I've got a mess

[Michael Barber]

> On Apr 20, 2004, at 3:28 PM, Michael Barber wrote:
>
> > Well, I have my changes ready for the primary nameserver...but when I
> > shut
> > it off to make the changes the secondary....it did NOT pick up.
> > Castrophy!
> > Rush to get the Primary back up with what it has.  Something is
> > definetly
> > wrong with my secondary name server.  I noticed that Bill said that
> > ns2 is
> > not authorative for the zone....
> >
>
> Sorry, I already lost the very last message that you sent out on this
> thread.  This last message was about when you reconfigured your slave
> for the 0.0.127.in-addr.arpa zone and it's inability to function as a
> slave.

Bill:  I think my slave is correctly pulling from the Master at this point.
I think that issue was the result of the primary not being correct in the
glue record that was causing some strange behavoir.  But, in in an earlier
email you indicated that my secondary was "Not authoritative" and when I go
to nslookup on the secondary the queries say "Not authoritative"....I
thought it was suppose to do that because it pulls from the primary so I
didn't think that was an issue.

The last message was just just the slave was improperly configured to slave
the 0.0.12.in-addr.arpa...from the master.  I just changed that so it was
the master of that particular zone....not of anything material.

> Try something!  On your slave, run "dig @207.168.174.130 comcity.com
> axfr".  If you get a listing of the comcity.com zone, then zone
> transfers CAN function from your master to your slave and the problem
> will lie with the configuration of your slave.

That seems to work...heres the dig.

; <<>> DiG 8.3 <<>> @207.168.174.130 comcity.com axfr
; (1 server found)
$ORIGIN comcity.com.
@   1H IN SOA ns hostmaster (
     2004042001 ; serial
     1H  ; refresh
     15M  ; retry
     1W  ; expiry
     1H )  ; minimum

   1H IN NS ns
   1H IN NS ns2
   1H IN A  209.66.93.9
   1H IN MX 10 mail
   1H IN MX 50 mail2

dns   1H IN A  207.168.174.130
ns2   1H IN A  209.10.62.39
mail   1H IN A  209.66.93.2
ns   1H IN A  207.168.174.130
localhost  1H IN A  127.0.0.1
www   1H IN A  209.66.93.9
;; and about a couple hundred more A records
@   1H IN SOA ns hostmaster (
     2004042001 ; serial
     1H  ; refresh
     15M  ; retry
     1W  ; expiry
     1H )  ; minimum

;; Received 378 answers (378 records).
;; FROM: sake to SERVER: 207.168.174.130
;; WHEN: Wed Apr 21 08:38:14 2004


>  There could be errors
> in the configuration file specifying the wrong

???? missing a word here in your email  (wrong what?  sentence got
truncated)

> If you do NOT get a listing of the comcity.com zone, then zone
> transfers CANNOT function from your master to your slave and the
> problem should lie with either the configuration of the master or the
> networking between the master and slave.
>
> As Jim Reid pointed out, the configuration of the 0.0.127.in-addr.arpa
> zone on the master or the slave is immaterial to your problem.  You
> should not be spending any time trying to troubleshoot this issue when
> your comcity.com zone isn't working.  In fact, all DNS servers are
> supposed to be masters for the 0.0.127.in-addr.arpa zone anyway.  You
> should not have this zone configured as a slave in the first place.

I was fixing it....  I didn't set it up that way.  Just trying to find all
the needles in the hairstacks.

> So, try running the dig command on your slave that I identified.  You
> need to find out if the zone transfers are possible at all before you
> worry about why they aren't working.
>
> You should be able to run the "named-checkconf" on both your master and
> slave servers to check that the configuration is correct.  There is
> also a "named-checkzone" that can check your zone files to insure that
> they are reasonable (not that the information is correct, but that the
> files are syntactically correct).  I am assuming that these
> "named-checkzone" and "named-checkconf" utilities are available with
> the Unix versions of BIND, and am assuming that they are also available
> with the Windows version also.  If not, I would be more than happy to
> run them for you on my system and send you the results by mail.

Hmm, no unfortunately we don't seem to get those files distributed in the
normal port.

> Finally, and actually this should be the first thing that you look at,
> check your system logs.  Since you are running under Windows, I am
> assuming that these logs will show up as part of the system's "Event
> Log", but this is only a guess.  You could also add some additional
> logging directives to your named.conf file to force the logging to be
> recorded to files and then review the files.  Whatever you do, you need
> to find out what the system, and named, are telling you when named
> tries to run.

There are no real errors in the system Event logs.  I believe all of the
logging goes into the windows logs.....thats were they have always gone to
in the past on all the windows ports I've run.  I'll need to read into the
additional logging directives for named.conf but everything looks to be
working.  This could be a firewall issue of some kind....although on the
surface I don't know how.  Both the primary and secondary are in the same
VPN and behind the firewall....seems to be everything would stop working
completely if that were the case.

What exactly in the significance of saying the secondary is not
authoritative....what metric are you using to measure this and come to that
conclusion?

> Bill Larson
>