> So there seem to be at least two alternatives:
>
> * Change/fix the definition of getaddrinfo()/getnameinfo() so they
> are tied to DNS only but nothing else.
> * Keep the current semantics of those functions, then update and
> standarize an API that strictly queries DNS only (res_XXX() and
> dn_XXX() comes to mind first; if they fall short of what real
> applications need, we could always define a new superset).
*If* we are going to change something in this area one could also
contemplate adding some flags to getaddrinfo/getnameinfo
to allow applications to specify "DNS only" or "allow non-DNS resolution".
> However, my impression was that a vast majority of applications out
> there use the functions in their original semantics (i.e. as a shorthand
> facility for specifying human-readable text form of addresses, not as a
> frontend interface for DNS only but nothing else), e.g. `ping6
> www.kame.net' certainly wouldn't care if the IPv6 address getaddrinfo()
> returns comes from DNS, NIS, or any other mechanism.
Over the years I've seen subtle differences even for well-managed installations
that use DNS and NIS with the intent that they actually contain the same
information; for instance the information might be extracted from the same
database and put into DNS and NIS.
An example subtlety that leads to surprises for applications is
the behavior of reverse lookup. In many cases a reverse lookup using NIS
only returns the one-component hostname (e.g. "blixten")
and a reverse lookup using DNS returns the FQDN ("blixten.eng.sun.com")
Back in the days when folks were using .rhosts for insecure access control
this was quite confusing.
I don't know if there are applications today that would stumble or fail
due to this type of subtle difference.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
