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

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!

share|improve this question
    
Stupid questions: Did you add the zone to the named.conf? Did you check the bind logs? –  Craig Mar 31 '10 at 16:38
    
try telling us what you do get, as well as what you didn't? –  Alnitak Mar 31 '10 at 16:58
    
I hope I added some useful info. Please check my edits. Thanks! –  d-_-b Mar 31 '10 at 23:29
    
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. –  James Sneeringer Apr 1 '10 at 15:24
add comment

3 Answers

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|improve this answer
    
OK, I hope I read you right. I've made the changes and I now get an authority section from when digging from my server and my laptop, but still no answer. Please see my edit. Thanks for your help! –  d-_-b Mar 31 '10 at 23:44
    
BTW, I see some examples and docs use IN and other do not. What gives? –  d-_-b Mar 31 '10 at 23:50
    
IN (Internet) is normally the default DNS record class. In most cases, it is optional in zone files and named.conf. –  James Sneeringer Apr 1 '10 at 4:59
add comment

What happens if you request a specific record type?

dig @mega.dude mega.dude. a
dig @mega.dude mega.dude. ns
dig @mega.dude mega.dude. mx

Have you tried dig's +trace option? It will show the whole delegation path, which may help you figure out where the query is breaking down.

dig mega.dude. +trace
share|improve this answer
    
Yup, I have that in /etc/resolv.conf I didn't know you could look up specific records like that. Cool! –  d-_-b Apr 1 '10 at 6:48
    
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' ... ? –  Alnitak Apr 1 '10 at 7:48
    
Altinak - Ahh crud, good point, I was thinking of "host". I'll remove that from my response so as not to confuse anyone. –  James Sneeringer Apr 1 '10 at 14:19
    
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 .... –  Alnitak Apr 1 '10 at 14:36
    
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. –  James Sneeringer Apr 1 '10 at 15:20
add comment
up vote 0 down vote accepted

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!

share|improve this answer
add comment

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.