Fixing DNS Misbehavior Hindering IPv6 Deployment

Shigeya Suzuki
USC Information Sciences Institute
4676 Admiralty Way, Suite 1001
Marina del Rey, CA 90292, USA
shigeya@wide.ad.jp

Tatuya Jinmei
Toshiba Corporation
Corportate R&D Center
Komukai Toshiba-cho 1, Kawasaki, Japan
jinmei@isl.rdc.toshiba.co.jp

Sohgo Takeuchi
WIDE Project
5322 Endo, Fujisawa, Kanagawa, 252-8520, Japan
sohgo@wide.ad.jp

Abstract
During the course to deploy IPv6, we found several critical implementation and operational issues which distract
user and possibly prevent wider deployment of IPv6.
Among the problems we noticed, Domain Name System
(DNS) related issues are signicant. Some of the problems
cause longer delay during the process to make a connection
to a given node. In worst case, the delay will be 60 seconds
or more. This amount of delay may mislead users for some
idea that IPv6 is not good technology, which is not accurate. In this paper, we will reveal six cases which related
to DNS server and resolver implemetation we found during
our study in detail.
To overcome these problem, x to the servers are essential. To know how these cases affect overall behavior
of the DNS, we created a tool to nd misbehaving servers.
We applied this tool to servers in .JP domain and found
that there are 0.11% of servers in .JP domain have some
problem. The other way to solve or ease the problem is
to nd workaround in client side. We will propose two
workarounds, with a sample implementation.

Introduction

IPv6 deployment is gradually spreading, but while discussing deployment of IPv6 and actually operating IPv6
networks, we found there were several issues which may
distract some of IPv6 adopters, especially in mobile connectivity areas. We understand these issues are relatively
rare, but problematic. Since the distractions we will discuss
here will affect a users experience a lot, if a user understands this experience as an IPv6s problem, the user may

not want to switch to IPv6 environment, possibly delaying

the deployment of IPv6, which is undesirable.
The v6x working group was created at the WIDE
Project[6] and is actively working to address these issues.
In this paper, we would like to describe one of these issues
especially in the Domain Name System(DNS)1 . In section 2
and 3, we describe what the problem is. In section 4, we describe our effort to know how this problem appear in current
system. Then, we propose possible xes in section 5.

DNS and the problem domain

When an application needs to retrieve a remote node address for a host name, it sends requests to an underlying
library. This library will communicate with DNS servers to
resolve a host name into addresses.
To resolve a name, authoritative DNS servers provide
authoritative information for a name. This information is
kept as some Resource Record (RR) in servers. Types
of information in a RR is distinguished by RR type. IPv4
address RR type is A and IPv6 RR type is AAAA. In
the environment which both IPv4/IPv6 are co-exist, addresses assigned to network interfaces will be either IPv4
address, IPv6 address or both of them. Since it is possible
to have multiple addresses for a host, any number of A or
AAAA RRs for a domain name may be stored.
To retrieve any IP address, applications use the standard
getaddrinfo() library function. The application should try
to connect to the returned addresses one by one to establish
communication. A typical implementation of this procedure
tries to connect to IPv6 addresses rst when both IPv4 and
1 DNS is specied in set of RFCs. For overview of DNS and further
references, please refer authors survey paper[5]

Proceedings of the International Symposium on Applications and the Internet Workshops (SAINTW06)
0-7695-2510-5/05 $20.00 2005

IEEE

IPv6 addresses are available.

This behavior assumes that DNS queries are handled
properly and a connection attempt to an unreachable address fails immediately, quickly falling back to a connection setup with other possibly reachable addresses. In reality, these assumptions are not necessarily met due to several
reasons.
In this paper, these behaviors are described, such as: several non-compliant DNS server code behaviors and a problem caused by combination of a kind of middle box and a
kind of resolver2 .

Some authoritative DNS servers return a response with

a result code Not Implemented (RCODE 4) or Server
Failure (RCODE 2) on AAAA queries in the scenario.
This is not correct, but this behavior is relatively harmless,
because most resolvers will fall back to A queries in this
case. However, caching servers do not cache the fact that
the queried hostname has no AAAA RR, increasing the
load of the authoritative server. Note that Format Error
(RCODE 1) result code could also cause a similar effect, but
there are no such implementations known at this moment.

