Date: Thu, 18 Jul 2002 14:35:24 +0100
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| I can't quite decide whether the problem is the down to the IPv6 or DNSExt
| Groups to solve,
Probably neither, most of what you're describing is just implementation bugs.
Talk to the implementors of the stack/library, and get it fixed.
| getaddrinfo() performs an outer loop across all known address families-
| in this case IPv6 and IPv4 in that order,
While this makes the implementation easy, it is almost certainly not the
right way - since (in this scenario) both AAAA and A records would be
wanted (otherwise it would only be doing one of the queries) it really
should be doing both at once. Not all the AAAA and then all the A.
That just turns out to be harder with the internal library interfaces
as they currently exist that the current scheme.
| Because all Unix resolver libraries I've been able to test force a
| last-resort search path of "."
That's another bug - failing to add a domain should only ever be done
to a name that already has dots, a name like "grumpy" (that is, not "grumpy.")
should never be looked up by normal applications, some default domain
should always be appended. (Diagnostic tools can behave differently
sometimes).
| The problem, of course, is that the "grumpy. AAAA" lookup is forced
| to query all the way up to the root servers
Just sloppy implementation. Nothing in any spec requires that.
| 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
That's a high overhead way of achieving a simple result (high because it
will often require two additional system calls - one to open, another to
close again) just to find out if the stack is IPv6 (or 4 for that matter)
capable. There should be an easier way in the API to achieve this.
That's something which might be an ipv6 working group issue.
| 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.
That sounds like more info than is required.
| 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.
Lots of things annoy the root servers. But the implementation bug should
be fixed. This is not the forum to achieve that however.
For what it is worth, the same problem can easily occur (and does occur,
though there are less implementations that suffer as much these days as
there used to be) without any IPv6 anywhere.
| The above might even argue for a redefinition of DNS itself,
| banning A/AAAA/A6 records in a TLD,
No, we don't need that.
| 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.
Everyone should be able to manage without it if the initial name has
no dots at all. Of course, if you had said "grumpy.subdomain" expecting
"grumpy.subdomain.dwarves.com" to be found, then a lookup for just
"grumpy.subdomain" is to be expected, and will often be attempted before
appending anything from the search path.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
