[dns-operations] Stunning security discovery: AXFR may leak information

[Michael Sinatra]

On 4/14/15 12:00 PM, Mike Hoskins (michoski) wrote:

>> I disagree with this.  There is no valid reason for exposing your
>> network topology to the outside world. You are only making the job
>> easier for potential attackers.
> 
> Yes agreed.  The finding is nothing new, and it's not a weakness in AXFR
> itself as others have rightly pointed out...so the timing and way in which
> it was reported were less than ideal...but your point is spot on.  Many
> speak against "security by obscurity" but I think that is often taken too
> far -- in some ways blocking AXFR is no different than DMZs and
> firewalls...hey, why not have everything on public IP with all ports
> exposed?  Security is an onion, and as many layers as you can put between
> you and the adversary are generally good assuming the "obscurity" is not
> adding unnecessary complexity or other hidden cost (proper config of a DNS
> server is quite easy and can be automated).

The problem I have with the way that this is posed by the US-CERT
advisory is that it neglects to point out that DNS is designed to be a
public database.  If you put information in the DNS that makes it easy
to guess things about your network that you don't want people to guess,
well, you have a problem then.  Relying on AXFR restrictions to mask
that problem is, at best, a weak control.  (See Paul's post.)  Because
security is indeed an onion, AXFR restrictions really shouldn't be
*that* important--just another layer in a set of good security practices.

The real reason I see for restricting AXFR is to preserve resources on
the server.  This is less of an issue now than it was in the BIND 4 days
(didn't BIND 4 used to fork() for outbound zone transfers?), but I still
don't want any- and every-one to hammer my DNS servers with AXFR
requests.  I am kind of surprised and disappointed that the US-CERT
doesn't mention that component of the issue.

michael