Domain transfers failing - attempted AXFR over UDP
Barry Margolin
barmar at alum.mit.edu
Wed Jun 23 17:57:32 UTC 2004
In article <cbc7c9$oi2$1 at sf1.isc.org>, Chris Cameron <chris at upnix.com>
wrote:
> Have a DNS server that, for simplicities sake, only has 1 zone. Using
> nslookup from a host that is allowed zone transfers, I did a simple:
>
> > set type=AXFR
> > domain.com
>
> (This fails, although I don't have exact error has I had to revert named
> back to a working config for the day)
>
>
> What showed up in my named query log:
>
> Jun 22 19:58:43 localhost named[3453]: client 192.168.120.50#46666:
> query: domain.com IN AXFR
> Jun 22 19:58:43 localhost named[3453]: client 192.168.120.50#46666: bad
> zone transfer request: attempted AXFR over UDP (FORMERR)
> Jun 22 19:58:43 localhost named[3453]: client 192.168.120.50#46667:
> query: domain.com.domain.com IN AXFR
> Jun 22 19:58:43 localhost named[3453]: client 192.168.120.50#46667: bad
> zone transfer request: 'domain.com.domain.com/IN': non-authoritative
> zone (NOTAUTH)
>
>
> So, what seems to happen is the domain gets appended to itself, which of
> course fails. But it looks like it only happens after it gives the
> error "attempted AXFR over UDP".
>
> Searching google for this brings up nothing. I can understand why it
> won't give me a zone over UDP, but using this same method on any other
> server gives me a zone transfer.
Your problem is that you're trying to use nslookup, a known deficient
tool.
If you want to do a zone transfer with nslookup, you must use its "ls"
command. It doesn't know that "set type=AXFR" means that it should
perform the request differently.
When it gets an error from the attempted UDP query, it treats it as a
"host unknown" error, and its normal way of dealing with this is to
retry the query with the default domain appended, which causes the
second log message.
> Now, this would seem like the classic '.' missing somewhere, but that
> zone file is not a big one, and I have hundreds of other working zone
> files, so I'm relatively certain the zone file is ok. Normal DNS
> queries against this zone also work fine.
>
> TCP connections to named are also fine as I'm able to telnet to port 53.
>
> Any ideas on what it could be? I'm doing this to debug -another-
> problem, so I can't really confirm whether BIND itself is able to coax
> a zone transfer out of this server or not.
Use "dig" instead of nslookup and you should rarely be confused.
--
Barry Margolin, barmar at alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
More information about the bind-users
mailing list