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

[John L. Crain]

It’s important to remember that not all zones are created equal.

For example the root is publicly available and the data in there by it’s nature is open accesible.
The question of allowing or not allowing AXFR in such a case is more about resource usage.
For L root we actually provide separate servers for those that feel a need to get the zone via AXFR, purely as a matter of resource management.

At the TLD level the question of how much of the data (and non existence of data) becomes more complex and a decision has to be made about access to the zone file. As long as there is a decision made based on understanding the pros and cons of AXFR I wouldn’t even go as far as to say “unwise” in this case. It’s a business decision that needs to be made. Many (not all) TLDs allow access to zone files, although not always via AXFR. 

When it come to business networks and their DNS information I agree that “generally unwise” would be a good description. I’m not sure what purpose allowing AXFR to the outside world meets.

John




> On Apr 14, 2015, at 12:15 PM, Edward Lewis <edward.lewis at icann.org> wrote:
> 
> On 4/14/15, 14:47, "Marjorie" <marjorie at id3.net> wrote:
> 
>> The bottom line is that unrestricted AXFR is generally evil,
> 
> I'd go with "generally unwise".  There are folks that believe it is fine
> to allow access to their zones and I have no reason to say they are
> foolish.  Folks who are not concerned with the minutia of operating their
> DNS server most likely would not want to allow the access and the tools
> they use should meet their likely expectations.
> _______________________________________________
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4363 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150414/c470974f/attachment.bin>