Common Misbehavior Against DNS Queries for IPv6 Addresses
RFC 4074

Ready to go. Editorial comments from gen-art:

Draft: draft-ietf-dnsop-misbehavior-against-aaaa-01
Reviewer: Brian Carpenter
Date: June 8, 2004

I think this is ready to publish and should be published. No
substantive problems.

Editorial nits:

> 1. Introduction
> 
>    Many DNS clients (resolvers) that support IPv6 first search for AAAA
>    Resource Records (RRs) of a target host name, and then for A RRs of
>    the same name. This fallback mechanism is based on the DNS
>    specifications, which if not obeyed by authoritative servers can
>    produce unpleasant results. In some cases, for example, a web browser
>    fails to connect to a web server it could otherwise. In the following
Missing verb,e.g. ....it could otherwise reach.

>    sections, this memo describes some typical cases of the misbehavior
---------------------------------------------------------such
>    and its (bad) effects.


> 4.5 Ignore Queries for AAAA
> 
>    Some authoritative severs seem to ignore queries for a AAAA RR,
------------------------servers

Just as a point of interest to section 4.2: Microsoft's name server returned SERVFAIL in response to AAAA queries at one point; SERVFAIL causes BSD's resolver to return TRY_AGAIN; sendmail thinks that TRY_AGAIN means "don't ask this name server any more questions", so would never ask for the A record since it always tried AAAA first, got TRY_AGAIN, and queued it to be tried again later.  Sendmail introduced the WorkAroundBrokenAAAA configuration option in response, which changes the behavior on TRY_AGAIN.

<Trying to delete a comment, but it keeps coming back!>

>    for a AAAA RR of the name with the RCODE being 0 (indicating no
>    error) and with an empty answer section [1]. Such a response

[1] should point to RFC 1035, not 1034 (could also point to both).


>    A widely deployed caching server implementation transparently returns
>    the broken response (as well as caches it) to the stub resolver.
>    Another known server implementation parses the response by
>    themselves, and sends a separate response with the RCODE being 2
>    (SERVFAIL).

But, isn't returning the "malformed" response the right thing to do?
The above makes it sound like the caching server has a bug. Caching
servers do not necessarily understand the format of the RRs they cache...