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 @ ns1.teamsystem.com

; DiG 9.3.6-P1-RedHat-9.3.6-20.P1.el5 @ 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

;ns1.teamsystem.com.            IN      A

teamsystem.com.         172800  IN      NS      ns1.teamsystem.com.
teamsystem.com.         172800  IN      NS      ns2.teamsystem.com.

ns1.teamsystem.com.     172800  IN      A
ns2.teamsystem.com.     172800  IN      A

;; Query time: 100 msec
;; 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
- Standard query A ns1.teamsystem.com
- Standard query response 
-- Additional Records
--- ns1.teamsystem.com: type A, class IN, addr
--- ns2.teamsystem.com: type A, class IN, addr

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 @ teamsystem.com SOA  
ns.teamsystem.com. postmaster.teamsystem.com. 1 3600 600 86400 3600
  • 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
  • 1
    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 '14 at 14:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.