BIND’s DNS resolver decided it couldn’t reach the authoritative nameserver for example.com when asked for its AAAA record, meaning it couldn’t tell clients where to find example.com over IPv6.
Cause 1: Missing AAAA Record for the Nameserver Itself
Diagnosis: Check the zone file for your nameserver’s domain. For example, if your nameserver is ns1.example.com, you need an AAAA record for ns1.example.com in the example.com zone.
dig @<your_master_dns_server> ns1.example.com AAAA +short
Fix: Add an AAAA record for your nameserver in its own zone file.
; example.com zone file
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
86400 ; minimum TTL
)
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
ns1 IN A 192.0.2.10
ns1 IN AAAA 2001:db8::10 ; <-- Add this line
ns2 IN A 192.0.2.11
ns2 IN AAAA 2001:db8::11
Why it works: The glue record (the AAAA record for ns1.example.com) is what the parent zone (.com) provides to the resolver so it knows how to reach ns1.example.com over IPv6. Without it, the resolver can’t even start the delegation process.
Cause 2: Missing Glue AAAA Record in the Parent Zone
Diagnosis: When a resolver queries for example.com, the .com TLD nameservers will respond with the NS records for example.com and also the glue records (A and AAAA records) for those NS records. You need to ensure these glue records are present in the .com zone for your nameservers.
dig @a.gtld-servers.net example.com NS +noquestion +nostats +nocomments
Look for the nsset section. Then query for the AAAA record of one of your nameservers directly from the .com servers.
dig @b.gtld-servers.net ns1.example.com AAAA +noquestion +nostats +nocomments
Fix: You need to add the AAAA record for your nameserver (ns1.example.com) to the parent zone’s configuration. This is usually done through your domain registrar’s control panel. The registrar is responsible for updating the TLD nameservers.
Why it works: The glue record is what the parent zone (.com) gives to the resolver so it knows how to reach the child zone’s (example.com) nameservers. If the resolver needs to reach ns1.example.com over IPv6, it needs that AAAA glue record from the .com zone.
Cause 3: Incorrectly Configured Glue Record in Parent Zone
Diagnosis: Similar to Cause 2, but the AAAA record might exist in the parent zone but point to the wrong IP address.
dig @b.gtld-servers.net ns1.example.com AAAA +short
Compare the returned IP address with the actual IPv6 address of ns1.example.com.
Fix: Correct the AAAA glue record via your domain registrar’s interface.
Why it works: The resolver uses the glue record provided by the parent zone to initiate the connection to the authoritative nameserver. If the IP address is wrong, the connection will fail.
Cause 4: BIND Not Listening on the IPv6 Address
Diagnosis: Check if your BIND process is configured to listen on the IPv6 address you expect.
netstat -tulnp | grep named
or
ss -tulnp | grep named
You should see a line indicating BIND is listening on [::]:53 (all IPv6 addresses on port 53) or a specific IPv6 address.
Fix: Add or modify the listen-on-v6 directive in your named.conf file.
options {
directory "/var/cache/bind";
// ... other options ...
listen-on-v6 { any; }; // Or a specific IPv6 address like 2001:db8::10;
// listen-on { 127.0.0.1; 192.0.2.10; }; // If you also want IPv4
};
Then reload BIND.
rndc reload
Why it works: BIND needs to be explicitly told to bind to an IPv6 address for the DNS service to be accessible over IPv6. any means it will listen on all available IPv6 interfaces.
Cause 5: Firewall Blocking IPv6 DNS Traffic
Diagnosis: Check your server’s firewall rules.
sudo iptables -L -n -v
sudo ip6tables -L -n -v
Look for rules that might drop or reject incoming traffic on UDP/TCP port 53 for IPv6.
Fix: Add rules to allow incoming IPv6 traffic on port 53.
sudo ip6tables -A INPUT -p udp --dport 53 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 53 -j ACCEPT
If you are using firewalld:
sudo firewall-cmd --permanent --add-service=dns --zone=public
sudo firewall-cmd --reload
Why it works: Even if BIND is listening and the glue records are correct, network-level firewalls can prevent the actual communication from happening.
Cause 6: Incorrect AAAA Record for the Hostname Itself
Diagnosis: The most straightforward check: is the AAAA record for the hostname you’re trying to resolve actually present and correct in the authoritative zone file?
dig @ns1.example.com example.com AAAA +short
If this returns nothing or the wrong IP, that’s the problem.
Fix: Add or correct the AAAA record in the example.com zone file.
; example.com zone file
@ IN SOA ns1.example.com. admin.example.com. (
2023102701 ; serial
3600 ; refresh
1800 ; retry
604800 ; expire
86400 ; minimum TTL
)
@ IN NS ns1.example.com.
@ IN NS ns2.example.com.
www IN A 192.0.2.100
www IN AAAA 2001:db8:100::100 ; <-- Corrected/Added AAAA record
Reload BIND.
rndc reload
Why it works: This is the ultimate destination. If the AAAA record for example.com (or www.example.com, etc.) is missing or points to the wrong place, clients won’t be able to reach the service via IPv6.
The next error you’ll likely encounter is a SERVFAIL response if the DNSSEC validation fails due to misconfigured trust anchors or signatures.