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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf