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

[Marjorie]

On 14-04-2015 22:31, Michael Sinatra wrote:
> <snip>
> 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.  
The thing is, AXFR goes beyond the 'public' requirement.
In DNS you submit a specific request, you get a reply. Anything that is
public, shall have an answer.
Doesn't mean you must/should tell more than what was asked.

Enabling AXFR is akin to publishing the whole corporate phone book for
the whole world to see (which may possibly be a desired feature in a
limited number of cases - as long as you understand the implications).

> 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.
Completely. Usually does more good than harm to restrict zone transfers o:)
>
> 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.
>
Certainly a valid concern, even though most zones are small.