Slaving the root and other top-level DNS zones
Phil Regnauld
regnauld at nsrc.org
Thu Feb 17 02:14:48 UTC 2011
Sorry, this probably should be moved to dns-ops, but this may
interest some of the network operators here.
Doug Barton (dougb) writes:
>
> I should also add that the fact that this configuration can get out
> of sync and cause problems is not to be taken lightly. When I first
> started using and recommending this configuration 10 years ago my
> feeling was that the days of "set it and forget it" DNS were coming
> to an end since DNSSEC was "just around the corner." I was wrong
> about that on both counts, but I still believe that for those that
> are willing and able to take appropriate care with their DNS
> infrastructure that this configuration is a win.
Not to tread on a landmine, but reading /etc/namedb/named.conf
on a (recent) FreeBSD, it states:
[...]
Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS
On the other hand, this method requires more monitoring than the
hints file to be sure that an unexpected failure mode has not
incapacitated your server. Name servers that are serving a lot
of clients will benefit more from this approach than individual
hosts. Use with caution.
[...]
(note that other zones can be configured to be slaved per the
above setup, but I'm only mentioning root for the sake of the
discussion)
In order:
Point 1:
After the NS has primed itself, and has been running for a few
minutes, how much faster are we talking about ? Is this something
you have some numbers on ? Is it measurable from a user experience
point of view ? Is there a sweet spot/ROI of sorts on scale ranging
from "small network" to "large corporation" ?
With ~300 TLDs in the forward space (don't know how many
subdelegations in-addr.arpa has off the top of my head), is this a
real, noticeable win ?
Imagining that the new vTLDs are a success, and this grows to
potentially thousands of new TLDs, what's the projected improvement
value from this setup ? Does it become a handicap ?
Point 2:
I've heard that 98% of traffic to the root is junk, but since
NXDOMAINs get quickly neg cached, how much bandwidth conservation
and resource preservation are we talking about ? If one takes
AS112 into account, how much improvement is this ?
Point 3:
Do we have a historical scenario where DDoS has effectively
hindered DNS resolution for caching nameservers to the extent
that they couldn't look up non-cached TLD records/prime themselves
at startup ?
Analysis of a big DoS attack in 2006, IIRC, did nothing more
that slow down somewhat some of the affected anycast instances.
Now, I'm not being skeptical here, but you put the arguments for
slaving the top level zones as a win-only situation. So I feel
compelled to ask you to back those claims, especially considering
the tradeoff in complexity and stability it entails with regards to
monitoring requirements.
The days of "set if and forget it" for DNS may be gone, but it's
no reason to make life unnecessarily complex for system administrators,
and while it's a personal choice to enable slaving, your recommending
it should be thoroughly justified :)
Cheers,
Phil
More information about the NANOG
mailing list