Subject: Re: DNS lookup API (was Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG)

From: Keith Moore <[email-masked]>
Date: Wed, 5 Nov 2003 18:33:10 -0500

> Keith Moore <[email-masked]> writes:
> 
> > Or you could redirect attempts to ssh to host X so that they go to
> > host Y instead.  This is not an inherently desirable feature.
> 
> Sure, but if I have write access to the DNS configuration (so that I
> can add the SRV record), then I don't need any SRV records to do that
> redirection, plain A or CNAME works fine. SRV just let's me do it on a
> more fine grained scale.

in other words, it lets you mount precision attacks :)

> > > If the server administrater wants it: Sure. Nobody else can really
> > > decide whether or not SRV is "useful" or "appropriate" for a
> > > particular service instance.
> > 
> > Nor, for that matter, can the DNS server administrator.
> 
> The server and administrator and DNS server administrator have to
> cooperate. If they for some reason refuse to do that, they simply
> can't deploy SRV in any useful way.

You missed my point, which was that the DNS server admin is usually not
in a position to know whether it's appropriate to impose SRV records on
a particular app - unless perhaps the app specifies how and when it's 
okay to do that.  SRV is not a general-purpose club that you can beat
apps with.
 
> > For instance, http://example.com:80/foo/bar will be canonicalized to
> > http://example.com/foo/bar  - which, if there were a SRV record for
> > _http._tcp.example.com pointing to a different port or host, would 
> > change the meaning of the URL.
> 
> Thanks, that's a good point. It's got more to do with URL syntax than
> with the http protocol per se,

it's pretty hard to separate HTTP and URL syntax; HTTP and URLs are very
closely tied together.

> but it still seems like it could be a
> real problem with using SRV records for http.

It's just one example among many.  Some protocols can run perfectly well
on any port; others have assumptions about port numbers wired-in , and 
often they are not obvious.  The point is that one size does not fit all,
and imposing SRV on all apps will break things.

Keith

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: [email-masked] (Niels Möller)
Date: 05 Nov 2003 10:19:21 +0100

Keith Moore <[email-masked]> writes:

> > As far as I can see, the only good reason to have the service argument
> > in getaddrinfo is to make it possible for getaddrinfo to perform SRV
> > lookups.
> 
> that's not a good reason, that's a disaster.

That's a strong word, given that the only effect on lookups in the
majority of domains that haven't deployed SRV, is one more roundtrip
to the local caching dns-server. Or if you do lookups in parallell,
you ask for A, AAAA and SRV instead of just A and AAAA.

> it would also tempt NATs to tweak DNS in even more preverse
> ways than they already do.

I don't understand how this is relevant. It should work fine unless
the NAT operator does anything stupid, and that's the highest level of
NAT-support we can expect for any protocol.

> there's a reason that RFC 2782 contains the following text:
> 
> Service SRV records SHOULD NOT be used in the absence
> of such specification.

Right, for each particular domain and service, there's a choice that
has to be made before deploying SRV. In order for SRV-records to be
used for a particular service, both ends must have it: There must be
SRV records configured in the DNS-server for the domain, and the
client must ask for and use them. (To be precise, I'd say that if a
client that asks for SRV records, gets a NODATA answer, and then falls
back to the good old A, AAAA and getservbyname, then SRV is "not
used". You may say there are security issues, but from reading the
security considerations section of RFC2782, I don't think there's a
real problem).

The effect of of having getaddrinfo try SRV lookup (or generally,
having a random client application ask for SRV records by default) is
to make it possible for the operator of the domain in question to
easily implement her choice. The effect is that the client
applications delegate the decision "should I be using SRV records for
this particular <domain,service>" to the operator of the corresponding
DNS domain.

This depends on how you want to deploy SRV, I guess. To me, it makes
sense with a gradual deployment per <domain,service>. And then it
seems useful if applications by default use SRV records whenever the
operator of a domain has bothered to configure relevant SRV-records
in the right DNS server.

