Problems with named default configuration in 6-STABLE

[Doug Barton]

Volker,

I'm sorry to say that you've provided a great deal of incorrect
information in this thread.

Volker wrote:

> Remember, AXFR requires a TCP transfer and not every firewall will
> happily let it pass.

This is true, although since to the firewall an AXFR looks just like
any other stateful TCP connection out to the wide world, it's actually
more likely (percentage wise) that this will succeed than it is that
the DNS requests (using UDP) will. Obviously, for those that cannot
transfer the zone, the hints mechanism is still in the comments.

> I (partially) agree to the speedup effects you mentioned

I think you should read the paper that David posted,
http://www.imconf.net/imc-2004/papers/p15-malone.pdf before you
comment further.

It's also worth nothing that even if the only benefits were greater
reliability vs. a root DDoS attack (which is sadly no longer a
theoretical issue) and the substantial improvements to local NXDOMAIN
answers, it would be worth it. Add the benefits of at worst a wash
with overall root traffic for the root zone, and the extra benefits of
also having local copies of ARPA and IN-ADDR.ARPA (which are much
smaller, and usually more frequently queried than the root zone) and
it's a clear win.

I should add for the sake of completeness that not every DNS
professional has reached the same conclusions I have, however the main
objection that is usually raised is not operational from the root
server operators, rather it's that DNS admins who are not paying
attention might miss a change that would prevent their local resolver
from slaving the zone at some time in the future. Given that the IP
addresses of the root servers hardly ever change, and given that we
have 5 servers to choose from (and we only need one good transfer to
make it work), and given that I (and as this thread points out,
others) actually do pay attention, I don't think this is going to be a
problem for us.

> but if just 5
> out of 13 root servers support AXFR, your bind will sit for a while to
> find a root server responding to it's AXFR requests.

I'm sorry, but that comment means that either you haven't read the new
named.conf, or you don't understand what you've read. Either way, you
should seriously consider whether or not it's a good idea for you to
continue offering DNS advice. The following:

zone "." {
        type slave;
        file "slave/root.slave";
        masters {
                192.5.5.241;    // F.ROOT-SERVERS.NET.
                192.228.79.201; // B.ROOT-SERVERS.NET.
                192.33.4.12;    // C.ROOT-SERVERS.NET.
                192.112.36.4;   // G.ROOT-SERVERS.NET.
                193.0.14.129;   // K.ROOT-SERVERS.NET.
        };
        notify no;
};

means that our named will only query those servers that actually do
allow AXFR. It's also worth noting that I listed F first because it's
currently anycasted to at least 40 locations around the world, so it's
almost always going to be the "closest" node.

A few more points worth mentioning; you only need to do a successful
transfer once per week (the expiry is one week). The actual content
(not the serial) of the root zone only changes a few times a week at
most, so realistically if you can transfer it only once per day you're
golden. Any working DNS setup ought to be able to transfer zones at
will of course. The ARPA zone hardly ever changes due to its nature.

So if you are in a situation where you know that you cannot reliably
perform zone transfers, yes, using the hints method is advised. But
then again, if you're in that situation you should probably reconsider
whether running a local resolver is a good idea or not.

BTW, so far we've only talked about the savings for an individual
resolver. If you are responsible for a network of resolvers you can
slave the zones from the roots on one server then slave them out to
your network from your local master for an overwhelming savings of
overall traffic to the roots. If you decide to do that, you should
take a look at the ixfr-from-differences option to save yourself even
more local traffic.


hope this helps,

Doug

-- 

    This .signature sanitized for your protection