domains going into "non-authoritative" mode

Invader Zim

Verified User
Joined
Sep 4, 2004
Messages
188
Domains that worked fine suddenly get listed as "non-authoritative".

Any way of explaining this? Or better yet, resolving it?
 
And what do you mean by "non authoritative mode"?

What command are you running?

And what is it saying?

Jeff
 
Not running any command. I keep having to nuke the zone file and start over. And with a zone with 25 entries that gets to be a pain in the you-know-what.
 
If you're not running any command how do you know you're 'going into "non-authoritative" mode'?

What do you mean by "non-authoritative" mode?

What specifically has broken that requires you to recreate the zone files?

Jeff
 
sorry it's taken me so long to get back on this, but i've been very busy with other things.

let me give you an example.

last january we created a new domain budgetwebsite.net. the zone file is the standard generated one. nothing was added or removed, and it worked like a charm. this morning however, i noticed the following line in ns2's syslog:

May 12 12:17:08 reaper named[1455]: zone budgetwebsite.net/IN: refresh: non-authoritative answer from master 83.149.67.24#53 (source 0.0.0.0#0)

mind that nothing has changed in the mean time (except for the increase in hosted domains). this (domains suddenly complaining about non-auth answers) will happen about once a week, but always with another domain. the only thing that resolves the situation is nuke the zone file (and it's entry in the bind's cfg) off ns2, remove the zone from DA, restart ns1 and ns2, recreate the zone on DA, recreate the slave entry on ns2, restart nd1 and ns2.

May 12 12:43:26 reaper named[1455]: zone budgetwebsite.net/IN: saved '/var/named/budgetwebsite.net.hosts' as '/var/named/db-7YPDDaWe'
May 12 12:43:26 reaper named[1455]: zone budgetwebsite.net/IN: Transfer started.
May 12 12:43:26 reaper named[1455]: transfer of 'budgetwebsite.net/IN' from 83.149.67.24#53: connected using 195.64.94.113#36147
May 12 12:43:26 reaper named[1455]: zone budgetwebsite.net/IN: transferred serial 2005051200
May 12 12:43:26 reaper named[1455]: transfer of 'budgetwebsite.net/IN' from 83.149.67.24#53: end of transfer
May 12 12:43:26 reaper named[1455]: zone budgetwebsite.net/IN: sending notifies (serial 2005051200)


now this isn't a really big problem cuz most of the zone files are the default generated ones, but we do have a few zone files that have considerably more entries.

(obviously, reaper is ns2)
 
Last edited:
Only two ways this could happen:

1) somehow your /etc/named.conf file is being changed to have a "slave" configuration instead of a "master" configuration; to see if that's happening, grep the file for the word slave:

grep slave named.conf

(it shouldn't return anything)

2) your registrar is somehow changing it's records of your authorized nameserver.

Jeff
 
jlasman said:
Only two ways this could happen:

1) somehow your /etc/named.conf file is being changed to have a "slave" configuration instead of a "master" configuration; to see if that's happening, grep the file for the word slave:

grep slave named.conf

(it shouldn't return anything)
there's only 2 instances of "slave" appearing:

Code:
/*
zone "domain.com" {
        type slave;
        file "s/domain.com.bak";
        masters {
                192.168.1.1;
        };
};

zone "0.168.192.in-addr.arpa" {
        type slave;
        file "s/0.168.192.in-addr.arpa.bak";
        masters {
                192.168.1.1;
        };
};
*/


jlasman said:
2) your registrar is somehow changing it's records of your authorized nameserver.
if only it were that simple. but then there'd have to be someone at the registrar continuously querying my nameservers to see when i nuke & recreate the zones. so i don't think that's a realistic scenario.

in the meantime, it has happened to 4 other zones. it's really getting tiresome.
 
When I test your budgetwebsite.net domain, everything appears to work properly.

When I do a test at DNS Report, everything looks good there as well (except for the missing reverse DNS for the mx record).

So if you're still having problems I'd say it's time to query the folk on the bind-users list; they're quite knowledgeable and at least a few of them work for the company that created BIND.

Jeff
 
jlasman said:
When I test your budgetwebsite.net domain, everything appears to work properly.
I know. It's because I nuked and recreated the zone file.

