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. _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
