[dns-wg] AAAA lookup misbehaviour

I hadn't planned on covering the sort of client side issues mentioned
by Alvaro and Colm, but maybe I should consider it? I think I
understand the issue mentioned by Colm, and would be interested in
the details of Alvaro's problem. If people think it is a good idea
to cover these problems, then I'll write some text.

The only feedback that I've got so far is from Peter, and I've made
the changes that he suggested. The last paragraph mentions trying
to automatically nag someone regarding problem servers - I'm not
sure if we should be advocating this or if we should be saying it
is a bad idea.

	David.



This document is a short description of problems with certain DNS
systems that have come to light with the deployment of IPv6 enabled
software.

---

One of the services that DNS provides is a facility for mapping
host names to IPv4 addresses. This is probably the most common used
service that DNS provides, and is achieved requesting a record of
type "A" for the host name. Records of type A can only store an
IPv4 address, and so with the introduction of IPv6, a new record
type, AAAA has been introduced. It is becoming increasingly common
for software to first issue a request of type AAAA, and if no record
of that type is found then to issue a request for a record of type
A.

A request for a record of type AAAA causes no problems for most DNS
servers, however some DNS servers implementations have been found
that have problems answering other queries. Some DNS implementations
have problems will only new types, such as AAAA, and others have
problems with any query not of type A.

The technical details of these problems are explained in the IETF
draft document draft-ietf-dnsop-misbehavior-against-aaaa-01.txt.
In Q1 2004, a survey of nameservers for 24000 hostnames mentioned
in web proxy logs found about 0.5--1% of name servers seem to have
to have a problem of this nature. The end result of these issues
is that connecting to a site using a problematic name server may
be impossible, intermittent or significantly delayed.

To prevent introducing more DNS servers with such issues, testing
of new DNS equipment should include checking that the response for
records is in accordance with the RFCs (in particular RFC 1035, RFC
3597 and the draft mentioned above). As DNS load balancing software
has often fallen foul of these problems, particular care should be
taken in testing and validating such systems.

The fact that problematic nameservers exist is in itself a problem.
Where these issues cause direct inconvenience, the maintainers of
the server and the maintainers of the DNS data should be notified
to allow a normal service to be restored. However, often it is
difficult for end users to identify the source of these problems,
(for example, where an image embedded in a web page being served
from a host with a problem hostname).

It is also possible to automatically produce lists of names and
nameservers that exhibit these problems. Clearly it is possible to
automatically mail hostmaters or to publish "hall of shame" lists
based on such data. It is unclear if such actions would achieve
any useful effect, as service maintainers are usually primarily
concerned about complaints directly from paying users!