There is a case that the response RDATA eld for an

AAAA RR query lled with IPv4 addresses instead of
IPv6 addresses. The caching server behavior to this type
of response varies; BIND[2] version 8 caching servers pass
a broken response to a resolver; BIND version 9 caching
servers discard a broken response, and returns an error of
Server Failure (RCODE 2) to the resolver. With BIND
version 9, the cache related problem described in 3 is also
happen in this case too.

DNS misbehave scenario in a dual stack environment

There are several known problematic cases. Some of

them are already documented in RFC4074[7] as a result of
the v6x working group effort. In addition to these cases,
we will cover a recently found case.
Note that, when a host name under a DNS zone has an
A RR but does not have an AAAA RR, an authoritative
DNS server of the zone should return 1) An empty answer
section, and 2) Response code which indicates there are no
error, which is RCODE set to 0, for an AAAA RR query.
Case 1: DNS Server ignores queries for an AAAA RR
Most resolvers rst send queries for an AAAA RR. If it
cannot be resolved, they send another query for an A RR.
Unfortunately there are some implementations of DNS
server software, which silently ignore AAAA queries. If
a query of an AAAA RR are ignored, client should wait
for a timeout period.
Case 2: DNS server return Name Error inappropriately
Name Error (RCODE 3) indicates that a DNS server
does not have any RRs of any type for a queried name.
When this response is returned to a resolver by a server
that is expected to send AAAA RRs, the resolver cannot
get A RRs anymore. The reason is, there are functionality called negative caching[1]. If a part of resolving process
is capable of negative caching, it caches non-existence of
the domain, effectively deny the existence of other RRs under same name. Therefore, if a resolver tries to fetch an
AAAA RR, but it gets Name Error, the negative cache
prevents checking the existence of the A even it is available. This prevents fallback, even there are IPv4 addresses
available.
Case 3: DNS server return erroneous codes other than
NameError
2 There are harmful behaviors in the IPv6 protocol specication and
characteristics of the TCP specication and implementation also. This paper will focus on DNS related issues.

Case 4: DNS server return a broken response

Case 5: Lame delegation and AAAA RR

Some DNS servers return an authoritative response to
A queries, but return a nonauthoritative response to
AAAA queries and effectively cause a lame delegation
situation. Some older versions of BIND version 8 caching
servers suffer from this behavior, because it will stop using a server for some period once it detects the server is a
lame server. Additionally, these BIND version 8 caching
servers simply returns a Server Failure (RCODE 2) result
for queries in the zone which is managed by a lame server
throughout the period. In this case, after receiving an error,
the resolver will never be able to get a correct response even
if it falls back from AAAA to A.
Case 6: Middle box and resolver behavior mismatch
There is a kind of middle box which is used in subscription based broadband services such as a hotel room
Internet service. These boxes intercept web browser connections from a client to the Internet, returns faked redirect
HTML text which forces a redirect to a subscription application page on a server. Since subscription web server is
usually beyond the middle box, the connection to the web
server is not ltered or redirected. After the user subscribes
to the service using the subscription page, this box passes
connections from the client to the Internet.
Since these boxes are usually implemented to fake
a DNS server, how it is implemented is important in
IPv4/IPv6 co-existing environment. There is at least one
such middlebox which misbehaves with IPv6 dualstack
congured Windows XP. This problem arise when the middlebox incorrectly return a A RR for the invalid server
address as the answer to a query to AAAA. Moreover,

Proceedings of the International Symposium on Applications and the Internet Workshops (SAINTW06)
0-7695-2510-5/05 $20.00 2005

IEEE

Some problems found

No problems found
Unknown

per domain
0.04%
82.16%
17.80%

per server
0.11%
84.39%
15.50%

Table 1. Proportion of the misbehaving

servers and good behaving servers, by per
domain or per server basis.

the Window XP resolver blindly accepts the A result for

the AAAA queries as a valid target address. Since the
returned IPv4 address is not an address congured to get
through the middlebox, a new connection to this address
will blocked by the middlebox again. The box will return
a faked HTML text as it previously did, causing an innite
loop.

