RFC 4074

RFC 4074: Common Misbehavior Against DNS Queries for IPv6 Addresses 🎀

Okay bestie, let's start with the basics 💅 This is an Informational RFC from May 2005, written by Y. Morishita (JPRS) and T. Jinmei (Toshiba) for the Network Working Group. Its header doesn't list any Obsoletes or Updates lines, so it doesn't replace or change any other RFC 🧚

Status of This Memo ✨

This memo gives information to the Internet community. It is not an Internet standard of any kind 🌸 Distribution of this memo is unlimited.

Copyright Notice 🌈

Copyright (C) The Internet Society (2005).

Abstract 💜

Some authoritative DNS servers are known to misbehave when someone asks them for AAAA resource records 😭 That can block IPv4 communication that should totally be available, cause a big delay in name resolution, or even turn into a denial of service attack. This memo walks through the known cases and what they do.

1. Introduction ✨

Lots of DNS clients (resolvers) that support IPv6 first look up the AAAA Resource Records (RRs) for a host name, and then look up the A RRs for that same name 🦋 This fallback is based on the DNS specifications. When authoritative servers don't follow those specs, things get messy. Sometimes a web browser can't connect to a web server it could otherwise reach 💀 The next sections describe some typical cases of this misbehavior and how bad the effects are.

Quick note: the misbehavior isn't only about AAAA RRs. All of the known examples also apply to queries for MX, NS, and SOA RRs. The authors think this can be generalized to every type of query other than those for A RRs. This memo focuses on AAAA queries, though, because the problem is especially severe for IPv6-supporting resolvers, which means it affects a lot of end users 🫶 End-user resolvers normally send only A and/or AAAA queries, so the problem is relatively minor for the other cases.

2. Network Model 🍓

We're assuming a typical name resolution setup that uses DNS. It has three parts: stub resolvers, caching servers, and authoritative servers 👑 A stub resolver sends a recursive query to a caching server, and the caching server handles the whole name resolution process recursively. The caching server caches the result and sends it back to the stub resolver. Authoritative servers answer queries for names they have authority over, and they usually do it in a non-recursive way.

3. Expected Behavior 💖

Say an authoritative server has an A RR but no AAAA RR for a host name. In that case, the server should return a response to a query for an AAAA RR of that name. The RCODE should be 0 (no error), and the answer section should be empty (see Sections 4.3.2 and 6.2.4 of [1]) ✨ That response tells the stub resolver there's at least one RR of a different type than AAAA for the queried name, so it can go look for A RRs next.

This works out nicely because the caching server can cache the fact that the queried name has no AAAA RR (though it may have other types of RRs) 🌷 That makes future AAAA queries for the name faster to answer.

4. Problematic Behaviors 🔥

Some authoritative servers are known to not match the expected behavior. This section covers those problem cases 🙈

4.1. Ignore Queries for AAAA 🫠

Some authoritative servers seem to just ignore AAAA queries 😭 The stub resolver then has to wait before falling back to an A RR query. This can cause a fatal timeout at the resolver or at the application calling it. Even when the resolver eventually falls back, the wait can be unacceptable for the app user, especially for interactive stuff like web browsing.

4.2. Return "Name Error" 💅

This kind of server returns a response with RCODE 3 ("Name Error") to an AAAA query. That basically says it doesn't have any RRs of any type for the queried name 💀

With this response, the stub resolver may immediately give up and never fall back. Even if the resolver retries with an A RR query, the negative response for the name is already cached in the caching server, so the caching server just returns that negative response again. The stub resolver ends up treating it as a fatal error in name resolution 😭

The authors know of several examples of this behavior. As of writing, all of them have been fixed ✨

4.3. Return Other Erroneous Codes 🦋

Other authoritative servers return erroneous response codes that aren't RCODE 3 ("Name Error"). One example is RCODE 4 ("Not Implemented"), which means the server doesn't support that type of query.

These cases are less harmful than the last one 🌸 If the stub resolver falls back to an A RR query, the caching server will process it correctly and return an appropriate response.

They can still cause serious trouble though 😬 There was an authoritative server implementation that returned RCODE 2 ("Server failure") to AAAA RR queries. One widely deployed mail server implementation, paired with a certain type of resolver library, read that result as a sign to retry and never fell back to A RR queries. The result was message delivery failure 💔

When a caching server gets a response with these response codes, it doesn't cache the fact that the queried name has no AAAA RR. That means redundant AAAA queries keep happening in the future. This wastes network bandwidth and piles more load onto the authoritative server 🙃

Using RCODE 1 ("Format error") would cause a similar effect, though the authors haven't seen any implementations doing that yet 👀

4.4. Return a Broken Response 🤡

Another kind of authoritative server returns broken responses to AAAA queries 💀 One known case of this is a response whose RR type is AAAA but whose RDATA is 4 bytes long. The 4-byte data looks like the IPv4 address of the queried host name.

Here's what the RR in the answer section looks like in that case:

www.bad.example. 600 IN AAAA 192.0.2.1

Obviously that's bogus (or at least meaningless) 🙅‍♀️

A widely deployed caching server implementation passes the broken response along to the stub resolver without changing it, and caches it too 😭 Another known server implementation parses the response itself and sends a separate response with RCODE 2 ("Server failure") instead.

Either way, the broken response doesn't affect A RR queries for the same name. If the stub resolver falls back to A queries, it gets an appropriate response 🫶

The second case, though, causes the same bad effect as the one in the previous section: redundant AAAA RR queries 🔁

4.5. Make Lame Delegation 🙈

Some authoritative servers respond to AAAA queries in a way that causes lame delegation. Here's how it goes: the parent zone says the authoritative server should have authority over a zone, but the server doesn't return an authoritative response for AAAA queries within that zone (meaning the AA bit in the response isn't set). Meanwhile, that same server does return authoritative responses for A queries 🌈

When a caching server asks the server for AAAA RRs in the zone, it notices the delegation is lame and returns a response with RCODE 2 ("Server failure") to the stub resolver 💀

It gets worse 😩 Some caching servers record the authoritative server as lame for the zone and won't use it for a while. With this type of caching server, even if the stub resolver falls back to an A RR query, the caching server just returns a response with RCODE 2, because every server is known to be "lame" 💔

There's also an implementation that relaxes this a little bit ✨ It tries to avoid the lame server but keeps trying it as a last resort. With this type of caching server, the stub resolver gets a correct response if it falls back after Server failure. Still, this causes redundant AAAA queries, as explained in the previous sections 🔁

Intellectual Property ✨

okay so the IETF is NOT taking a side on whether any IP rights (patents, copyrights, whatever else people might claim) apply to the tech in this doc. 🙃 It also doesn't say whether you can get a license for them, and it hasn't gone hunting for any rights either, so don't assume it did 💅. If you want the rules on rights in RFC docs, check out BCP 78 and BCP 79 📚🫶

Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are any licensing assurances, plus the results if someone tried to get a general license or permission to use proprietary rights for this spec. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🦋

The IETF also really wants to hear from you 💖 If you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to build this standard, please tell them. Send it to ietf-ipr@ietf.org and they'll take it from there 🌸

Acknowledgement

Funding for the RFC Editor function is currently coming from the Internet Society 💜 Thank you, Internet Society, you're literally keeping the RFC lights on 🕯️✨