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.

We have a problem with some caching nameservers running BIND on CentOS in that they appear to be acting incorrectly and not properly handling the 'Additional Records' which contain the glue records. When asking d.gtld-servers.net dig gets the glue records:

$ dig @192.31.80.30 ns1.teamsystem.com

; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5 @192.31.80.30 ns1.teamsystem.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 48270
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;ns1.teamsystem.com.            IN      A

;; AUTHORITY SECTION:
teamsystem.com.         172800  IN      NS      ns1.teamsystem.com.
teamsystem.com.         172800  IN      NS      ns2.teamsystem.com.

;; ADDITIONAL SECTION:
ns1.teamsystem.com.     172800  IN      A       2.115.99.97
ns2.teamsystem.com.     172800  IN      A       2.115.99.98

;; Query time: 100 msec
;; SERVER: 192.31.80.30#53(192.31.80.30)
;; WHEN: Mon Aug  6 10:22:54 2012
;; MSG SIZE  rcvd: 100

I'm wondering if it's the domain itself or something we have incorrectly configured.The following is a paraphrased tcpdump.

# dig +trace ns1.teamsystem.com
- Standard query NS <Root>
- Standard query response NS ... (lists all the root nameservers)
- Standard query A d.gtld-servers.net
- Standard query response A 192.31.80.30
- Standard query A ns1.teamsystem.com
- Standard query response 
-- Additional Records
--- ns1.teamsystem.com: type A, class IN, addr 2.115.99.97
--- ns2.teamsystem.com: type A, class IN, addr 2.115.99.98

At this point, dig begins using nameservers from /etc/resolv.conf to get the AAAA of ns1.teamsystem.com

- Standard query AAAA ns1.teamsystem.com
- Standard query response, Server failure

We have 3 nameserver entries, so it tries them all, receiving the same failure. It then retries with the A record request.

- Standard query A ns1.teamsystem.com
- Standard query response, Server failure

This proves that BIND, on our resolvers, is unable or unwilling to follow on with the glue records that are clearly available in the Additional Records section.

The only problem we can find with the zone is that the SOA doesn't match the nameservers in the glue records:

$ dig +short @2.115.99.98 teamsystem.com SOA  
ns.teamsystem.com. postmaster.teamsystem.com. 1 3600 600 86400 3600
share|improve this question
    
In fact, the SOA lists a non-existent name server. The DNS specification explicitly states that the primary master server be named here. However, the only thing I know of that actually uses it is sending dynamic updates, which obviously isn't happening here. In fact, doing it this way is sometimes use for a hidden master scheme. It shouldn't cause your issue. –  David Schwartz Aug 6 '12 at 10:21
    
This is way late but I can only assume that the problem must have been that the ns1.teamsystem.com and ns2.teamsystem.com names did not have A records in the teamsystem.com zone (maybe it had entirely different NS records)? The delegation (NS + glue A/AAAA) should always match the actual authoritative data. –  Håkan Lindqvist Jul 22 at 14:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.