DNS resolution problems; dig SERVFAIL error

Question

I'm setting up a couple of dedicated servers, and having problems setting up my nameservers properly. One of these is a LEMP server (LAMP with nginx in place of Apache), and the other will function solely as an email server, running exim/dovecot/ASSP antispam (no Apache). The LEMP server is CentOS 5.5, with no control panel, while the email server is CentOS 5.5 as well, with cPanel/WHM.

So, I've had problems getting DNS set up properly. I have two domains, each one pointing to one of these servers. The nameservers are registered correctly with the domain registrar, and the nameserver IPs are entered correctly as well. I've spoken to tech support at the registrar and they confirm that everything is set up on their end. Not knowing much about DNS, I googled nameservers and DNS until I nearly went blind, and spent hours messing with the configuration.

Eventually, I got the LEMP server's DNS working properly (no cPanel). Pleased with this triumph, I'm trying to mimic that configuration and repeat the process with the email server, and it's just not happening. The nameserver starts and stops, but the domain doesn't resolve.

Things I have tried
Going through standard procedures to set up DNS in WHM Clearing all DNS information, uninstalling BIND, then reinstalling all of that and again going through WHM procedures for setting up DNS Clearing all DNS information, and setting up BIND via shell (completely outside of cPanel) by using my config and zone files from the LEMP server as a template

named runs just fine, but nothing is resolving. When I "dig any example.com" I get a SERVFAIL message. Nslookups return no information.

Here are my config and zone files.

named.conf

controls {
        inet 127.0.0.1 allow { localhost; }
        keys { coretext-key; };
};
options {
        listen-on port 53 { any; };
        listen-on-v6 port 53 { ::1; };
        directory       "/var/named";
        dump-file       "/var/named/data/cache_dump.db";
        statistics-file "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";

        // Those options should be used carefully because they disable port
        // randomization
        // query-source    port 53;
        // query-source-v6 port 53;

        allow-query     { any; };
        allow-query-cache { any; };
};
logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };
};
view "localhost_resolver" {
        match-clients      { 127.0.0.0/24; };
        match-destinations { localhost; };
        recursion yes;

        //zone "." IN {
        //      type hint;
        //      file "/var/named/named.ca";
        //};

        include "/etc/named.rfc1912.zones";
};
view "internal" {
/* This view will contain zones you want to serve only to "internal" clients
   that connect via your directly attached LAN interfaces - "localnets" .
*/
    match-clients        { localnets; };
    match-destinations    { localnets; };
    recursion yes;

    zone "." IN {
        type hint;
            file "/var/named/named.ca";
    };

    // include "/var/named/named.rfc1912.zones";
    // you should not serve your rfc1912 names to non-localhost clients.

    // These are your "authoritative" internal zones, and would probably
    // also be included in the "localhost_resolver" view above :
        zone "example.com" {
                type master;
                file "data/db.example.com";
        };
        zone "3.2.1.in-addr.arpa" {
                type master;
                file "data/db.1.2.3";
        };
};
view "external" {
/* This view will contain zones you want to serve only to "external" clients
 * that have addresses that are not on your directly attached LAN interface subnets:
 */
        match-clients           { any; };
        match-destinations      { any; };

        recursion no;
        // you'd probably want to deny recursion to external clients, so you don't
        // end up providing free DNS service to all takers

        allow-query-cache { none; };
        // Disable lookups for any cached data and root hints

        // all views must contain the root hints zone:
        //include "/etc/named.rfc1912.zones";

        zone "." IN {
                type hint;
                file "/var/named/named.ca";
        };
        zone "example.com" {
                type master;
                file "data/db.example.com";
        };
        zone "3.2.1.in-addr.arpa" {
                type master;
                file "data/db.1.2.3";
        };
};

include "/etc/rndc.key";

db.example.com

$TTL 1D
;
; Zone file for example.com
;
; Mandatory minimum for a working domain
;
@       IN  SOA ns1.example.com. contact.example.com. (
                2011042905 ; serial
                8H ; refresh
                2H ; retry
                4W ; expire
                1D ; default_ttl
        )

                NS      ns1.example.com.
                NS      ns2.example.com.

ns1             A       1.2.3.4
ns2             A       1.2.3.5

example.com.            A       1.2.3.4

localhost               A       127.0.0.1

www                     CNAME   example.com.
mail                    CNAME   example.com.
;

db.1.2.3

$TTL 1D
$ORIGIN 3.2.1.in-addr.arpa.

@       IN      SOA     ns1.example.com  contact.example.com.   (
                        2011042908 ;
                        8H      ;
                        2H      ;
                        4W      ;
                        1D      ;
                )

                NS      ns1.example.com.
                NS      ns2.example.com.

4               PTR     hostname.example.com.
5               PTR     hostname.example.com.
;

Also of note: both of these servers are managed. Tech support is very responsive, and largely useless. Hours go by with them asking me questions to narrow down what could be wrong, then they pass the ticket to the tech on the next shift, who ignores everything that's happened already and spend his whole shift asking all the same questions the last guy asked.

So, in summary:

• Nameservers, with IPs, are correctly registered with domain registrar
• named is configured and running ...and must not be configured
• correctly, because nothing resolves.

Any help would be great. I changed domains and IPs in the files to generics, but let me know if you need to know the domain in question.

Thanks!

UPDATE

I found that I didn't have 127.0.0.1 in /etc/resolv.conf, so I added it, along with my two public IPs that I have named listening on.

resolv.conf

search www.example.com example.com
nameserver 127.0.0.1
nameserver 7.8.9.10   ;Was in here by default, authoritative nameserver of hosting company
nameserver 1.2.3.4    ;Public IP #1
nameserver 1.2.3.5    ;Public IP #2

Now when I DIG example.com from the host, it resolves. If I try to DIG from my other server (in the same datacenter), or from the internet, it times out or I get SERVFAIL.

Solution

I'd start with verifying, that your server runs:

netstat -an | grep ^udp | grep 53

It should show a line similar to

udp        0      0 0.0.0.0:53                0.0.0.0:*

If named doesn't run, then stop it (just to clean up), then start and see what it writes to log files (/var/log/messages, /var/named/data/named.run). There may be some typo that prevents the daemon from starting successfully.

Then I'd strip as much as I could from the named.conf. Minimal, basic config should be easier to troubleshoot. Then I'd add entries bit by bit, to see, which entry causes the server to balk.

Also try separately to resolve things locally from the server, and from a client outside. I hope you'll find what's wrong.

Comments

[Alnitak]

please don't mix recursive and authoritative DNS in the same server instance...

[JustinP]

Thanks for that. named is running, when I run that netstat command I get several lines similar to that (one with 127.0.0.1, and one for each of my two public IPs). I found that I didn't have an entry in /etc/resolv.conf for localhost, so I added one. Now when I run: dig any example.com from the server itself, it resolves just fine. If I dig from my other server (with the same hosting company), it either times out, or I get SERVFAIL again.

[JustinP]

Yes, the example.com is the same for ns1 and www. A whois lookup on the domain only lists ns1/ns2.example.com, no IPs, but a lookup on my working nameserver (as well as google.com) doesn't return any IPs either. I confirmed with the registrar that they have the correct IPs associated with my nameservers. Here's are the relevant lines for output from dig [email protected]: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41943 ;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2011042900 1800 900 604800 86400

[DerfK]

@JustinP You need a space before the @. @w.x.y.z tells dig to use a specific nameserver instead of whichever one you've got in resolv.conf. Also check @1.2.3.5.

[JustinP]

@DerfK When I add the space, I get no response for either of the IPs (or a SERVFAIL). Sounds like my firewall is maybe blocking it?

[DerfK]

@JustinP sounds like it. Check iptables, and if you have a hardware firewall, check that too. Remember that DNS uses both UDP and TCP and needs the port open on both protocols.

[JustinP]

@DerfK Haven't used iptables before, not sure what to look for; I had it look at all chains and the data dump was more than I could make sense of. Using netstate and lsof though, I looked at what ports were open on each of my servers (the one with the successful DNS config, and the problematic one). named on the successfully config'd server has 10 ports open; on the other one, it has 9. The port that's not open on the problematic server is: TCP [::1]:953 (LISTEN) Config files for each server are exactly the same (save for the NS names and IPs)....

[Paweł Brodacki]

Try dig host.example.com @127.0.0.1 -- now you force the local DNS server to resolve it and it verifies that named works. Next step: verify that UDP port 53 is reachable from the outer world -- try UDP ping or nmap scan to see if your named is reachable from outside. If it is, then there's something wrong with query permissions.

[Paweł Brodacki]

@JustinP run dig with +trace option, it will show you whether there is problem with delegation -- you'll see each step of name resolution from the root servers down.

[Peter]

You need TCP only for zone transfers. UDP is sufficient for simple caching (but not for EDNS/Signed domains).