1

I've got two DNS resolvers:

  • RHEL5 - BIND 9.7.0-P2-RedHat-9.7.0-17.P2.el5_9.2
  • RHEL6 - BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4

The configuration is exactly the same, both DNS servers are not configured with IPv6 addresses and BIND does not listen for client queries on IPv6.

I wonder why only RHEL6 returns IPv6 records, is there any configuration option related to this:

RHEL5

# dig @RHEL5 example.com NS

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @RHEL5 example.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59564
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 12

;; QUESTION SECTION:
;example.com.           IN  NS

;; ANSWER SECTION:
example.com.        84843   IN  NS  ns01.example.com.
example.com.        84843   IN  NS  ns02.example.com.

;; ADDITIONAL SECTION:
ns01.example.com.   2233    IN  A   192.168.10.10
ns02.example.com.   2233    IN  A   192.168.20.20

;; Query time: 1 msec
;; SERVER: 10.10.1.10#53(10.10.1.10)
;; WHEN: Wed May  7 15:08:33 2014
;; MSG SIZE  rcvd: 464

RHEL6

# dig @RHEL6 example.com NS

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> @RHEL6 example.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59564
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 12

;; QUESTION SECTION:
;example.com.           IN  NS

;; ANSWER SECTION:
example.com.        84843   IN  NS  ns01.example.com.
example.com.        84843   IN  NS  ns02.example.com.

;; ADDITIONAL SECTION:
ns01.example.com.   2233    IN  A   192.168.10.10
ns01.example.com.   171236  IN  AAAA    2001:502:f4gg::1
ns02.example.com.   2233    IN  A   192.168.20.20
ns02.example.com.   171236  IN  AAAA    2410:a1:1024::1

;; Query time: 1 msec
;; SERVER: 10.10.2.10#53(10.10.2.10)
;; WHEN: Wed May  7 15:08:53 2014
;; MSG SIZE  rcvd: 464
Andrew B
  • 33,098
HTF
  • 3,198

1 Answers1

3

When you query a caching DNS server (ra flag set in your response), what you get in the ADDITIONAL section should be considered "best effort" outside of what the RFCs explicitly require a server to do. Some servers disable the ADDITIONAL section entirely except where required by RFC, i.e. BIND's minimal-responses option.

In this scenario, the ADDITIONAL section will contain records that the server is passively aware of, but you cannot consider this information to be exhaustive. It's not going to go out of its way to get the extra data for you because it would be unnecessary work and it has better things to do with its time. AAAA nameserver IPs are not frequently requested and it is common for them to be absent.

Take the following example:

$ rpm -q bind97
bind97-9.7.0-17.P2.el5_9.1
$ dig @localhost +noall +additional serverfault.com
brad.ns.cloudflare.com. 82084   IN      A       173.245.59.105
roxy.ns.cloudflare.com. 6209    IN      A       173.245.58.142
$ dig @localhost +short brad.ns.cloudflare.com AAAA
2400:cb00:2049:1::adf5:3b69
$ dig @localhost +noall +additional serverfault.com
brad.ns.cloudflare.com. 82056   IN      A       173.245.59.105
brad.ns.cloudflare.com. 86397   IN      AAAA    2400:cb00:2049:1::adf5:3b69
roxy.ns.cloudflare.com. 6181    IN      A       173.245.58.142

What I've done here is demonstrate my cache returning an ADDITIONAL section that lacks the AAAA records. I then give the cache a helpful nudge about the existence of one AAAA record, and my subsequent retry pulls down an additional section that contains the AAAA response for that record but not the other.

An authoritative nameserver or a referring nameserver would not be passively populating the ADDITIONAL section.

Andrew B
  • 33,098