[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Resolver problems
On Dec 3, 2009, at 9:59 AM, Jeremy C. Reed wrote:
>> 1) Installation of a filtering DNS proxy on the NetBSD box which sends
>> NXDOMAIN replies to all AAAA queries.
> What is making these AAAA queries? Why not fix them instead?
Evidently, the WIDE IPv6 project responsible for much of the IPv6 code which
has been adopted into the BSDs set things up to perform IPv6 address lookups
before IPv4 lookups were performed, perhaps in order to get wider testing of
IPv6 code paths. Both the resolver routines in libc itself, and the BIND
nameserver will still continue to perform AAAA queries, even if IPv6 is
disabled and the system rebuilt, and/or if named is run with -4 flag or similar
IPv4-only settings in its config.
The encouraged programming practice has been to replace calls to the older
gethostbyname() family with getaddrinfo(), and to use PF_UNSPEC for the network
protocol so that any supported network protocol can be used so that the program
doesn't need to care whether the connection happens via IPv4 or IPv6, if both
types of addresses are available.
Unfortunately, in real-world usage rather than experimental testing, a fair
amount of the Internet doesn't (or didn't, since the situation is improving as
networks fix things) support IPv6 requests to various extents; in particular, a
vast number of web-based ad-tracking domains like doubleclick.net and so forth
did badly when you tried IPv6 lookup so that as a consequence end users would
experience obvious delays-- from 10s of seconds to minutes, for each page-- in
casual web browsing.
Trying to perform A lookups before you try AAAA lookups turns out to resolve
almost all the problems users were experiencing, and so this became the default
behavior on FreeBSD (ie, the second suggested patch from my earlier email; see
this change was made back in 2005). Darwin/OSX issues A and AAAA lookups in
parallel, but seems to prefer A results if both are available or if running as
part of an embedded platform, going from
Given that the normal IPv4 packet header is 160 bits and the normal IPv6 header
is 320 bits, with 1500 byte MTU, you get a mild improvement of 1480 / 1460
bytes of payload == ~1.4% more data throughput when using IPv4 protocol instead
Main Index |
Thread Index |