On Oct 25, 2007, at 15:48, Andrew McMillan wrote:
> On Thu, 2007-10-25 at 21:17 +0200, Koos van den Hout
wrote:
>> Today I decided to change ordering in resolv.conf
so ipv6 addresses
>> would be found first by placing the zone I created
for ipv6
>> addresses first
>> (next step will be to eliminate the special ipv6
zone and just put
>> all ipv6
>> adresses in the main zone so ipv4-with-natted
addresses will be
>> the special
>> case and ipv6 the default).
>
> All of the addresses in the search list are resolved in
parallel
> and it
> is likely that the IPv4 address is resolved faster than
the IPv6
> one, so
> that gets used.
I really hope that's not it. It would be an excellent
argument for
abandoning domain search lists, since on other systems you
get to
express a preference order.
Assuming that's not the case, my guess is that the code
searches
first for an A record through the domain search list, and if
it's not
found, searches again for an AAAA record in case it's an
IPv6-only
host; if it finds an A record, it probably then asks for an
AAAA
record for the same FQDN. The fairly obvious problem with
this is
that an IPv6-only host may be skipped over for an
IPv4-and-IPv6 host
if the user is asking for both address types, or IPv4 only.
(Should
you get back a no-address answer if an IPv6 host comes first
and
you're only asking for IPv4? My guess is, probably.) You
(well, the
original poster) could test this by using tcpdump or similar
programs
to watch DNS exchanges while looking up the names.
As I understand it, the issue is with the internal
nameserver query
APIs -- you get an interface like "search the domain
search list for
this name and record type", so you make two passes if
necessary,
first with type A and then type AAAA it sounds like. There
isn't an
interface (last I looked) to search for any in a set of RR
types.
You could ask for "any RR type", but then you
increase the traffic
(lots of data coming back that you don't care about and will
just
throw away), and you get positive matches for names you
probably do
want to skip over, for example if a site has a wildcard MX
record.
And as far as I know there isn't a "resume search list
where we left
off" interface either. So it might be doable, but the
easiest and
cleanest way may require updating the resolver APIs. (To be
fair, I
haven't looked at them in a while, so maybe someone's
already doing
that.)
Ken
--
To UNSUBSCRIBE, email to debian-ipv6-REQUEST lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org
|
