Scanning Alexa's Top 1M for AXFR

They don't actually explain how to disable AXFR...saying just: "The easiest way to fix this issue is to re-check your dns server’s configuration file. Make sure that the nameservers only allow AXFR to subsidiary nameservers and that these aren’t allowed to answer AXFR requests."

In BIND, this is configured by the allow-transfer option. You can explicitly allow your slaves with an option like:

    allow-transfer { 192.168.1.1; };

Or, disable all transfers by specifying "none;". This can be done on a per-zone basis, as well, though the global section will apply in the absence of zone-specific configuration, which I suspect is how so many servers are misconfigured (i.e. there is no rule in place to block it in the global section, so it is allowing all for zones that don't have an allow-transfer section). I just noticed that some of my zones on slave servers fall prey to this, as well, even though I know better. The default seems to be to allow all, if allow-query allows all.

That said, I'm not overly alarmed. Very little (roughly zero) sensitive data exists in my world-facing zones.

The article author seems to ignore the existence of views. If you have confidential data query-able from the outside, it's a much bigger issue than wide open AXFR... Restricting AXFR is more cute than efficient, the information still leave your network unencrypted.

http://www.cyberciti.biz/faq/linux-unix-bind9-named-configur...