still slave ns problems...

[Joseph S D Yao]

On Thu, Jul 06, 2000 at 03:21:47PM -0500, Carl Brock Sides wrote:
> 
> * david johnson <davjohn at attglobal.net> [000706 15:07]:
> 
> > Well, this is a follow-up to my previous post... In short, the slave ns
> > will not update itself.  I've tried to force it with restarts and reload
> > of the named daemon, but that fails.  All my config files are correct as
> > far as I know, but this time, you can see them all:
> 
> [snip]
> 
> > db.pcprosmn:
> > 
> > @  IN   SOA  squid.pcprosmn.com.  root.squid.pcprosmn.com. (
> >                200007063; serial
> > 	       200; refresh
> > 	       200; should be 3600
> > 	       604800; expire
> > 	       86400; default ttl
> > 	       )
> >                IN       NS         ns1.pcprosmn.com.
> > 	       IN       NS         ns2.pcprosmn.com.
> 
> There needs to be an @ at the beginning of the NS lines. Otherwise, the
> slave will not recognize the master as authoritative.

No, that is not true.  With no LHS, 'named' will use the last LHS of an
RR.  In the above case, that is "@".

However, you have zoomed in on two lines that have problems anyway.
They list "ns1" and "ns2" as name servers.  But there are no "A"
records for "ns1" and "ns2"!  Instead, "ns1" and "ns2" are aliases, and
their CNAMEs are squid and hydra.

I do not remember whether it is just a Very Bad Idea, or something that
is Absolutely Wrong And Will Make Things Fail, but name servers should
not be given as aliases.  You should use the canonical names - in this
case, squid and hydra.  I also don't know whether that will make the
master/slave relationship work, but you should try it.

This has probably been mentioned in this thread before, but I can't
resolve name server or any other type of RR for "pcprosmn.com."  I just
checked to see whether the name servers were registered with the NIC as
ns1/ns2 or squid/hydra.  Apparently, this is not yet a problem.  ;-)

-- 
Joe Yao				jsdy at cospo.osis.gov - Joseph S. D. Yao
COSPO/OSIS Computer Support					EMT-B
-----------------------------------------------------------------------
This message is not an official statement of COSPO policies.