>> because their boxes break horribly when confronted with an AAAA >> lookup. This has been going on for _years_ and the operators and >> vendors obviously don't care even though the problem is blatantly >> obvious. > > Obviously this should be fixed. But: you may ask yourself: why is your > system doing AAAA lookups when you obviously don't have IPv6 > connectivity? Because the application asked it to do them? Here's the thing. I don't want getnameinfo() or any other API that does DNS lookup to act differently depending on whether the system seems to have external IPv6 connectivity or not (unless the app explicitly asked for this), because my app might have a valid reason for wanting to know if there's an AAAA record associated with a name even if the system doesn't have external IPv6 connectivity. For instance, my app might have an RSIP or socks or explicitly controlled NAT service available that can let it access the IPv6 network, or it might be providing referrals to peers that can make use of an IPv6 address. More generally, I don't want anything that handles DNS queries - be it the API or a cache server or any intermediary or really even an authoritative server, to be trying to make guesses about how to interpret a query based on anything other than the information in that query - class, query RR type, name, etc. The view of DNS needs to be consistent from one host to another and one query to another if we want applications to work reliably. Over-clever APIs, NATs with DNS ALG, other intermediaries that try to guess what the app wants or needs are not doing a service to anybody. They're just making the DNS less predictable, less consistent, and less usable by apps. (as for multi-faced DNS, it is is a mixed blessing at best) As for intermediaries that try to intercept DNS queries and screw with the query or the results: In general, the problem with intermediaries is that they need to be smarter than both endpoints. Intermediaries essentially always fail at this. One reason is that endpoints are so diverse in their implementations and needs. Another reason is that intermediaries tend to be invisible (not "transparent" which is something different). So when things break, attention is focused on the endpoints even though the intermediary is responsible for the breakage. But the last thing you need is an API that tries to second guess what the intermediary is doing and work around bugs in the intermediary. Because that just makes the system as a whole even less predictable, and makes it take longer to get the broken intermediaries fixed. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf