starred/geodns

Fork 0

mirror of https://github.com/abh/geodns.git synced 2026-04-27 03:45:53 +03:00

[GH-ISSUE #12] DNSSEC support? #153

New issue

Open

opened 2026-03-01 17:24:14 +03:00 by kerem · 5 comments

kerem commented

2026-03-01 17:24:14 +03:00

Owner

Originally created by @miekg on GitHub (Sep 3, 2012).
Original GitHub issue: https://github.com/abh/geodns/issues/12

Hello,

Do you want to support DNSSEC?

There are two issues at stack here:

DNSSEC is dependent on a correct clock, hence everybody uses NTP. But this creates a catch-22 when DNSSEC validation errors break NTP.
Go DNS (and fksd) does not make DNSSEC as easy as it should, but this is minor compared to 1)

Originally created by @miekg on GitHub (Sep 3, 2012). Original GitHub issue: https://github.com/abh/geodns/issues/12 Hello, Do you want to support DNSSEC? There are two issues at stack here: 1) DNSSEC is dependent on a correct clock, hence everybody uses NTP. But this creates a catch-22 when DNSSEC validation errors break NTP. 2) Go DNS (and fksd) does not make DNSSEC as easy as it should, but this is minor compared to 1)

kerem commented

2026-03-01 17:24:15 +03:00

Author

Owner

@abh commented on GitHub (Sep 3, 2012):

Yes, I'm planning to. In the short term I don't want to add it as a new variability, but supporting it in the next few months so I can start experimenting with it on something that's not the main pool.ntp.org zone would be good.

Regarding being dependent on NTP, we can make sure the DNS servers here aren't depending on "themselves" for that.

I am most concerned about performance and what impact it will have on the DNS traffic on the (sometimes volunteer) servers, but those are things we can figure out, too.

@abh commented on GitHub (Sep 3, 2012): Yes, I'm planning to. In the short term I don't want to add it as a new variability, but supporting it in the next few months so I can start experimenting with it on something that's not the main pool.ntp.org zone would be good. Regarding being dependent on NTP, we can make sure the DNS servers here aren't depending on "themselves" for that. I am most concerned about performance and what impact it will have on the DNS traffic on the (sometimes volunteer) servers, but those are things we can figure out, too.

kerem commented

2026-03-01 17:24:15 +03:00

Author

Owner

@miekg commented on GitHub (Sep 3, 2012):

[ Quoting notifications@github.com in "Re: [geodns] DNSSEC support? (#12)..." ]

I am most concerned about performance and what impact it will have on the DNS
traffic on the (sometimes volunteer) servers, but those are things we can
figure out, too.

That should not be a problem. DNSSEC zones are pre-signed. The answers are
slightly bigger than with DNS, but the server load does not increase (much).

Regards,

Miek Gieben                                                   http://miek.nl

@miekg commented on GitHub (Sep 3, 2012): [ Quoting notifications@github.com in "Re: [geodns] DNSSEC support? (#12)..." ] > I am most concerned about performance and what impact it will have on the DNS > traffic on the (sometimes volunteer) servers, but those are things we can > figure out, too. That should not be a problem. DNSSEC zones are pre-signed. The answers are slightly bigger than with DNS, but the server load does not increase (much). Regards, ## ``` Miek Gieben http://miek.nl ```

kerem commented

2026-03-01 17:24:15 +03:00

Author

Owner

@abh commented on GitHub (Sep 4, 2012):

But the geodns server makes every answer (just about) different. Maybe a cache could remember answers that worked out to be the same, but I don't think the hit rate would be huge. For 'pool.ntp.org' (assuming no country information for the client) it randomly chooses between 2-3000 weighted servers.

One option is to have 'pool.ntp.org' (for example) unsigned, but sign certain sub-zones (debian.pool.ntp.org, fedora.pool.ntp.org etc) for users who are more likely to care.

(Update: Eh, obviously pool.ntp.org would have to be signed for that to work, but 1.pool.ntp.org etc wouldn't have to be).

@abh commented on GitHub (Sep 4, 2012): But the geodns server makes every answer (just about) different. Maybe a cache could remember answers that worked out to be the same, but I don't think the hit rate would be huge. For 'pool.ntp.org' (assuming no country information for the client) it randomly chooses between 2-3000 weighted servers. One option is to have 'pool.ntp.org' (for example) unsigned, but sign certain sub-zones (debian.pool.ntp.org, fedora.pool.ntp.org etc) for users who are more likely to care. (Update: Eh, obviously pool.ntp.org would have to be signed for that to work, but 1.pool.ntp.org etc wouldn't have to be).

kerem commented

2026-03-01 17:24:15 +03:00

Author

Owner

@miekg commented on GitHub (Sep 4, 2012):

[ Quoting notifications@github.com in "Re: [geodns] DNSSEC support? (#12)..." ]

But the geodns server makes every answer (just about) different. Maybe a cache
could remember answers that worked out to be the same, but I don't think the
hit rate would be huge. For 'pool.ntp.org' (assuming no country information for
the client) it randomly chooses between 2-3000 weighted servers.

Ah. But that also means on-the-fly signing and distributing the private keys
to slaves. All doable, but this makes for an interesting use case.

One option is to have 'pool.ntp.org' (for example) unsigned, but sign certain
sub-zones (debian.pool.ntp.org, fedora.pool.ntp.org etc) for users who are more
likely to care.

That would break the chain of trust. Again: an interesting use case :-)

Regards,

Miek Gieben                                                   http://miek.nl

@miekg commented on GitHub (Sep 4, 2012): [ Quoting notifications@github.com in "Re: [geodns] DNSSEC support? (#12)..." ] > But the geodns server makes every answer (just about) different. Maybe a cache > could remember answers that worked out to be the same, but I don't think the > hit rate would be huge. For 'pool.ntp.org' (assuming no country information for > the client) it randomly chooses between 2-3000 weighted servers. Ah. But that also means on-the-fly signing and distributing the private keys to slaves. All doable, but this makes for an interesting use case. > One option is to have 'pool.ntp.org' (for example) unsigned, but sign certain > sub-zones (debian.pool.ntp.org, fedora.pool.ntp.org etc) for users who are more > likely to care. That would break the chain of trust. Again: an interesting use case :-) Regards, ## ``` Miek Gieben http://miek.nl ```

kerem commented

2026-03-01 17:24:15 +03:00

Author

Owner

@miekg commented on GitHub (Jan 25, 2015):

Note that I've implemented on the fly-signing with caching for SkyDNS: https://github.com/skynetservices/skydns/blob/master/server/dnssec.go

It uses NSEC3 whitelies. Something similar can be done for geodns.

@miekg commented on GitHub (Jan 25, 2015): Note that I've implemented on the fly-signing with caching for SkyDNS: https://github.com/skynetservices/skydns/blob/master/server/dnssec.go It uses NSEC3 whitelies. Something similar can be done for geodns.