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

[Mark Andrews]

In message <152316B1-9E18-463D-B148-71CEA2038CA2 at icann.org>, "John L. Crain" writes:
>
> 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

When rsh was all in fashion, slaving (AXFR) the zone on the recursive
servers actually made rsh safer as it prevented cache poisoning of
the addresses.  This was despite calls to ban it because it gave
away the names.

I, and I know others, have been able to debug DNS problems reported
on bind-users because we could see the full zone contents which
would have been harder or perhaps impossible to solve otherwise.

RFC 2317 style reverse "delegations" really need the "parent" zone
to be open to at a mimimum the users of the delegated address space
or else reverse lookups fail when the network connection(s) to the
site break.

Any zones you have in your search lists should be servers locally
so that you can survive network partitions.  These may or may not
all be zones you "own".  With DNSSEC this includes all the parent
zones unless you want to have to install and manage trust anchors
for all the local zones on all machines performing validation.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org