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

[Mark Andrews]

> 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
> NXDOMAINs.
> 
> 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.
> 
>         David.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org