[dns-operations] Domain Name System without Root Servers
Daniel Karrenberg
dfk at ripe.net
Tue Oct 3 12:28:18 UTC 2017
On 03/10/2017 04:23, Tony Finch wrote:
> Daniel Karrenberg <dfk at ripe.net> wrote:
>>
>> Methinks we could do even better by just loading the whole root zone
>> into resolvers.
>
> I was interested by Petr Špaček's presentation on RFC 7706 root slaving
> vs. RFC 8198 negative answer synthesis.
>
> https://indico.dns-oarc.net/event/27/session/3/contribution/7/material/slides/0.pdf
That is indeed a good presentation I enjoyed very much. It goes in the
right direction. Fetching the whole root zone is even better than
RFC8189 however.
>
> One of the things he discusses is actively pre-populating the cache,
I suggest "Fetch the whole root zone from wherever you like using
whatever protocol you like, then validate the signatures of all RRsets
as they get referenced before using them."
We need to start moving away from using DNS/UDP to obtain root zone
information and from the root name servers being the only source.
> ...>> As this paper shows nicely lameness will be very limited even if a
>> resolver operator chooses to do this only every couple of weeks.
>
> Hmm, I get the impression from https://twitter.com/diffroot that TLDs
> flip DS records fairly frequently - in the last two weeks,
>
> .kia
> .infiniti
> .nissan
> .ruven enough
> .hyundai
> .chloe
>
> and a couple with different rollover timing,
>
> .mil (5 day overlap)
> .lat (16 day overlap)
>
> so it looks to me like you would need frequent updates to avoid bogosity,
> unless TLDs commit to following RFC 5011 timing constraints.
These are corner cases and I expect that they will adapt to evolutionary
pressures. ;-)
Also there are several ways around this: The simplest is to fetch the
whole root zone at least once a day. It is no big deal unless you are in
space or Antarctica. More sophisticated would be to try a plain old
DNS/UDP fetch from the root name servers in case of a signature not
verifying and before declaring the RRset bogus.
Daniel
More information about the dns-operations
mailing list