IPv6 issues: Localized Denial-of-service caused by incorrect NXDOMAIN responses from AAAA queries

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:

Error:
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.

Before you read this article, you should read about AAAA records IPv6 addresses in the Domain Name System. Following section is taken directly from Vulnerability Note VU#714121

Overview

Some DNS servers respond with an inappropriate error message if queried for nonexistent AAAA records, which can lead to possible denial of service.

Description

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.

Note: The same issue occurs with A6 records. However, A6 records (RFC2874) have been deemed “Experimental” by the IETF, with preference being given to AAAA records (RFC3363, RFC3364).

This is not a new issue. The NXDOMAIN in response to a AAAA query issue was noted in the (now expired) Internet Draft
draft-itojun-jinmei-ipv6-issues-00.txt:

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.

Impact

An attacker could create a localized denial-of-service condition by exploiting this vulnerability.

Solution

Apply a patch from your vendor.

Systems Affected

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 200.200.200.200
loadbalancer2.xyz.com. 191 IN A 200.200.200.201
;; Query time: 23 msec
;; SERVER: 221.221.221.221#53(221.221.221.221)
;; 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: 221.221.221.221#53(221.221.221.221)
;; 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: 221.221.221.221#53(221.221.221.221)
;; 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.

F5 Solution

http://support.f5.com/kb/en-us/solutions/public/7000/800/sol7851.html

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).

Conclusion

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.

Useful resources

1. Vulnerability Note VU#714121 – Incorrect NXDOMAIN responses from AAAA queries could cause denial-of-service conditions
2. Cisco Systems Inc. Information for VU#714121 – Incorrect NXDOMAIN responses from AAAA queries could cause denial-of-service conditions
3. F5 Networks Information for VU#714121 Incorrect NXDOMAIN responses from AAAA queries could cause denial-of-service conditions
4. sol7851: Configuring the BIG-IP GTM or Link Controller systems to provide NOERROR responses for IPv6 queries
5. ISC BIND AAAA denial of service (DNS_Bind_AAAA_RPZ_DoS)
6. ISC BIND DNS64 Nameserver Response Policy Zone AAAA Record Query Remapping Remote DoS Vulnerability
7. DNS Best Practices, Network Protections, and Attack Identification