Domain transfers failing - attempted AXFR over UDP

[Barry Margolin]

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 ***