Zone transfer failing

[Kevin Darcy]

Don Doumakes wrote:

>I've got a problem with secondary DNS, and am searching for the
>correct question.  :)
>
>I run a name server which is authoritative for several domains.  I
>trade secondary DNS with a friend:  his name server is my secondary
>and vice versa.  My slave server won't transfer zones from his master.
>
>My server, debs.pinko.net is running BIND 9.2.1 and Redhat Linux 8.0. 
>His server is ns1.quadaenterprises.com, and I understand he's running
>BIND 8+ but I'm not sure.  Typical log output during the attempted
>zone transfer:
>
>Sep 15 22:04:53 debs named[13120]: zone shoppinstop.com/IN: refresh:
>failure trying master 66.112.55.16#53: timed out
>Sep 15 22:04:53 debs named[13120]: zone shoppinstop.com/IN: refresh:
>retry limit for master 66.112.55.16#53 exceeded
>
>In Albitz & Liu's "DNS and BIND" three leading causes for this
>behavior are listed:  loss of connectivity to the master, incorrect IP
>address for the master in the configuration file, and syntax error in
>the zone data file on the master.  I can ping 66.112.55.16, so it's
>not connectivity.  The config file definitely has the correct IP
>address for the master.  And I can do a zone transfer using dig:
>
>dig @66.112.55.16 quadaenterprises.com axfr
> 
>; <<>> DiG 9.2.1 <<>> @66.112.55.16 quadaenterprises.com axfr
>;; global options:  printcmd
>quadaenterprises.com.   43200   IN      SOA    
>ns1.quadaenterprises.com. brent.quadaenterprises.com. 2004082601 7200
>7200 1209600 172800
>quadaenterprises.com.   43200   IN      MX      10
>mail.quadaenterprises.com.
>quadaenterprises.com.   43200   IN      MX      20
>www.baldwinbunch.net.
>quadaenterprises.com.   43200   IN      TXT     "v=spf1 a mx -all"
>quadaenterprises.com.   43200   IN      NS      ns1.4safedata.com.
>quadaenterprises.com.   43200   IN      NS      ns1.activitae.com.
>quadaenterprises.com.   43200   IN      NS     
>ns1.quadaenterprises.com.
>quadaenterprises.com.   43200   IN      NS      debs.pinko.net.
>quadaenterprises.com.   43200   IN      A       66.112.55.16
>ns1.4safedata.com.quadaenterprises.com. 43200 IN NS 65.66.245.121.
>ns1.activitae.com.quadaenterprises.com. 43200 IN NS 80.177.4.228.
>ns1.quadaenterprises.com.quadaenterprises.com. 43200 IN NS
>66.112.55.16.
>mail.quadaenterprises.com. 43200 IN     A       66.112.55.16
>debs.pinko.net.quadaenterprises.com. 43200 IN NS 204.96.181.68.
>ns1.quadaenterprises.com. 43200 IN      A       66.112.55.16
>server.quadaenterprises.com. 43200 IN   MX      10
>mail.quadaenterprises.com.
>server.quadaenterprises.com. 43200 IN   A       66.112.55.16
>stats.quadaenterprises.com. 43200 IN    A       66.112.55.16
>www.quadaenterprises.com. 43200 IN      A       66.112.55.16
>quadaenterprises.com.   43200   IN      SOA    
>ns1.quadaenterprises.com. brent.quadaenterprises.com. 2004082601 7200
>7200 1209600 172800
>;; Query time: 93 msec
>;; SERVER: 66.112.55.16#53(66.112.55.16)
>;; WHEN: Wed Sep 15 22:22:11 2004
>;; XFR size: 21 records
>
>
>So I'm stumped.  I have exactly two clues:  (a) I can't resolve the
>name ns1.quadaenterprises.com from my own server, 
>
Hmmm... That'd odd. What kind of error do you get?

I don't see how this can be related to your zone transfer problems, 
though, since masters are specified by IP address, not name.

>and (b) the output
>of dig (above) looks as if there might be some missing periods in his
>zone file.
>
Yeah, there are missing periods, and a wrong record type, for "glue" 
records that are unnecessary and would've have been rejected as a 
duplicate, in the case of ns1.quadaenterprises.com, and as "out of 
zone", for the other 3, if they head been syntactically correct. I.e. it 
appears they have in their zone file

ns1.4safedata.com ns 65.66.245.121.
ns1.activitae.com ns 80.177.4.228.
ns1.quadaenterprises.com ns 66.112.55.16.
debs.pinko.net ns 204.96.181.68.

Looks like the intention was to create "glue" records for the 
nameservers. But with the owner names not dot-terminated, and the type 
being "ns", these actually created *delegations* for strange subzones of 
quadaenterprises.com, to nameservers with unresolvable, all-numeric 
names. Sloppy work indeed.

But, as oddball as this may be, it shouldn't (and didn't, as your dig 
output attests) prevent you from transferring the zone.

>Can someone suggest a direction for further inquiry?
>
Why don't you try troubleshooting shoppinstop.com, the zone being 
complained about the logs? Can you transfer the zone via dig? Maybe it's 
as simple as a bad allow-transfer on the zone...

                                                                         
                                                - Kevin