[dns-operations] FreeBSD and the slaving of the root zone

David Malone dwmalone at maths.tcd.ie
Thu Aug 2 13:08:15 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?

	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.

        3) If someone screws up the serial number of the root zone,
        there could be an interesting mess to clean up.

        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?

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.


More information about the dns-operations mailing list