I've got a mess

[Bill Larson]

On Apr 21, 2004, at 9:03 AM, Michael Barber wrote:

> Thanks Kevin...  Answers below.
>
>> Michael Barber wrote:
>>
>>> I changed my named.conf on the secondary from the commented lines to 
>>> the
> new
>>> lines...
>>> It looks like it was slaving the local db.127.0.0.
>>>
>> I'm not sure what relevance that has. That's an entirely different 
>> zone.
>
> No relevance....just trying everything I can think of.  I think its 
> always
> been like that....I thought it was saying that it wasn't authoritative
> because the primary NS is up and that it refers to it.

If it is no relevance then don't try working with it.  Shotgun 
approaches to troubleshooting problems are rarely effective.

>> What does the slave zone definition for comcity.com look like?
>
> //named.conf
>
> zone "comcity.com" {
>  type slave;
>  file "_db_COMCITY.zone";
>  masters {
>   207.168.174.130;
>  };
> };

Actually, what is the WHOLE configuration file on this server look 
like.  Just send us the whole thing to review rather than making us 
guess what you have.

> //comcity zone as slaved.
> (trimmed some superflous A records for clarity)
>
> ; BIND version named 8.4.4 Fri Jan 16 22:45:44 2004
> ; BIND version marka at drugs:src/port/winnt
> ; zone 'comcity.com'   first transfer
> ; from [209.66.93.2].53:53 (local [209.10.62.22].1045) using AXFR at 
> Mon Mar
> 08 13:59:21 2004
> ; NOT TSIG verified
> $ORIGIN com.
> comcity 1800 IN SOA ns.comcity.com. webmaster.comcity.com. (
>   2004033101 43200 7200 604800 1800 )

I strongly suspect that this is the zone file on the slave because it 
doesn't match the zone file on the master.  On the master, your serial 
number in the SOA record is "2004042001" rather than the "2004033101" 
that you have identified.

(Even more lines deleted.)

>> Also, do
>> you see any error messages in the logs at the time named tries to
>> read/load the comcity.com zone file?
>
> No error messages at all.

What exactly are you logging and where are you looking for these logs?

On your slave system, ns2.comcity.com, can you successfully run "dig 
@207.168.174.130 comcity.com axfr"?  This will perform a zone transfer 
on your slave getting the zone information from your master.  If this 
command returns a listing of the comcity.com zone, then your slave CAN 
request a zone transfer from your master and the problem should lie 
with the configuration of the slave.  If this command does NOT return a 
listing of the comcity.com zone, then the problem lies with the 
configuration of the master OR your network communication between the 
master and slave.

Please note that the master DOES respond to the zone transfer to my 
machine which is not on your network.  So, your master is allowing zone 
transfers but maybe not to your slave or the network that your slave is 
on.  (AFTER this problem is solved, you may want to reconfigure your 
server to prevent this.  But until things are working, this is a useful 
capability to allow us to try and help you out).

The two name servers that you have identified for your zone, 
ns.comcity.com and ns2.comcity.com are on two different networks (IP 
addresses show different networks and a traceroute shows completely 
different paths to the two servers).  Could there be routing problems 
between these two networks that is preventing communication?  Maybe one 
or more firewalls between the two servers that are selectively blocking 
communications?  The results of the "dig" command will indicate if the 
necessary communication is possible, tell us the results to allow us to 
help.

Remember that TCP communication on port 53 is necessary for a zone 
transfer.  Many people block TCP communication on port 53 under the 
belief that this improves security.