NS does not think it is authoritative

[Syed Ali]

Thank you for the pointers.

As it turned out there was a host entry host_name.ccrl.nj.nec.com which was
not liked by BIND and hence it was not considering itself as authoritative.
I changed the host name to be host-name.ccrl.nj.nec.com and it works fine
now. I did not see the error in syslog because my syslog.conf was "not
working properly" so I had to rebuild that first in order to see any BIND
related error message.

(Although this is not an h2n mailing list, would anyone know how to get h2n
to add an MX record for a domain?
The -m options adds MX records for hosts, which I do not want. I have tried
the spcl.options file with an MX record in it for the domain, but that does
not seem to work. The only other option seems to be to give an A record for
my subdomain in my parent domain, and then use the -m option to add an MX
record )


-----Original Message-----
From: Jim Reid [mailto:jim at rfc1035.com]
Sent: Friday, April 21, 2000 7:00 PM
To: syed at ccrl.nj.nec.com
Cc: bind-users at isc.org
Subject: Re: NS does not think it is authoritative


>>>>> "Syed" == Syed Ali <syed at ccrl.nj.nec.com> writes:

    Syed> I am running Bind 8.2.2. pathlevel 5, on Solaris 2.7 and
    Syed> using h2n Rev 1.29.

    Syed> My sub domain has 2 NS records, one for a master and one for
    Syed> a slave name server.  My master server does not seem to
    Syed> think it is the authoritative for my sub domain, even though
    Syed> the slave thinks that it is the authoritative for my sub
    Syed> domain.  Any clue on what I could do to fix this problem?

It would have helped if you'd supplied:
	(a) the domain names
	(b) the names and addresses of your name servers
	(c) your named.conf file(s)
	(d) the relevant zone files
	(e) extracts from the name server's logs

Why do people posting questions to the list routinely omit important
and relevant information like this?

The most likely explanation for your problem is that you've updated
the master zone file with garbage. [Illegal host names, names outside
your zone, names that exist as CNAMEs and other record types, etc,
etc.] That garbage generates syntax errors when the zone file is
loaded and this prevents the master server from successfully loading
the zone. There will be glaringly obvious messages in the logs
indicating these errors. Didn't you check the logs when the new copy
of the zone file was loaded? Another possible explanation is an error
in named.conf, perhaps a mangled zone{} statement. Again, this will be
clearly flagged in the logs.