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 addresseswould 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 specialcase 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, sothat 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