Reason
Ignore queries of an AAAA RR
Name Error (RCODE 3)
Error other than Name Error
Broken response
Lame delegation

Table 2. Reason of misbehave

the summary is created both in per-domain and per-server
basis. Since there are more than one authoritative server for
a zone, it is important to check the proportion in each case.
For the Unknown case, there are several possible causes,
such as 1) Target server is simply down, 2) Target host label
selection does not meet the condition. Table 2 categorizes
the misbehaving server and their proportions.

5
4

Proportion
4.7%
4.7%
8.5%
0.0%
82.1%

Workarounds at the resolver side

A survey of misbehaving DNS servers

As described in the previous sections, misbehaving DNS

servers have bad effects on the client side. The rst step of
our activity in v6x working group was to survey current
DNS servers by the following steps as a joint effort with
Japan Registry Services (JPRS): 1) Develop a tool to nd
misbehaving DNS servers, 2) Perform query with this tool
on servers in the .JP zone to identify misbehaving sites, 3)
Obtain vendor and version information of the misbehaving
DNS servers from system administrators of the sites, and
4) Report the results to the vendors to ask for xing the
implementation.
As the rst step, we wrote a perl script for the survey.
This script sends probing DNS queries to DNS servers, analyzes the returned packets, and outputs a summary of the
results. The procedure of the script is as follows: 1) Select
a domain name to survey, e.g. example.jp, 2) Find all authoritative DNS servers for the domain, then select one of
them as the initial target authoritative server, 3) Determine a
service host name as a target. Our tool tries to select a likely
existing host name by adding some well-known host label such as www or ftp to the domain name, 4) Send
A RR queries to the selected authoritative DNS server to
retrieve IPv4 addresses of the target service host, 5) If the
tool can successfully retrieve the addresses of the the target
host name, then it checks the behavior of all the authoritative DNS servers found in step 2 by sending an AAAA
RR query for the same host name, and 6) Output the results.
Then, using this tool, we performed a survey on the JP
domains using the domain list of .JP zone as of November
2004. Table 1 shows the result. Only summarizing statistics
information of the results is shown due to privacy concerns.
Because we want to see how each domain is affected by the
behavior, and number of servers affected by the behavior,

In this section, we will discuss workarounds to these

problems at resolver side. Specically, we will propose
the following two approaches in the subsequent sections:
1) Limiting AAAA queries to the case where they are absolutely necessary, and 2) Shortening the timeout period for
AAAA queries under a certain condition.
Proposal 1: Limiting AAAA queries
It is possible to ease or avoid most DNS-related problems in a dual stack system if we can limit DNS queries
for AAAA RRs only to the case where those queries are
absolutely necessary. For instance, we do not need provide
the information for communicate over IPv6 in an environment where IPv6 connectivity does not exist, such as IPv4
only node. By the use of this limitation, it is possible to
completely avoid the problems described so far in such a
network by only sending A queries and making communication over the IPv4 address(es) returned. To determine
whether it is necessary to locate IPv6 addresses, one option
is to check the availability of IPv6 addresses other than linklocal addresses3 . In practice, this means the case where the
node has a global IPv6 address.
When modifying the standard getaddrinfo() library, it is
possible to implement the proposed approach by suppressing AAAA queries when 1) the AF_UNSPEC address
family is specied in the hint structure given as its third
argument and 2) the hints structure and the host calling
getaddrinfo() does not have a non-link-local IPv6 address.
Suppressing AAAA queries this way is quite a different
behavior than that of deployed implementations of getaddrinfo(). However, it still conforms to the standard[4]. Refer to sample implementation described before for detail.
3 For simplicity, we regard the loopback address as a link-local address
in this discussion.

Proceedings of the International Symposium on Applications and the Internet Workshops (SAINTW06)
0-7695-2510-5/05 $20.00 2005

IEEE

Proposal 2: Shorten the timeout for AAAA queries

