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

Warren Kumari warren at kumari.net
Tue Apr 14 21:06:56 UTC 2015


On Tue, Apr 14, 2015 at 4:31 PM, Michael Sinatra <michael at brokendns.net> wrote:
> 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.

Depends on who you are and who is interested in the contents of your
zone -- if you are operating a ccTLD (and depending on the number of
records, the distribution of records, phase of the moon, etc) it *may*
be cheaper to simply allow AXFR instead of having a bunch of spammers
do dictionary attacks trying to guess all the names. At least one
ccTLD (that I know of) became much happier after they just threw in
the towel and allowed AXFR...

W

>  I am kind of surprised and disappointed that the US-CERT
> doesn't mention that component of the issue.
>
> michael
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf



More information about the dns-operations mailing list