Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a BIND 9.6 instance that acts as a caching NS for the whole building and is also authoritative for an internal zone ("example" below):

zone "example" {
    type master;
    file "example";
    update-policy { grant dhcp-update subdomain example. A TXT; };
};

Due to a rogue switch we lost connectivity with the rest of the world, and the NS started answering SERVFAIL; what surprised me was that the server was also unable to respond to queries for the example domain.

What is the reason of this behavior? Shouldn't the NS be able to answer since it has authoritative data?

edit: The rest of the configuration is the standard one shipped with Debian: hints for the root servers and the zones for localhost and broadcast.

share|improve this question
    
It's pre-coffee, but I can't think of a reason this should SERVFAIL for the "example" zone -- anything interesting in your BIND log files? –  voretaq7 Jan 25 '11 at 14:57
    
No, nothing interesting in the logs: just a few reloads that I tried since I was out of ideas... –  Luca Tettamanti Jan 25 '11 at 15:15
3  
Yes, the name server should have answered. I have been in the same situation and "example" still resolved. Without more of your bind and zone configurations it is hard to know what is wrong with your config. –  Mark Wagner Jan 25 '11 at 17:44
    
The rest of the configuration is the standard one shipped with Debian: hints for the root servers and the zones for localhost and broadcast –  Luca Tettamanti Jan 27 '11 at 8:49
    
Just a random guess - was setting up a veeery similar configuration here, and it's definitely pathname related in my case, sticking in an absolute path made the difference. Noting that my logs clearly showed up the file being inacessible however.. –  tanantish Oct 7 '12 at 11:06

1 Answer 1

You can turn up debugging to see if that doesn't directly answer your question. However, I'd suspect that the permissions on your zone file aren't allowing the bind user to read the file.

I define all my logging options in named.logging.conf and then use an include in the main file:

logging {
        channel default_syslog {
                // Send most of the named messages to syslog.
                syslog local2;
                severity debug; 
        };

        channel audit_log {
                // Send the security related messages to a separate file.
                file "/var/named/system/named.log";
                severity debug;
                print-time yes; 
        };

        channel null {
                null;
        };

        category default { default_syslog; };
        category general { default_syslog; };
        category security { audit_log; default_syslog; };
        category config { default_syslog; };
        category resolver { audit_log; };
        category xfer-in { audit_log; };
        category xfer-out { audit_log; };
        category notify { audit_log; };
        category client { audit_log; };
        category network { audit_log; };
        category update { audit_log; };
        category queries { audit_log; };
        category lame-servers { null; }; 

};

and then in named.conf:

root@dnsm02:/etc/bind# grep logging named.conf
include "/etc/bind/named.logging.conf";

Additionally, you don't mention views, but if you have any views defined, then all of your zones must be in defined views.

share|improve this answer
    
The zone file is readable (the server is the only one authoritative for the internal names) and there are no views... I'll see if I can schedule a test to try and reproduce the issue :S –  Luca Tettamanti Feb 4 '11 at 9:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.