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.

  • 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... 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. 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 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

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 {

        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.

  • 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 Feb 4 '11 at 9:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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