[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals andAI_ADDRCONFIG)

(Trimmed down Cc: list again, assuming we are all reading ipv6@...)

Keith Moore wrote:

>>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).
>There's a third option - like I suggested earlier, add a flag to
>getaddrinfo that says "only use DNS for this query".  The res_XXX
>and dn_XXX functions (or improvements to these) are needed anyway 
>because we use DNS for other things besides address lookup.

That sounds good too, as long as the res_XXX()/dn_XXX() functions are 
standardized at the same time and the DNS-only getaddrinfo() flag is 
defined to be equivalent of obtaining address records via res_XXX() calls.

The intention here is to define and promote res_XXX()/dn_XXX() as `the' 
DNS API, and define and promote getaddrinfo() as nothing more than a 
basic name lookup service.  Otherwise people might start thinking that 
getaddrinfo() would/should be the point of augmentation when they want 
to implement SRV, MX and other name-to-address lookup API, leading to a 
whole mess (e.g. they would want to add new members to struct 
getaddrinfo to return SRV service priority and weight information 

IMO, people should be first recommended to use res_XXX() in order to 
implement such a non-A/AAAA lookup scheme, and if they find that too 
bothersome (which it's likely to be when the scheme is widely deployed), 
they should define a new API that fully covers the scheme rather than 
finding a similar API then victimizing it.

>>Perhaps it'd be desirable to see some actual figures; how much 
>>percentage of the applications out there that use 
>>gethostbyXXX()/getaddrinfo()/getnameinfo() would assume those
>>functions look up DNS records *only*, and would be severely broken if
>>they were given results not based on DNS.
>Well, it has a lot to do with the environment, doesn't it?  I mean, if
>and when an alternate name-to-address translation service produces
>answers  identical to DNS, then the app probably doesn't care what
>service provided the answers.  The problems occur when the translation
>service doesn't  provide the correct answers, or when the translation
>service in use at point A provides different answers than the service in
>use at point B.  The more different lookup mechanisms in use, the easier
>it is for them to get out of sync with one another.
>Similarly, no app will be broken by a decision to use DNS when its host 
>or network is properly configured.  The only time breakage occurs is 
>when the host or network is improperly configured to use some other 
>lookup service besides DNS, or when the host is not configured at all.
>(yes, we do need to deal with self-configuring or ad hoc networks, 
>but we need to do so in a way that produces results that don't conflict
>with DNS)
>An increasing number of apps are defined in such a way that DNS is *part
>of the protocol specification*; the app will violate the protocol
>specification if it uses a service other than DNS.  For instance, any
>app that uses SRV or MX records falls into this catgory.  There's little
>justification for an administrator to use an alternate address lookup
>service, since they typically have to support at least one app that
>requires DNS anyway.

The standard (RFC 3493, or POSIX) as it is defined now is defined to be 
namespace-neutral (although in a passive manner).  A lot of 
implementations interpret the standard that way too, e.g. 
nsswitch.conf.  If applications abuse it as a DNS interface then break 
later, it's their problem; they should've taken into account from the 
first place that getaddrinfo() *may* return non-DNS results.  It doesn't 
seem like a good idea to reduce the functionality of an existing 
standard just so it meets what applications mistakingly expect it to 
be.  (By the way, I'm talking about the option #1; AI_DNS_ONLY looks 
good because it does draw a clear line without sacrificing any of the 
existing capability.)

>And there's certainly no reason for IETF to be endorsing the idea that 
>a site should be able to use any lookup service it likes without
>breaking things.

Agreed.  The current RFC 3493 seems insufficient in this aspect.  An 
update to RFC 3493 that defines the DNS-only flag could clarify: `If 
AI_DNS_ONLY is not specified to getaddrinfo() or getnameinfo() calls, 
the result from such calls MUST NOT be assumed to be obtained solely 
from DNS.  Applications that require the result to be from DNS MUST 
specify AI_DNS_ONLY when calling getaddrinfo() or getnameinfo().'

>>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.
>It's been a long time since HOSTS.TXT was sufficient.  It's also been
>a long time since DNS was only a distributed replacement for HOSTS.TXT.
>The Internet is not defined by the "vast majority of applications".
>The Internet is defined by specifications.   The problem is that our
>specifications are sometimes incomplete.  In this case the APIs that
>we're recommending be used for implementation of apps aren't specified
>with enough precision to allow those apps to interoperate reliably.

(This seems to be getting off-topic; this will be my last on-list 
response about this particular subject.  Sorry ;)

I agree with you, except that I think the Internet *is* defined (albeit 
indirectly) by applications.  My take is slightly broader.

How the Internet *should be in the future* is defined by 
specifications.  How the Internet *currently is* is defined by various 
components of the Internet, including the VMoA (:p).

The basis upon which people decide how the Internet should be in the 
future, i.e. specifications, is what they want to accomplish in the 
current environment, i.e. the current status of the Internet.  In that 
sense, the current Internet and its applications provide some sort of 
guidance upon creating/amending specifications, usually suggesting a 
path of less resistance.

I'm not saying that what applications do is always right.  But the fact 
that applications are doing a wrong thing means we can just ignore them 
as if they weren't there.  Whatever we do that breaks them will upset 
some people (especially if they didn't even know those applications had 
problems, however subtle they may be).  So, as long as we can reach our 
goal of enhancing our specifications to be more clear and precise, why 
not take a course of action that meets expectation of more applications 
and/or breaks less applications?

This is why I still believe what people expect from (current 
applications that expect certain behavior from) getaddrinfo() should 
have a say about how we update RFC 3493.  To me it looks like there are 
going to be more people who are like `What, my changes to 
/etc/nsswitch.conf has no effect?' or `Why do the entries I added to 
/etc/hosts seem to be ignored?' (e.g. if system admininstration scripts 
rely on those files) after we change getaddrinfo() to be DNS-only by 
default, than people who are like `Geez, this program doesn't work 
anymore after I change /etc/nsswitch.conf?' (e.g. after raising the 
priority of NIS database which is out of sync with DNS) under the 
current behavior.  But this is only from my (limited) viewpoint, and I 
wanted to hear some other inputs as well.


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6