UPDATE 2011-10-19: files containing raw data have been taken offline.
To shed a broader light on the state of DNS zone transfer configuration, I sent AXFR requests for 1063954 domains (zones) collected from the Google Trends sitemaps.
- 151684 out of 1063954 zones (14%) were AXFRable via
- 51407 out of 223619 nameservers (23%), in
- 210 out of 250 TLDs, yielding
- 26 million DNS records.
Here (.html) is a table w/breakdown per TLD.
Why bother about AXFR? DNS zones can contain information that is useful during reconnaissance activities. Needlessly giving away partial blueprints of IT infrastructure by permitting AXFR is probably a bad idea. US DoD DISA also recognizes lack of zone transfer limiting in the BIND section as a topic in its DNS Security Checklist v4r1.12 (.zip):
Group ID (Vulid): V-4483
Group Title: Zone master server does not limit zone transfers.
Rule ID: SV-4483r7_rule
Severity: CAT II
Rule Version (STIG-ID): DNS0460
Rule Title: A zone master server does not limit zone transfers to a list of active slave name servers authoritative for that zone.
Vulnerability Discussion: The risk to the master in this situation, is that it would honor a request from a host that is not an authorized slave, but rather an adversary seeking information about the zone. To protect against this possibility, the master must first have knowledge of what machines are authorized slaves.
Fix Text: The DNS software administrator should configure each zone master server to limit zone transfers to a list of active slaves authoritative for that zone. Configuration details may be found in the DNS STIG Section 4.2.8.
(I don’t know whether that checklist is applied to all .mil domains; AXFR was allowed in 3 out of 59 .mil cases – centcom.mil, dma.mil and dodlive.mil. For .gov, AXFR was allowed in 104 out of 984 cases. Presumably, DNS zone information that does not need to be publicly known may in some cases qualify as Sensitive But Unclassified — a category of information that the DoD recently proposed a new safeguarding rule for.)