jlasman said:
(except for the missing reverse DNS for the mx record).
We do not own the netblock, and the one who does doesn't feel like adding reverse pointers.
 
If they refuse to create reverse DNS records, and refuse to delegate it to you so you can, then you'll find that a lot of email from your server will be blocked.

A lot.

And more every day, as more ISPs and other email administrators require reverse DNS to work for email delivery.

Jeff
 
continuation. dnsreport says the following:

FAIL Lame nameservers ERROR: You have one or more lame nameservers. These are nameservers that do NOT answer authoritatively for your domain. This is bad; for example, these nameservers may never get updated. The following nameservers are lame:
83.149.67.24

And yes, that's the directadmin machine.
 
Does your DA server have zones for these domains?

Do the whois records for these domains show the DA nameservers?

Do the zone files show these nameservers, or others either in addition to or instead of these?

Any additional effort to help will require you to tell us real domain names so we can do testing.

Jeff
 
Does your DA server have zones for these domains?
Yes, it does. It's the authoritative nameserver, the master, for all our zones.

Do the whois records for these domains show the DA nameservers?
Yes, it does. For all zones.

Do the zone files show these nameservers, or others either in addition to or instead of these?
All zonefiles list both the primary and secondary nameserver in the manner they should.

Any additional effort to help will require you to tell us real domain names so we can do testing.
The zone in question keeps changing. After I fix zone a, zone b becomes the problem. And it's unpredictable as to the sequence as well.

For some reason it is no longer necessary to nuke the zone on the secondary nameserver. Just nuking it on the primary and then recreating it is now enough.
 
The problem vanished a few days after my last post, but it has reappeared again.

Apparently, there's a problem with our nameservers themselves.

Here's an excerpt of our zone file as built by Direct Admin (so not all entries are shown):

Code:
$TTL 14400
@       IN      SOA     ns1.ermis.nl.      root.ermis.nl. (
                                                2005081101
                                                7200
                                                3600
                                                1209600
                                                86400 )

ermis.nl.       14400   IN      NS      ns1.ermis.nl.
ermis.nl.       14400   IN      NS      ns2.ermis.nl.

apollon 14400   IN      A       83.149.67.24
ermis   14400   IN      A       83.149.67.26
ermis.nl.       14400   IN      A       83.149.67.24
ftp     14400   IN      A       83.149.67.24
localhost       14400   IN      A       127.0.0.1
mx      14400   IN      A       83.149.67.24
ns1     14400   IN      A       83.149.67.24
ns2     14400   IN      A       195.64.94.113

ermis.nl.       14400   IN      MX      10 mx

ermis.nl. IN TXT "v=spf1 a mx ip4:83.149.67.24 ?all"

DNS Report informs me that
Code:
ERROR: You have one or more lame nameservers.
These are nameservers that do NOT answer authoritatively
for your domain. This is bad; for example, these
nameservers may never get updated. The following
nameservers are lame:
83.149.67.24

I find it rather funny that our master nameserver thinks it's not authoritative for it's own domain. Anyway, let's continue and see what dnswalk has to say:

Code:
Checking ermis.nl.
Getting zone transfer of ermis.nl. from ns1.ermis.nl...failed
FAIL: Zone transfer of ermis.nl. from ns1.ermis.nl failed: Response code from server: REFUSED
Getting zone transfer of ermis.nl. from ns2.ermis.nl...done.
SOA=ns1.ermis.nl        contact=root.ermis.nl
BAD: ermis.nl NS ns1.ermis.nl: CNAME (to apollon.ermis.nl)
BAD: ermis.nl NS ns2.ermis.nl: CNAME (to reaper.take13.net)
1 failures, 0 warnings, 2 errors.

I really do not understand what the problem is with the ns statements.
 
Check to make sure ermis.nl is properly set up in /etc/named.conf.

Second, make sure your nameservers are properly registered with the domain registry where you've set up your domain.

Jeff
 
jlasman said:
Check to make sure ermis.nl is properly set up in /etc/named.conf.

Second, make sure your nameservers are properly registered with the domain registry where you've set up your domain.

Jeff
If I nuke and recreate the zone file in the same manner, all is well. The problem just transfers to another domain.
 
You're beyond my ability to diagnose in general over a forum.

I suggest you ask the users on the bind-users forum.

Jeff
 
Back
Top