RHEL5 - Bind doesn't return IPv6 records
I've got two DNS resolvers:
RHEL5 - BIND 9.7.0-P2-RedHat-9.7.0-17.P2.el5_9.2RHEL6 - 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
Solution 1:
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.