[dns-wg] AAAA problem document

It seems that the AAAA problem draft is still on the agenda. I've
included the current version of the document below, which includes
some minor updates, clarifications and edits from the last version.

There weren't too many substantial comments last time and the issue
isn't changing rapidly. I'd suggest that we either go with something
close to this version of the document, or close the item and point
at the Internet Protocol Journal article.

	David.


Misbehavior of DNS when faced with IPv6 or other New Query Types

David Malone
August 2006

Abstract

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

1. Introduction

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 by 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 ("quad A"), has been introduced. It is becoming increasingly
common for software to first issue a request for a record 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 server implementations have been found
that have problems answering other queries. Some DNS implementations
have problems with only new types, such as AAAA, and others have
problems with any query not of type A.  The end result of these
issues is that connecting to a site using a problematic nameserver
may be impossible, intermittent or significantly delayed.

The technical details of these problems are explained in [RFC4074].

Note that these problems are not limited to hosts connected to the
IPv6 Internet. Any host may look up an IPv6 address even if it does
not wish to make an IPv6 connection. This might include hosts
processing e-mail headers of a mail that has passed through an
IPv6-capable system or a host processing log files from an IPv6-capable
system.

2. Problem Extent

In Q1 2004, a survey of nameservers for 24000 hostnames mentioned
in web proxy logs found about 0.5-1% of nameservers seem to have
to have a problem of this nature. This corresponds to about 1.8%
or URLS that are impacted by the problem. For more details of this
survey see [IPJMISBEHAVE].

In terms of DNS server software, DNS load balancers seem to be
commonly affected. This means that high-volume sites, such as ad
servers, are often victims of this problem. Due to the embedding
of ad-server images in web pages, the extent of the problem may be
experienced by users of other web sites displaying these ads.

3. Testing New DNS Systems

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 [RFC1035],
[RFC3597] and [RFC4074] 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.

Simple testing can be conducted by making a query for a AAAA record
using a tool such as dig. Supposing that the server has IP 192.0.2.1
and is to serve the domain example.com, queries such as the following
should be made:

	dig AAAA exists.example.com @192.0.2.1
	dig AAAA does-not-exist.example.com @192.0.2.1
	dig AAAA www.subdomain.example.com @192.0.2.1

In each case the server should return the correct response. In the
first case, the correct response is a number of AAAA records (0 if
there are none) and a status of NOERROR; in the second case, the
returned status should be NXDOMAIN; in the third case the server
should return a referral to the servers for the subdomain. Even if
the server is only responsible for reverse zones, where queries for
AAAA records are uncommon, such tests are still useful as reverse
zones may still receive queries for other new record types.

A simple web-based tool for testing is available at

	http://www.cnri.dit.ie/cgi-bin/check_aaaa.pl

This tool can detect some of the most common problems given
a domain name.

4. Addressing the Existing Problem

The fact that problematic nameservers exist is in itself a problem.
Where these issues cause direct inconvenience to your user-base, the
maintainers of the offending 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 is 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 hostmasters or to publish lists based on such
data. However, as service maintainers are usually primarily concerned
about complaints from paying users, the most effective way to tackle
this problem may be for these users to users to notify service
maintainers.

The action required to restore normal service may just require a
simple software upgrade if the DNS server vendor has already addressed
these issues. A DNS server vendor should be able to address these
issues rapidly using the RFCs referenced in this document.

5. Related Issues

There are a number of other IPv6-related DNS issues that warrant
mention.

5.1 A6 Records

Initially, IPv6 addresses were to be determined in the DNS using
A6 records, rather than AAAA records. Nameservers that respond
incorrectly to AAAA requests are also likely to respond incorrectly
to A6 records. A6 queries are now considered experimental.

5.2 ip6.int vs. ip6.arpa

Originally, two schemes were proposed for IPv6 reverse lookups. One
used the ip6.int domain and the "nibble" format. The other used the
ip6.arpa domain and the "bitstring" format. The system that has now
been settled on uses the ip6.arpa domain and the nibble format.

Most use of the ip6.int domain has ceased and it has been deprecated
formally [RFC4159]. However, some older IPv6 clients may still issue
queries in this domain.

5.3 Resolver Issues

There can also be issues with DNS resolver libraries. Some resolvers
may not react as expected when asked to act on unusual addresses
(such as IPv6 mapped addresses). Other resolvers have had problems
if a host has both IPv4 and IPv6 addresses. Still others have had
problems if hosts have only IPv6 addresses.

Problems have also been reported with some caching recursive resolvers
included in 'home router' products, which behave incorrectly when
dealing AAAA or non-A record queries.

Some of these issues can be worked around by application developer,
however many vendors now have software updates to address these
issues.

6. Acknowledgments

This work is a product of the RIPE DNS Working Group.

7. References

[RFC1035] P. Mockapetris, "Domain Names - Implementation and
	Specification", RFC 1035, STD 13, November 1987

[RCF3597] A. Gustafsson, "Handling of Unknown DNS Resource Record
	(RR) Types", RFC 3597, September 2003.

[RFC4074] Y. Morishita and T. Jinmei, "Common Misbehavior Against
	DNS Queries for IPv6 Addresses", RFC 4074, May 2005.

[RFC4159] G. Huston, "Deprecation of "ip6.int"", RFC 4159, August 2005.

[IPJMISBEHAVE] D. Malone, "Misbehaving Name Servers and What They're
	Missing", The Internet Protocol Journal - Volume 8, Number
	1, March 2005.