cannot resolve DNS server's own domain name

5,270

Solution 1

I just want to clear this up, in case anyone is wondering. The main problem was with whitespace. However, thanks to all that helped sort out some other of my mistakes. Cheers!

Solution 2

Rather than telling us you didn't get an Answer Section, we would be able to diagnose better if you told us what you did get, as well as the response code.

This would tell us for example whether your server is correctly serving the SOA, or if you're getting some particular error message.

FWIW, the warnings about using an alias (i.e. a CNAME) as the target of an MX or NS records are correct - you shouldn't do that.

I don't see any real config error here, but there are a couple optimisations you can make so that you don't need the real domain name anywhere in the config file:

@       IN SOA    ns1 names ( ... )        
        IN MX 10  mail

Also, the www record should also be an A rather than a CNAME - it's not really a good idea to make www an alias for the $ORIGIN, because than a query for www IN MX? or www IN NS? would return the exact same records as the domain itself, when all you ever really want is the IP address.

You also have two effectively identical records for the main A record listed. That shouldn't break anything, and maybe it's just a copy&paste error?

EDIT Curious that the duplicate A record entry was the problem - possibly the lack of IN qualifier caused a parse failure - your BIND startup logs would tell you that.

Regarding the additional questions - those would be better in a new question, and ideally quoting the actual domain name. We simply can't do effective diagnosis on live DNS issues if you're using dummy data.

EDIT2 I did fix the SOA issue though - the first entry in the SOA is supposed to be the name of the primary name server. See revised example above.

Share:
5,270

Related videos on Youtube

d-_-b
Author by

d-_-b

Updated on September 17, 2022

Comments

  • d-_-b
    d-_-b over 1 year

    I have a DNS server (mega.dude - 123.123.123.123) running bind 9.4. When I:

    dig mega.dude
    

    I get no answer section.

    I have

    nameserver 123.123.123.123
    

    in /etc/resolv.conf

    Here is my zone file:

    $TTL 1W
    @                       IN SOA          mega.dude. names.mega.dude. (
                                            2009081502      ; serial
                                            3H              ; refresh
                                            15M             ; retry
                                            1W              ; expiry
                                            1D )            ; minimum
    
                            NS        ns1
                            NS        ns2
                            MX 10     mail.mega.dude.
    
                            A 123.123.123.123
    @                       A 123.123.123.123
    ns1                     A 123.123.123.123
    ns2                     A 123.123.123.123
    www                     CNAME @
    mail                    A 123.123.123.123
    

    It didn't used to look like this. I read that it's evil to have an mx record pointing to a CNAME. So I changed that. Then I thought maybe that was also the case for NS. So I changed those too. Still no good. The ports are open. I can't figure it out. Oh by the way, all the other zones return fine. But not the servers own domain. So I know I'm doing something stupid.

    EDIT

    Here is the section of my named.conf:

    zone "mega.dude" {
         type master;
         file "pri/mega.dude";
    };
    
    zone "123.123.123.in-addr.arpa" {
            type master;
            notify no;
            file "pri/123.123.123";
    };
    

    Here is the response I get on the server itself:

    $ dig mega.dude
    
    ; <<>> DiG 9.4.3-P1 <<>> mega.dude
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25170
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    
    ;; QUESTION SECTION:
    ;mega.dude.                    IN      A
    
    ;; Query time: 134 msec
    ;; SERVER: 123.123.123.123#53(123.123.123.123)
    ;; WHEN: Thu Apr  1 08:02:54 2010
    ;; MSG SIZE  rcvd: 28
    

    And here is the response from my laptop:

    dig @mega.dude mega.dude
    
    ; <<>> DiG 9.4.2-P2.1 <<>> @mega.dude mega.dude
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 21361
    ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available
    
    ;; QUESTION SECTION:
    ;mega.dude.                    IN      A
    
    ;; Query time: 51 msec
    ;; SERVER: 123.123.123.123#53(123.123.123.123)
    ;; WHEN: Thu Apr  1 08:20:19 2010
    ;; MSG SIZE  rcvd: 28
    

    The queries.log has:

    01-Apr-2010 08:02:54.192 client 123.123.123.123#33160: query: mega.dude IN A +
    

    Anywhere else I should check?

    EDIT

    I've made the changes suggested by Alnitak - at least I think I understood:

    $TTL 1W
    @                       IN SOA          mega.dude. names.mega.dude. (
                                            2009081502      ; serial
                                            3H              ; refresh
                                            15M             ; retry
                                            1W              ; expiry
                                            1D )            ; minimum
    
                            IN NS        ns1
                            IN NS        ns2
                            IN MX 10     mail
    
                            A 123.123.123.123
    ns1                     A 123.123.123.123
    ns2                     A 123.123.123.123
    www                     A 123.123.123.123
    mail                    A 123.123.123.123
    

    I now get an authority section, but no answer section:

    dig mega.dude
    
    ; <<>> DiG 9.4.3-P1 <<>> mega.dude
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30264
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
    
    ;; QUESTION SECTION:
    ;mega.dude.                    IN      A
    
    ;; AUTHORITY SECTION:
    mega.dude.             86400   IN      SOA     mega.dude. names.mega.dude. 2009081502 10800 900 604800 86400
    
    ;; Query time: 0 msec
    ;; SERVER: 123.123.123.123#53(123.123.123.123)
    ;; WHEN: Thu Apr  1 08:33:50 2010
    ;; MSG SIZE  rcvd: 70
    

    So it turns out the extra record was causing a problem.

    This works:

    @                       A 210.48.255.42
    

    This does not:

                            A 210.48.255.42
    

    I now get a full response:

    $ dig @mega.dude mega.dude
    
    ; <<>> DiG 9.4.3-P1 <<>> @mega.dude mega.dude
    ; (1 server found)
    ;; global options:  printcmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1029
    ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
    
    ;; QUESTION SECTION:
    ;mega.dude.                    IN      A
    
    ;; ANSWER SECTION:
    mega.dude.             604800  IN      A       123.123.123.123
    
    ;; AUTHORITY SECTION:
    mega.dude.             604800  IN      NS      ns1.mega.dude.
    mega.dude.             604800  IN      NS      ns2.mega.dude.
    
    ;; ADDITIONAL SECTION:
    ns1.mega.dude.         604800  IN      A       123.123.123.123
    ns2.mega.dude.         604800  IN      A       123.123.123.123
    
    ;; Query time: 0 msec
    ;; SERVER: 123.123.123.123#53(123.123.123.123)
    ;; WHEN: Thu Apr  1 15:15:58 2010
    ;; MSG SIZE  rcvd: 112
    

    That's great! Just a few oddities...

    I run a test from http://www.checkdns.net/quickcheckdomainf.aspx

    I see two problems:

    1. Master DNS defined by SOA (mega.dude) was not found among NS records.

    2. Domain mega.dude has no MX records, but it has A record for domain. This configuration is not mega.dude

    and on: http://www.mxtoolbox.com/

    I get:

    No records found Reported by ns1.mega.dude on Thursday, April 01, 2010 at 1:09:05 AM (GMT-5)

    It's been over 12 hours since I made the changes. I would think that I did specify an MX record in my zone file. What about the SOA? I'm pretty happy that it's mostly sorted out, but it still looks like I've some problems. It's probably obvious that mega.dude not the actual domain name. I don't feel like getting hacked just yet.

    Sorry to be so long with this question. I guess I should edit it down. Or should close this and post another question?

    Thanks all!

    • Craig
      Craig about 14 years
      Stupid questions: Did you add the zone to the named.conf? Did you check the bind logs?
    • James Sneeringer
      James Sneeringer about 14 years
      For item 1 in your most recent edit, you don't see mega.dude listed with the NS records because you only have ns1.mega.dude and ns2.mega.dude specified as NS records. The authoritative server in the SOA record is not automatically added to the NS list.
  • d-_-b
    d-_-b about 14 years
    BTW, I see some examples and docs use IN and other do not. What gives?
  • d-_-b
    d-_-b about 14 years
    Yup, I have that in /etc/resolv.conf I didn't know you could look up specific records like that. Cool!
  • Alnitak
    Alnitak about 14 years
    1. /etc/resolv.conf isn't used by "dig". 2. how the heck is he supposed to 'dig @mega.dude' if he can't resolve 'mega.dude' ... ?
  • James Sneeringer
    James Sneeringer about 14 years
    Altinak - Ahh crud, good point, I was thinking of "host". I'll remove that from my response so as not to confuse anyone.
  • Alnitak
    Alnitak about 14 years
    I was slightly hasty - dig (and host) do use /etc/resolv.conf if you don't specify a server on the command line. However the second problem still stands even after the edit - you're giving it the very server name that it can't resolve! More likely he should dig @localhost ....
  • James Sneeringer
    James Sneeringer about 14 years
    My version of dig (9.4.3-P4 on Gentoo) opens it (as seen with strace), but doesn't appear to use the specified search domains, because if I do dig unqualified-hostname, the output indicates that dig assumes it is fully-qualified. Regardless, /etc/resolv.conf is only used by the client resolver, not BIND itself. With regard to @mega.dude, I specifically wrote it that way because in sims' own example, he was doing the same thing and getting a response from his server.