This is an unusual situation and a misconfiguration on DNS servers that can be exploited using a simple AAAA DNS query. This causes a localized Denial-of-service situation where users behind a specific resolver will get:
Unable to determine IP address from host name www.somevulnerablesite.com
The DNS server returned: Name Error: The domain name does not exist.
This means that the cache was not able to resolve the hostname presented in the URL.
Check of the address is correct.
Your cache administrator is root.
Some DNS servers respond with an inappropriate error message if queried for nonexistent AAAA records, which can lead to possible denial of service.
Some DNS servers respond with a “Name Error” response code (NXDOMAIN, RCODE 3) instead of “No Error” (RCODE 0) when queried for a nonexistent AAAA record. (AAAA records are used to provide name-to-address resolution for IPv6 addresses, as described in RFC1886.)
When an NXDOMAIN response code is received, the querying resolver will usually stop attempting to resolve that name. Resolvers that support negative caching (RFC2308) and receive an NXDOMAIN response will not query for A records for the same resource until the negatively cached error response has expired.
Sites operating DNS servers that respond to queries for nonexistent AAAA records with NXDOMAIN response codes may be susceptible to attackers using other sites’ caching nameservers to block those other sites’ users from resolving records in domains served by the broken DNS servers. Similar attacks may be possible against caching resolvers if an attacker were able to induce the resolver to look up a nonexistent AAAA record from a server acting in this manner.
This is not a new issue. The NXDOMAIN in response to a AAAA query issue was noted in the (now expired) Internet Draft
There are broken DNS servers that return NXDOMAIN against AAAA queries, when it should return NOERROR with empty return records. When deploying IPv6/v4 dual stack node, it becomes problem because dual stack nodes would query AAAA first, see NXDOMAIN error, and won’t try to query A records. These broken DNS servers need to be corrected.
However, we have not seen this issue documented elsewhere as a potential denial-of-service attack vector against sites with their DNS servers broken in this manner.
An attacker could create a localized denial-of-service condition by exploiting this vulnerability.
Apply a patch from your vendor.
Usually BIND 8.2 or later versions are not affected. However, see below:
|Vendor||Status||Date Notified||Date Updated|
|Cisco Systems Inc.||Affected||21 Mar 2003||23 May 2003|
|F5 Networks||Not||21 Mar 2003||23 May 2003|
|djbdns||Unknown||21 Mar 2003||21 Mar 2003|
|ISC||Unknown||21 Mar 2003||21 Mar 2003|
|Microsoft Corporation||Unknown||21 Mar 2003||21 Mar 2003|
|Openwall GNU/*/Linux||Unknown||21 Mar 2003||21 Mar 2003|
Reproducing NXDOMAIN responses using AAAA queries
This is a proof of concept. Outputs are modified to conceal identities.
Step 1: Check standard A record response
Doing a simple DIG request to resolv2.blackmoreops.com for www.somevulnerablesite.com
Got a response with AUTHORITY: 2.
[user@blackmoreops-resolver2 ~]# dig www.somevulnerablesite.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 150580 ;; flags: ar bd ca; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.somevulnerablesite.com. IN A ;; ANSWER SECTION: www.somevulnerablesite.com. 30 IN A 100.100.100.100 ;; AUTHORITY SECTION: somesite.srd.com. 2705 IN NS loadbalancer1.xyz.com. somesite.srd.com. 2705 IN NS loadbalancer2.xyz.com. ;; ADDITIONAL SECTION: loadbalancer1.xyz.com. 18 IN A 188.8.131.52 loadbalancer2.xyz.com. 191 IN A 184.108.40.206 ;; Query time: 23 msec ;; SERVER: 220.127.116.11#53(18.104.22.168) ;; WHEN: Wed Jan 3 23:04:51 2014 ;; MSG SIZE rcvd: 150
Step 2: Request AAAA response
Doing a simple DIG AAAA request for www.somevulnerablesite.com. Got a NXDOMAIN response with AUTHORITY: 1.
Also note that the AUTORITY changed and we are missing DNS glue. (Additional Section)
Note: This is where it goes wrong, as We just received a NXDOMAIN response from an AUTHORITATIVE server.
This NXDOMAIN is now cached for 20 minutes.
[user@blackmoreops-resolver2 ~]# dig AAAA www.somevulnerablesite.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24603 ;; flags: ar bd ca; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.somevulnerablesite.com. IN AAAA ;; AUTHORITY SECTION: somesite.srd.com. 1200 IN SOA loadbalancer2.xyz.com. hostmaster.removedaddress.com. 2014031841 3600 900 2207600 1200 ;; Query time: 23 msec ;; SERVER: 22.214.171.124#53(126.96.36.199) ;; WHEN: Wed Jan 3 23:05:02 2014 ;; MSG SIZE rcvd: 120
Step 3: Any subsequent DIG requests will give NXDOMAIN responses
Doing a Simple DIG request for www.somevulnerablesite.com
Got a NXDOMAIN response with AUTHORITY: 1.
This happens because an NXDOMAIN takes preferences for both ipv4 and ipv6. (also it’s now cached)
[user@blackmoreops-resolver2 ~]# dig www.somevulnerablesite.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 24179 ;; flags: ar bd ca; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.somevulnerablesite.com. IN A ;; AUTHORITY SECTION: somesite.srd.com. 1196 IN SOA loadbalancer2.xyz.com. hostmaster.removedaddress.com. 2014031841 3600 900 2207600 1200 ;; Query time: 0 msec ;; SERVER: 188.8.131.52#53(184.108.40.206) ;; WHEN: Wed Jan 3 23:05:02 2014 ;; MSG SIZE rcvd: 120
In this particular case, it was a mis-configured F5 GTM (Global Traffic Manager) and the solution was forwarded to the the Network Admin of the vulnerable site.
However, even though F5’s can be synced, you need to configure each F5 (F5 v9 and F5 v10 comes in pair, starting v11, you can have more than two) WIP IPv6 NoError response manually as that part of config is not in the shared directory (i.e. /config).
This is a very simple Denial-of-service attack and extremely tough to detect as DNS is the last place a Network admin would look. This affect Cisco Systems, F5 GTM’s, djbdns, ISC, Microsoft DNS and Openwall GNU/*/Linux DNS servers. In most cases this is caused when the same DNS server is used for a long time and ipv6 is not taken into account. New installation of DNS servers usually encounters it pretty well and in case of a AAAA request, it will send a NOERROR response.
Interestingly, Google seems to be invulnerable to NXDOMAIN caching and responses, I am not sure if Google uses dig +trace to determine a DNS response or if they are breaking RFC by not respecting a NXDOMAIN response from an Authoritative server. Either way, if you’re using Google DNS resolvers, you’re safe. But secured resolvers usually caches a NXDOMAIN responses for 10-20 minutes and by sending this AAAA request, you can make a domain unavailable for all users behind that resolver.
Also know that all the vendors fixed this issue (at least the ones using BIND 8.2 or later), but you get those few older version in the wild sometimes.
- Vulnerability Note VU#714121 – Incorrect NXDOMAIN responses from AAAA queries could cause denial-of-service conditions
- Cisco Systems Inc. Information for VU#714121 – Incorrect NXDOMAIN responses from AAAA queries could cause denial-of-service conditions
- F5 Networks Information for VU#714121 Incorrect NXDOMAIN responses from AAAA queries could cause denial-of-service conditions
- sol7851: Configuring the BIG-IP GTM or Link Controller systems to provide NOERROR responses for IPv6 queries
- ISC BIND AAAA denial of service (DNS_Bind_AAAA_RPZ_DoS)
- ISC BIND DNS64 Nameserver Response Policy Zone AAAA Record Query Remapping Remote DoS Vulnerability
- DNS Best Practices, Network Protections, and Attack Identification