Software Engineering Institute

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.

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

Apply a patch from your vendor.