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

[Simon Waters]

Personally I think slaving the root zone is a reasonable model, and have 
advocated such. However there is a big difference between believing it to be 
a reasonable model and deploying it on machines I'm immediately responsible 
for, versus deploying it on a whole class of machines.

The primary issue raised so far, that it make a weaker assumption about the 
set of servers providing the root zone information, is a client problem, not 
a root server operators issue -- if a whole lot of recursive servers forget 
how to query the root servers, that will just make FreeBSD look bad - so long 
as they fail so as to produce less traffic to the root servers it isn't a 
root server issue.

So the remaining issues are how else will it affect the root servers and their 
management.

I'm guessing that whatever FreeBSD does, short of a deliberate DDoS isn't 
going to have huge operational impact. The big FreeBSD installations are 
going to do this knowingly.

If the traffic reduction by doing this isn't significant, it could shift 
traffic from the root servers (13 by name) to the root servers providing AXFR 
(5 by IP address), which is something that would have to be watched, but I 
don't think would be more than a general management issue.

Abuse ideas anyone?

One could spoof NOTIFY messages from the root servers, causing an SOA request 
from the slave to the root servers. But whilst this provides indirection in 
hiding the source of the abuse, it doesn't provide amplification, and I 
suspect isn't a great concerned compared to the number of open recursive DNS 
servers already around. Still craftier minds than mine will ponder this 
issue!

Perhaps by spoofing NOTIFY packets one could cause randomly started slave 
boxes to all request their SOA packets for "." at the same instant in time. 
So that an attacker could synchronise all the SOA packets to arrive at once. 
i.e. pick a bunch of slaves, and spoof a NOTIFY between 12:00:00 and 
12:00:01, then based on the advertised SOA record of the root zone, one would 
pick another bunch of slaves and get them to refresh when the others would, 
rinse and repeat, till all the slaves are fetching the SOA record at the same 
time. But even here normal refresh mechanisms in BIND would probably cause 
such an attack to be merely nusiance, as those that fail will come back 
later. Ironically the slaves would continue to answer queries for their own 
clients, at least till the root zone expires, even if this briefly stopped 
services for other clients of those servers.

What happens if you DDoS the servers providing AXFR, how does the 
retry/fail-over behaviour for transfers compares to the same situation for 
normal queries? Too late in the day for me to think that one through. 

Once you get use to slaving the root zone, you don't have to get it via 
AXFR ;)