I never found any reference to this in example set-ups, including those from the Bind ARM.
Nevertheless, I noticed my authoritative server received transfer requests from IPs — not their names — that were actually part of some root-servers' set — the DNS root.
I was about to allow such transfers in my configuration and thought about double checking.

If I'm right, the root will only answer for the gTLDs, and then the TLDs only for their respective next level domains — delegations. But, if I understand the hierarchical design of DNS, it's up to each server to provide all the information it has rather than providing the strict minimum and referring the client into the iterative process. So why not, a root server could wish to be able to answer about my zones… that would alleviate my own servers.

So, first of all, why does a root server (seem to) ask for my zones?
Can this actually be an attack?

Or, if that is OK, remains the risk that such a server — root or TLD's — will allow transfers for the zones it handles while this may not be our policy — don't trust the big fish to always manage perfectly its settings.

I guess we could feel differently depending on if we have already authenticated the zones with DNSSEC, as trusting the root for DNSSEC signatures is not just equivalent to trusting the root for the whole zone content.

And by the way, if we allow the transfers, we should also send them notifications on modifications.

*I feel this question should also have the tags *
AXFR, zone-transfer & root-servers

EDIT (here is the clue):
I was going from the log lines like

20-Jan-2016 20:33:30.581 security: error: client zone transfer 'MyZone.info/AXFR/IN' denied


dig +noall +answer +authority -x @a.in-addr-servers.arpa.
192.in-addr.arpa.       86400   IN      NS      y.arin.net.

dig +noall +answer +authority -x @y.arin.net.
134.192.in-addr.arpa.   172800  IN      NS      ns3.nic.fr.

dig +noall +answer -x @ns3.nic.fr. 172800 IN    PTR     zonemaster.rd.nic.fr.

dig +noall +authority SOA zonemaster.rd.nic.fr. @ns3.nic.fr.
rd.nic.fr.              3600    IN      SOA     ns2.rd.nic.fr. hostmaster.nic.fr. 2015111706 21600 3600 3600000 3600

And well…
I did on those dates play with online DNS checkers, including the French TLD's zonemaster.fr. Quite a detailed one, by the way.

So the AXFR request was just part of the tests they run. :-)

My mistake.
Thanks for your answers.

  • 1
    Can you show what was actually going on in more detail? Logs? It doesn't really make any sense that the root servers would try to AXFR anything from you. – Håkan Lindqvist Jan 31 '16 at 23:47
  • Safest bet is to directly contact the specific root server operator and confirm the intent of the transfer. Keep us updated – pete Feb 1 '16 at 0:42

For the most part, while I would agree with the sentiment about not trusting the big fish to always manage their settings. Since there is really no (direct) profit available from running DNS (let's ignore OpenDNS/Google etc). I have always believed that the root domain servers are very likely run by very very geeky DNS guys who are very adept at what they do. Simply because it would be so catastrophic to the internet at large if these servers are badly managed. I think generally you can trust the core network stuff, because management is kept away from it!

Saying that, there is no reason that a root zone server would be requesting a AXFR from an authoritative server of a domain. These are very busy machines (clusters) imagine the additional strain that randomly requesting zone transfers would have. There is simply no logical reason that this would happen. Hence I would be almost certain that this is some sort of attack.

The only servers that need AXFR access is secondary zone servers, everything else can use the standard DNS protocols, like they're meant to!

  • Basically, I agree with you. I did not want to be degrading towards the geeks who care for the net. It's just that cross checking TLD settings with each other's tools can provide some surprises. Like this one SE tested by FR (and I don't advertise all what I have noticed while paying around). Thanks. – ondelettes Feb 1 '16 at 12:23

Well, actually...

Conceivably it might be that at least one root name server (say, for the sake of argument, that it'd be named L) is actually a set of hundreds of servers distributed all over the world. And it might be that some entity is interested in testing the setups of DNS zones, and that this entity might have access to this set of machines. It would then be pretty convenient to use those machines to run tests from, since that would give information about how things work from various different places. And, also, one of the tests might be to send an AXFR query not to actually get the information, but to see if it will be allowed or denied.

Or so I might have heard.

  • It turns out you're close to what actually happened. A pity you got a minus. Thanks. – ondelettes Feb 1 '16 at 12:28
  • I wrote a large part of the test engine for zonemaster.fr :-) – Calle Dybedahl Feb 1 '16 at 12:50
  • @ondelettes: if you consider this to be the most correct answer, it would be a good idea for you to accept it. That way, if someone else has the same question and looks here, they will find the right answer. – Jenny D Feb 1 '16 at 18:12
  • Might find interesting, I had just read that the ISC Domain Survey used to AXFR, until too many hosts were blocking it to be useful ages ago (or so implied; not explicitly stated) – pete Feb 2 '16 at 1:02
  • @jenny-d Actually Calle's answer guessed quite well what happened, but my question was "should we allow", and for that I expected kind of a "normative" answer. In that sense, Michael's reply gets closer by stating "there's no reason". About Pete's comment – thanks for the link, the fact a survey gets the transfers does not mean the same organization will then serve the zone details, it's more of an indication that transfers used to be more available than they have become. – ondelettes Feb 12 '16 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.