My current interest in SRV is that I'm hacking Ian Jackson's resolver
library "adns" to support IPv6 and SRV. This includes an
adns_getaddrinfo function which asks for SRV-records, and in the
absense of SRV-records, constructs a fake SRV-record from A and AAAA
records and getservbyname. Unlike getaddrinfo, SRV lookup is an
advertised feature, and the function returns SRV records, not just a
list of addresses. If there's any good reason why I shouldn't
recommend random client applications to use this function, I'd like to
know about it.

Ah, and one more question: After a first look around for SRV records
in the current DNS infrastructure, I've found SRV records for the
following services: ftp, http, kerberos, kpasswd, and sip. I imagine
SIP, being a recent protocol, actually specifies the use of SRV (I
haven't read the SIP specs). What about the others, does there exist
any standards track spec, as required by the RFC2782 applicbility
statement, endorsing SRV-records for e.g. ftp, http and kerberos? For
example, try

  host -l sunet.se sunic.sunet.se |grep SRV
  host -l ingate.se usagi.ingate.se |grep SRV

for two domains that are operated by people who I believe are not
clueless about the DNS.

Best regards,
/Niels

PS. I'm afraid API and deployment issues border on off-topic on the
ipv6 list. Feel free to send followups elsewhere (and Cc: me), or to
answer privately.

---

From: Keith Moore <[email-masked]>
Date: Tue, 4 Nov 2003 14:16:39 -0500

> 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.

> 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.  

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.

> 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.

Keith

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 4 Nov 2003 09:28:17 +0100 (CET)

On Mon, 3 Nov 2003, Keith Moore wrote:

> > On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote:
> > > I don't think that we should be defining getaddrinfo() in terms of
> > > "whatever lookup service happens to be around" because it's very
> > > difficult to get reliable and repeatable behavior that way.
> >
> > Isn't the DNS a lookup service that happens to be around ?
>
> DNS is a specific lookup service.  not a random one that just might happen
> to be around.
>
> > The purpose of getaddrinfo is to perform network address and service
> > translation. Whilst a portable, granular, interface to DNS would be
> > very much welcome - getaddrinfo should not be it.
>
> Perhaps.  But if getaddrinfo isn't the service that does DNS lookups,
> then at least some apps should not be using it.

getaddrinfo() and getnameinfo() was developed as a generalisation of
gethostbyname() and gethostbyaddr(). Thus, from pragmatic point of view
should follow the behaviour of the extended functions (gethostbyname etc.)

Basically if you call them you are rely on the several different name
service functions controlled by local configuration (e.g nsswitch.conf
resolv.conf etc.)

>
> Well, link-local addresses should never be in DNS in the first place.

Yes this is advisable!

> My argument is not that link-local addresses should be returned by
> getaddrinfo() , it is that getaddrinfo() should be transparent.

Completely agree. The getaddrinfo() should be completely transparent from
programmers' point of view. The local setup should be system/environment
specific. I think the cleanest solution would be to setup the DNS
resolution order locally by administrator: IPv6 address-resolution enable,
and order of IPv4/IPv6 address-resolution. In my opinion, this should be
included the resolver code and configurable from resolv.conf.

We already have sortlist: IPv6 should be added, and then we could
configure whether we want IPv6 address or IPv4 in the first place. To
disable IPv6 DNS query should be configurable one the _res.options e.g
RES_NO_INET6_QUERY.  The current default is to do IPv6 RR query, so that
one could be disabled.

I strongly against the idea, to change the current default behavior of
IPv6 applications without setting up new things. The compatibility is one
of the most important feature that we have to keep!

Regards,
	Janos Mohacsi

---

From: "Eugene M. Kim" <[email-masked]>
Date: Tue, 04 Nov 2003 14:35:55 -0800

Eugene M. Kim wrote:

> But the fact that applications are doing a wrong thing means we can 
> just ignore them as if they weren't there.  

Oh God.  s/means/doesn't mean/ *blush*

Eugene