[dns-operations] FreeBSD and the slaving of the root zone
simonw at zynet.net
Tue Jul 31 18:06:26 UTC 2007
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
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
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
More information about the dns-operations