Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 dig gets the glue records:

$ dig @

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

;            IN      A

;; AUTHORITY SECTION:         172800  IN      NS         172800  IN      NS

;; ADDITIONAL SECTION:     172800  IN      A     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
- Standard query NS <Root>
- Standard query response NS ... (lists all the root nameservers)
- Standard query A
- Standard query response A
- Standard query A
- Standard query response 
-- Additional Records
--- type A, class IN, addr
--- type A, class IN, addr

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

- Standard query AAAA
- 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
- 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 @ SOA 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 and names did not have A records in the 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 posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.