[dns-operations] FreeBSD and the slaving of the root zone
Mark_Andrews at isc.org
Thu Aug 2 23:00:37 UTC 2007
> I buy slaving the root as definitely beneficial in the case of busy
> servers serving applications that aren't particularly well defined.
> As Paul says, this is a case where you're more likely to have DNS
> wizards who can deal with magic configurations if needed.
> The case for everyone doing this is less clear to me. Based on the
> figures I got in the paper, slaving the root was unlikely to represent
> a reduced level of traffic for quiet resolvers. It should represent
> slightly better behavior in the case where your network becomes
> disconnected from the Internet at large and may give quicker
> The paper does mention how it reduces the flow of crud out of a
> network. I hadn't though about this in terms of privacy, but Mark's
> point is an interesting one here. It seems unclear if the root
> server ops want the flow of crud reduced, as it certainly does offer
> interesting glimpses of what's going on in the Internet as a whole.
> The major points against that I see are (1) the root servers would
> have to serve more TCP, which is something they have less experience
> of and (2) this isn't something that they haven't promised to do.
> I guess both these points could be addressed because (1) there are
> lots of people around who know how to serve many TCP connections
> and (2) if slaving the root zone is actually a good idea, then the
> root servers could decide to support it.
> A slightly more tricky negative point is that slaving the root zone
> interacts poorly with anycast. If you switch between two anycast
> instances in the middle of an AXFR or IXFR, then you'll have to try
> again later. A failed transfer isn't fatal, as you can keep using
> the old zone until it expires, but we don't have experience of how
> these things will work.
> In terms of maintainability of the DNS system, I think slaving the
> root zone is roughly similar to the existing hints method. Both
> methods hardcode a list of IP addresses, which can gradually go
> stale as root servers renumber. In practice this makes the slave
> method less robust at the moment, simply because it has fewer IPs
> that give AXFRs of the root.
> I can think of some other questions that may also be worth considering,
> some of which have already come up in this discussion:
> 1) Resolvers usually only ask for records they know about.
> What happens if they AXFR from the root and it contains
> records they don't understand?
See RFC 3597, Handling of Unknown DNS Resource Record (RR) Types.
> 2) There may be marginal effects in terms of how difficult
> it is to blindly spoof responses from root servers. There
> are other solutions to this problem, so it's not a show-stopper.
> I don't think there's a big difference with respect to man
> in the middle attacks, since if someone gets between you
> and the root servers there are already bad things that can
> happen? Spoofed notify is an interesting question.
Notify is not a issue as notify would be turned off.
> 3) If someone screws up the serial number of the root zone,
> there could be an interesting mess to clean up.
What mess? Serial numbers roll over.
> 4) Are there sensible values for expire, retry and refresh
> if this scheme was in use? How often should the serial
> number really be incremented?
The first thing is to only change the serial when it needs
to be changed and not twice daily.
> If anyone actually wants to document the pros and cons of slaving the
> root compared to the hints file, I'd be glad to try and help.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews at isc.org
More information about the dns-operations