Local Slave copy of root zone

Doug Barton dougb at dougbarton.us
Sat Aug 18 22:57:17 UTC 2018

On 2018-08-15 10:43, Tony Finch wrote:
> Doug Barton <dougb at dougbarton.us> wrote:
>> Slaving the root and ARPA zones is a small benefit to performance for 
>> a busy
>> resolver, [...]
>> This technique is particularly useful for folks in bad/expensive 
>> network
>> conditions. While the current anycast networks of root servers is much 
>> better
>> than it was "in the old days," the more data you have locally the more
>> resilient you are to DDOS against those targets.
> I should probably have said that it isn't just RFC 8198:
> * synth-from-dnssec (RFC 8198) synthesizes negative answers, so in most
>   cases you don't need to talk to the authorities to find out that the
>   answer is no; this is on by default

If you're slaving the zone on the resolver, that resolver is 
authoritative for the zone, so it doesn't need to query another server 
to prove that the answer is no.

> * prefetch (https://tools.ietf.org/html/draft-wkumari-dnsop-hammer [1])
>   means your users won't suffer the latency of talking to the 
> authorities
>   when a popular name expires from the cache; this is on by default

If you're slaving the zone, there is no cache to expire.

> * stale-answer-enable / max-stale-ttl
> (https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale)
>   means you can still function for a while if you can't reach the 
> authorities

This is a terrible idea, so not having it is a good thing.  :)

> These are all general-purpose features, not at all specific to the 
> root.
> I think a local root was clearly a good idea before DNSSEC; since 2010 
> I
> have been less comfortable with it.

How, specifically, is DNSSEC affected by the validating resolver having 
a local copy of the root zone?


More information about the bind-users mailing list