Some time ago, I had an issue with a recently IPv6 capable telnet client on a
Linux box
being apparently unable to connect to local IPv4 only capable hosts during a
local
ISP Connectivity outage.
I can't quite decide whether the problem is the down to the IPv6 or DNSExt
Groups to solve,
since the issue relates to the interface between the Sockets API and the lower
level resolver libraries.
The combination of requirements for which the problem arose were:
non-Windows2000 client host
getaddrinfo capable client app.
Dual IPv4/IPv6 capable ( i.e. kernel and sockets/resolver library ) client host.
IPv4 interfaces only actually configured and up on client host.
IPv4 only visible server destination host.
non-dotted server name passed as parameter to client app.
Local ISP outage
Further investigation revealed the following explanation.
The telnet client was passed a non-FQDN ( or more accurately a non-dottted )
hostname to
which to connect.
Within the client app, getaddrinfo was called to resolve the non-dotted name.
For the purposes of the argument, assume a local company name - and hence
resolv.conf
search path of dwarves.com, and a hostname of grumpy. Also discount for the
present any
use of hosts/NIS in nsswitch.conf - which adds yet further complication to the
problem.
getaddrinfo() performs an outer loop across all known address families- in this
case IPv6 and
IPv4 in that order, passing each request down to the resolver library's lower
levels
Resolver library searches for the hostname across the resolver search path.
Because all Unix resolver libraries I've been able to test force a last-resort
search path of "."
on non-dotted names, this combination results in the following DNS queries to
the local DNS server.
grumpy.dwarves.com AAAA returns NODATA/NOERROR
grumpy. AAAA returns NXDOMAIN
grumpy.dwarves.com A returns address
As far as I can tell, on Windows boxes, performing a gethostbyname or similar on
a non-dotted name
always looks along the explicitly declared search path - there is no implicit
"." search lookup
for non-dotted names.
The problem, of course, is that the "grumpy. AAAA" lookup is forced to query
all the way up to the
root servers ( assuming no local cache has the answer ), and if your local ISP
has just pulled the plug,
the client app sulks for several tens of seconds before falling back to the
final successful
"grumpy.dwarves.com A" lookup.
As a nasty kludge fix for my local Linux boxes, where most of the kernels happen
to have been built without IPv6
support whilst the sockets library was still IPv6 capable, I was able to patch
fix the problem to an extent
by making the telnet client call getaddrinfo with AF_UNSPEC if and only if it
was capable of successfully
opening a test IPv6 socket - thereby proving the kernel to be IPv6 capable.
As far as I can tell, the preferred solution seems to be a redefinition of
getaddrinfo()/resolver-library internal
operations to perform the lookup across the DNS search path as the outer loop,
with the search across the
address family set as the inner loop, instead of the other way round as at
present. As everyone can readily
guess, this is a non-trivial problem....
Another possible workround is to enhance the API to include some form of ioctl()
like call which returns the number
of interfaces of a given family configured on a host. The client app could then
opt to only use AF_UNSPEC
as a parameter to getaddrinfo if ioctl() returns a non-zero count for the IPv6
address family.
A side effect of this is that even during normal - fully Internet connected
times - local dual stack hosts will
be busy annoying the root servers will TLD level AAAA lookups which invariably
return NXDOMAIN. Fixing
this issue would presumably relieve all the root servers of quite a bit of
nonsense.
Of course, if someone happens to choose a local hostname which matches a TLD,
and a rogue TLD admin
were to create a suitable AAAA record and corresponding IPv6 host, a form of
man-in-the-middle attack might
also be possible. Consider a real local host of biz.dwarves.com, and a biz. AAAA
record pointing
to a live rogue IPv6 host; any client connecting to biz from a dual stack host
might potentially connect to the rogue.
The above might even argue for a redefinition of DNS itself, banning A/AAAA/A6
records in a TLD, but implementing
such a monumental change is probably completely out of the question.
The other argument to be made is to ban the last resort lookup in the search
path for A/AAAA/A6 records. It seems
that Windows boxes manage completely happily without it. Given that there are
very few TLD level A/AAAA/A6 records anyway,
( cc. being a known exception ) leaving that implicit root lookup in place is
perhaps more trouble than it's worth.
Ted Rule,
Flextech Television.
***************************************************************************************************
This E-mail message, including any attachments, is intended only for the person
or entity to which it is addressed, and may contain confidential information.
If you are not the intended recipient, any review, retransmission, disclosure,
copying, modification or other use of this E-mail message or attachments is
strictly forbidden.
If you have received this E-mail message in error, please contact the author and
delete the message and any attachments from your computer.
You are also advised that the views and opinions expressed in this E-mail
message and any attachments are the author's own, and may not reflect the views
and opinions of FLEXTECH Television Limited.
***************************************************************************************************
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
