3

I have a RHEL 5.7 server running bind-9.3.6-16.P1.el5. At seemingly random points during the day, the DNS will fail to resolve hosts on the LAN for about ten seconds. WAN hosts always resolve. Then it goes back to working fine. I have logging enabled and there are no errors in the logs. Total devices using this DNS server are about 50; its not under heavy load. I have multiple views set up in the configuration.

I used the system-config-bind RHEL tool to configure this. My suspicion is that this tool added something to the configuration that "Refreshes" or "Performs maintenance" at some interval, or some configuration piece that doesn't and that is when the LAN hosts are unresolvable.

// Red Hat BIND Configuration Tool
// 
// Default initial "Caching Only" name server configuration
//


    logging {
    channel "custom" {
        syslog local0;
        severity dynamic;
        print-category yes;
        print-severity yes;
        print-time yes;
    };
    category lame-servers {
        custom;
    };
    category xfer-in {
        custom;
    };
    category xfer-out {
        custom;
    };
    category network {
        custom;
    };
    category dnssec {
        custom;
    };
    category database {
        custom;
    };
    category default {
        custom;
    };
    category dispatch {
        custom;
    };
    category general {
        custom;
    };
    category client {
        custom;
    };
    category notify {
        custom;
    };
    category resolver {
        custom;
    };
    category queries {
        custom;
    };
    category security {
        custom;
    };
    category config {
        custom;
    };
    category delegation-only {
        custom;
    };
    };
















    options {


    querylog yes;
    dnssec-enable yes;
    directory "/var/named";
    dump-file "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";

    forwarders { 8.8.8.8; 8.8.4.4; }; // ISP primary/secondary


    /*
     * If there is a firewall between you and nameservers you want
     * to talk to, you might need to uncomment the query-source
     * directive below.  Previous versions of BIND always asked
     * questions using port 53, but BIND 8.1 uses an unprivileged
     * port by default.
     */
     // query-source address * port 53;
      };




    view "chill" {
    match-clients {
    192.168.3.0/24;
    };
    zone "2.168.192.IN-ADDR.ARPA." IN {
    type master;
    file "192.168.2.db";
    };
    zone "laptop." IN {
    type master;
    file "laptop_0.db";
    };

    zone "media." IN {
    type master;
    file "media_1.db";
    };
    zone     "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." IN {
        type master;
    file "chill_named.ip6.local";
    allow-update { none; };
    };
    zone "255.in-addr.arpa." IN {
    type master;
    file "chill_named.broadcast";
    allow-update { none; };
    };
    zone "0.in-addr.arpa." IN {
    type master;
    file "chill_named.zero";
    allow-update { none; };
    };
    zone "localhost." IN {
    type master;
    file "chill_localhost.zone";
    allow-update { none; };
    };
    zone "." IN {
    type hint;
    file "chill_named.root";
    };

    match-destinations {
    any;
};
};
view "media" {
    match-clients {
    192.168.1.0/24;
};






    match-destinations {
    any;
};
    recursion yes;






zone "synbackup." IN {
    type master;
    file "synbackup.db";
};
zone "media." IN {
    type master;
    file "media_0.db";
};
zone "laptop." IN {
    type master;
    file "laptop.db";
};

zone "1.168.192.IN-ADDR.ARPA." IN {
    type master;
    file "192.168.1.db";
};

zone "." IN {
    type hint;
    file "named.root";
};

zone "localdomain." IN {
    type master;
    file "localdomain.zone";
    allow-update { none; };
};

zone "localhost." IN {
    type master;
    file "localhost.zone";
    allow-update { none; };
};

zone "0.0.127.in-addr.arpa." IN {
    type master;
    file "named.local";
    allow-update { none; };
};

zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." IN {
        type master;
    file "named.ip6.local";
    allow-update { none; };
};

zone "255.in-addr.arpa." IN {
    type master;
    file "named.broadcast";
    allow-update { none; };
};

zone "0.in-addr.arpa." IN {
    type master;
    file "named.zero";
    allow-update { none; };
};




};

include "/etc/rndc.key";



Also no errors on the interface:

eth0      Link encap:Ethernet  HWaddr 00:xx:xx:xx:xx:xx  
          inet addr:192.168.1.xx  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::222:19ff:fe65:xxxx/xx Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2109561869 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3527205451 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2120862115404 (1.9 TiB)  TX bytes:4168472739611 (3.7 TiB)
          Interrupt:185 Memory:ec000000-ec012800 

4
  • What are the symptoms of "the DNS will fail to resolve hosts on the LAN for about ten seconds"? Are you getting specific error messages? Are you running diagnostic tools such as "host" or are you getting application errors? Is your network interface configured using DHCP? If so, what's the expiration time on leases?
    – larsks
    Commented Aug 8, 2012 at 16:49
  • DNS fails to resolve LAN hosts unknown host synbackup.media <br> Network is configured to use DHCP from the SonicWall (lease time 1440 minutes - default), but DNS is running from the server.
    – Chris E.
    Commented Aug 8, 2012 at 16:52
  • If you run host against your server when this error is occurring, do you get the same error? That is, if you run host dv.server 192.168.1.xx (where 192.168.1.xx is the address of your nameserver), does it report an error? I don't see a zone entry matching .server in your configuration, but I'll assume that's a typo. Make sure when testing you're using fully qualified hostnames.
    – larsks
    Commented Aug 8, 2012 at 16:55
  • I'll do that and post back next time it goes down. Yes it was a typo.
    – Chris E.
    Commented Aug 8, 2012 at 17:08

1 Answer 1

5

There's a RH KB article which says this happens when the cache expires, but still contains IPv6 information (they're pretty vague in the root cause).

They suggest disabling IPv6 support, if that's an option.

add OPTIONS="-4" to /etc/sysconfig/named

1
  • I think the KB article meant the caching server was trying to perform IPv6 lookups, which were timing out. If anyone else runs into this problem, try a tcpdump and look for 'AAAA' record lookup delays.
    – skohrs
    Commented Aug 8, 2012 at 17:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .