[dns-operations] Stunning security discovery: AXFR may leak information
marjorie at id3.net
Tue Apr 14 21:02:23 UTC 2015
On 14-04-2015 22:31, Michael Sinatra wrote:
> 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.
More information about the dns-operations