Bugtraq mailing list archives

Re: Full zone information disclosure on top level domain name servers


From: Måns Nilsson <mansaxel () sunet se>
Date: Sat, 19 Oct 2002 09:27:05 +0200

--On Friday, October 18, 2002 14:28:23 -0700 Max <rusmir () tula net> wrote:
Many of top level domain (TLD) DNS servers do not implement any
restrictions on AXFR query.

And this is not a problem from an information disclosure point of view. If
you believe you have a security problem when AXFR is possible for a given
zone, you obviously have a very serious security problem in the rest of
your systems since you so desperately need to hide them. 

Credits:

I'll keep all the credits. Feedback is welcome at "rusmir AT tula DOT net"

I wouldn't want credits for this, and I believe noone else with their
reality view properly adjusted would either. 

Appendix:

Fortunately, none of .com/org/edu/net/mil/gov servers allow AXFR.

That is entirely for performance reasons. A zone on disk or in transfer is
roughly 100 bytes per RRset, averaged. So, a TLD like .NL is some 100+ megs:

ls -l slave/nl | awk '{ print $5/(1024*1024) }'
117.308
(this is the file format BIND writes the zone in, no extra comments) 

And, as a small exception from above, a somewhat possible DoS scenario
exists if an attacker is able to bog down a server with this thus
exhausting its resources. For smaller domains (up to, say, 100000 RRsets)
on modern, well-connected hardware, it is probably too much work to be
practically feasible. 

For the small leaf domain, with typically only one network, self-contained
and simple, blocking zone transfers is also useless; a simple loop that
fetches the PTR records for that particular network is often enough. And,
most RIRen require you to maintain reverse zones. Many admins, who have
blocked zone transfers for "security" have been surprised by this...

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.



Current thread: