AXFR resolution path
Kevin Darcy
kcd at daimlerchrysler.com
Mon Sep 26 23:09:22 UTC 2005
Jeffrey Stevens wrote:
>If I configure my DNS to be master for a fake test zone and attempt to use dig
>to that server to transfer the zone, it times out. I believe it is recursing to
>the root servers to resolve the (internal intranet) MNAME in the SOA.
>
>Ok, I thought I'll first have it resolve the MNAME (should get it from a
>forwarder first, not a root) and then try the zone transfer. This should avoid
>the recursion to the roots, but does not, it just times out. Did I understand
>this correctly?
>
>
Zone transfers are not recursable. If you're pointing your client
directly at the master or one of the slave servers (e.g. via dig
example.com axfr @x.x.x.x) and it's timing out, then there some sort of
connectivity and/or firewall-rule problem involved. Firewall-rule
problems aren't terribly unusual, since zone transfers use TCP, whereas
most (but not all) ordinary DNS queries use UDP -- certain overzealous
and/or ignorant firewall admins will allow the "safe" UDP protocol
through the firewall, but block the "scary" TCP protocol.
Not sure where you're going with the whole MNAME thing. For zone
transfers, you need to talk directly to an authoritative nameserver for
the zone. The MNAME _should_ refer to an authoritative nameserver for
the zone, but many folks screw up their MNAME fields with little or no
ill effect (i.e. there's little incentive for them to fix it), and even
if the MNAME field is "correct", it might refer to a "hidden master"
that you can't even talk to. You'd be better off stepping through the NS
records for the zone, but ultimately, if this is a zone you have any
legitimate business zone-transferring, you should already be in contact
with the administrator, and they'll tell you what names and/or IP
addresses to use. You might also need to configure the appropriate TSIG
keys, if transfers of the zone are crypto-authenticated.
- Kevin
More information about the bind-users
mailing list