Resolver implementations based on ISC BIND[2]4 ,
which is the basis of many of widely deployed resolvers,
rst send queries for AAAA RRs. If it gets a response or
fails after timeouts, the resolver sends queries for A RRs.
Similarly, if it gets a response or the timer expires, the resolver combines all the responses, if any, and returns the
entire results to calling application. This behavior will suffer from a long timeout about 1 minute in the rst part, if
the responding DNS server ignores the AAAA query, and
will end up with A RRs as the nal result.
In order to ease the problem, we propose the following
modication which reduces the hopeless timeout: 1) The resolver rst sends A queries, 2) If it get successful response
for A queries, reduce a timeout period to a smaller value.
Otherwise, select a predened value as timeout period, and
3) The resolvers sends AAAA queries using the precalculated timeout value. By using this step, the resolver will not
have to wait for a long period even if the responding DNS
server ignores AAAA queries, and can still get the result
for A queries.
Implementation
We have implemented the proposed approaches in the
getaddrinfo() library function of weekly FreeBSD version
of snapshots of KAME Project[3] code. The implementation is available in snapshots of 20041129 and later.
In this implementation, we use max(1second, T 2) for
the shortened timeout period where T is the round-trip time
of the preceding A query when it succeeds.

Conclusion

In this paper, currently known problems in IPv4/IPv6

dual network, especially related to DNS are summarized.
To know how these misbehaving DNS system affect IPv6
environment, we created a survey tool, then using this survey tool, we ran a survey of miscongured servers with a
help of JPRS. We observed that existence of very few miscongured DNS servers, which may still cause problems in
dual stack environment. This does not harm overall IPv6
operation, but even the very few servers may distract users
a lot and delude users into an idea there are some problems
in IPv6 itself. This is unacceptable, so we must x the problem.
There are two ways to address these problems: server
side x and client side x. Server side x is only possible by xing server code or install xed program onto the
server. For client side x, we proposed two workarounds.
These x will improve users experience even if there are
still problem exists in server side.
4 There are several versions of BIND implementation exists and the behavior of resolvers are different sometimes even between snapshots.

By understanding nature of these problems described in

this paper, and apply several possible xes, IPv4/IPv6 dual
stack environment will work smoothly. This will improve
overall experience of user and accelerate smooth deployment of IPv6.

Future Work

There are several possibilities to enhance our proposal.

So far, we observed only servers in .JP domain. We
need to extend these surveys on other domains.
Timeout value selection algorithm for a DNS query
needs further discussion. As our understanding, there are
not enough work in this area. Better timeout selection algorithm is good not only for IPv6 environment, but also good
for IPv4. To test and nd misbehaving servers, tools are
necessary. We want to make our tools to be publicly available in future.
We need to extend evaluation of modication we made
to FreeBSD snapshots. Then, promote to import this code
into other operating systems to achieve wider availabilities.
We need some way to let these administrators know what
is the problem, to promote to xing misbehaving servers.

Acknowledgment

We would like to thank members of the WIDE Projects

v6x working group and DNS working group to discuss
whole issues around this area. And we also thank for Japan
Registry Service for helping use their facility to run a survey. We also thank Bill Manning at USC/ISI for valuable
comments.
This work is supported by the Strategic Information and
Communications R&D Promotion Programme (SCOPE)
of the Ministry of Internal Affairs and Communications,
Japan.

References
[1] M. Andrews. RFC 2308: Negative caching of DNS queries
(DNS NCACHE), Mar. 1998.
[2] Internet systems consortium BIND. http://www.isc.org/.
[3] KAME Project. http://www.kame.net/.
[4] R.Gilligan, S.Thomson, J.Bound, J.McCann, and W.Stevens.
RFC 3493: Basic Socket Interface Extensions for IPv6, Feb.
2003. Informational.
[5] S. Suzuki and M. Nakamura. Domain name system past,
present and future. IEICE Transactions on Communications,
Vol.E88-B(3):857864, 2005.
[6] WIDE Project. http://www.wide.ad.jp/.
[7] Y.Morishita and T.Jinmei. RFC 4074: Common Misbehavior
Against DNS Queries for IPv6 Addresses, May 2005. Informational.

Proceedings of the International Symposium on Applications and the Internet Workshops (SAINTW06)
0-7695-2510-5/05 $20.00 2005

IEEE