Slaving the root and other top-level DNS zones

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