Common Misbehavior Against DNS Queries for IPv6 Addresses
RFC 4074

[Ballot comment]
>    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...

[Ballot discuss]
Section 4.1: I'd prefer to not see NXDOMAIN mentioned in this document since it is specific to one implementation of the DNS.  Use "Name Error" as described in RFC 1035.

Section 4.2: same gripe.  Please use "Not Implemented" instead of NOTIMP.  1035-terms would be better than SERVFAIL or FORMERR, too.

These implementation-specific terms are used elsewhere in the document.  All should be changed.

[Ballot comment]
Section 4.1: I'd prefer to not see NXDOMAIN mentioned in this document since it is specific to one implementation of the DNS.  Use "Name Error" as described in RFC 1035.

Section 4.2: same gripe.  Please use "Not Implemented" instead of NOTIMP.  1035-terms would be better than SERVFAIL or FORMERR, too.

These implementation-specific terms are used elsewhere in the document.  All should be changed.

[Ballot comment]
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

[Ballot comment]
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.