Subject: Re: v6ops-v6onbydefault: link-locals and AI_ADDRCONFIG

From: Keith Moore <[email-masked]>
Date: Mon, 3 Nov 2003 08:36:50 -0500

Having looked at this again, I'm firmly convinced that:

- if address family is set to AF_UNSPEC, getaddrinfo() should by default 
  attempt both IPv4 and IPv6 lookups - even if the local system is not 
  capable of communicating on both IPv4 and IPv6.  it can be useful to do A 
  lookups even if the local system doesn't support IPv4, and it can be useful 
  to do AAAA lookups even if the local system doesn't support IPv6.  the job 
  of an API is to do what the application tells it to do, not to guess what 
  the application needs.  when getaddrinfo() tries to be too clever (as it 
  does on some platforms) it gets in the way and makes it difficult just to
  do simple DNS lookups.

  this implies that a feature to avoid A or AAAA lookups on systems that
  cannot communicate on v4 or v6 (respectively) should be optional, as
  AI_ADDRCONFIG is.

- It's highly desirable to avoid unnecessary DNS queries.  DNS is too
  slow and unreliable for single queries; multiple queries only makes this
  worse.  There are various ways that DNS could be updated to return the same
  information in fewer round-trips, but none of them would obviate the need
  for hosts to do multiple concurrent queries in the near term.

- AI_ADDRCONFIG is an imperfect heuristic, not a reliable indicator of whether
  an address can be used.  that doesn't mean that it's useless, but it does
  mean that people need to be aware of its limitations and not rely on it to
  do magic - in particular, it will not do a perfect job of either avoiding
  unnecessary lookups and connection attempts, or (due to race conditions)
  of finding all usable addresses.

- getaddrinfo SHOULD ONLY DO DNS QUERIES.  LLMNR/mDNS, NIS/NIS+, netinfo, WINS
  and local file lookups only serve to cause divergence between platforms
  and problems for apps that need a consistent view of DNS.

  (Note: I don't expect to get consensus for this view, so I'll offer a 
  less radical view:   Apps whose behavior is defined based on "what DNS
  says",  rather than some other name lookup service, need a portable and
  reliable way to find out "what DNS says" without having to supply their own
  DNS lookup routines.  e.g. maybe there needs to be a AI_DNS_ONLY flag for 
  getaddrinfo?)

- if AI_ADDRCONFIG is set, the decision of whether to do DNS lookups for a
  particular address family should ignore link-local addresses as well as 
  loopback addresses.  This is in keeping with the notion that AI_ADDRCONFIG 
  is an imperfect heuristic.  The configuration of only link-local addresses 
  for a particular address family is a good (though imperfect) indicator 
  that DNS queries for that address family will not yield usable results.

  OTOH, if getaddrinfo() is set up (against my better judgement) to do 
  queries from services other than DNS, the choice of whether to query other
  services might not want to ignore link-local addresses.  For example,
  on a host with only a v4 link-local address configured it might make
  sense to query LLMNR for A records.

- IMHO, getaddrinfo()'s job should be to report what is in DNS, not to try to
  coerce apps into behaving well.  So even though apps shouldn't be using
  link-local addresses, and even though people shouldn't list link-local
  addresses in DNS, getaddrinfo() should not try to hide such addresses from
  apps if they happen to appear in DNS.

Keith

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

---

From: Stig Venaas <[email-masked]>
Date: Mon, 3 Nov 2003 16:16:26 +0100

[...]
>   apps if they happen to appear in DNS.

I can sympathize with your opinions. I think two things are needed:

o A standard call that most applications can use in a simple way. IMHO it
  should query DNS, other name services, /etc/hosts etc.

o A standard call that applications can use to check what is in DNS

The first should IMHO be something like getaddrinfo() where applications
simply try the addresses in the order they are returned. I also think it
should be possible for an administrator to define which name services
should be used, which type of addresses should be returned, and the order.

Another matter is what the API should be. Most IPv6 enabled applications
today use getaddrinfo(), while specialized DNS applications like "host"
use their own resolver routines. So I would say that getaddrinfo()
without special arguments would be good for the general applications.
For the DNS applications one could use getaddrinfo() with a new option,
or a completely new call. It's easier to change the few DNS applications
that are out there.

Stig

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Nov 2003 10:42:02 -0500

> >   coerce apps into behaving well.  So even though apps shouldn't be
> >   using link-local addresses, and even though people shouldn't list
> >   link-local addresses in DNS, getaddrinfo() should not try to hide
> >   such addresses from apps if they happen to appear in DNS.
> 
> o A standard call that most applications can use in a simple way. IMHO
>   it should query DNS, other name services, /etc/hosts etc.
> 
> The first should IMHO be something like getaddrinfo() where
> applications simply try the addresses in the order they are returned. 

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.  

> I also think it

I disagree.  Different apps have different needs, and no single
host-wide or site-wide policy can accomodate the needs of the variety of
apps in use. Also, apps often cross administrative boundaries, which
creates problems when different nodes of those apps are subjected to the
whims of different administrators.

> Another matter is what the API should be. Most IPv6 enabled
> applications today use getaddrinfo(), while specialized DNS
> applications like "host" use their own resolver routines.

It's not just specalized DNS applications that need to know what really
is in DNS.  Many apps need consistent views of DNS without having to
second-guess the local host API implementation, brain-damaged sysadmins,
etc.

Keith

---

From: Colm MacCarthaigh <[email-masked]>
Date: Mon, 3 Nov 2003 17:06:05 +0000

> difficult to get reliable and repeatable behavior that way.  

Isn't the DNS a lookup service that happens 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.

> apps in use.

A large ammount of apps have common needs; a very common need is to
translate network and service names into numbers. The vast majority
of these apps should not care whether it comes from lookupd/nscd, a 
hosts file, dns, WINS or another source.  

> Also, apps often cross administrative boundaries, which

Indeed, but to remove responsibility from administrators is to remove
power from administrators. Many administrators cherish and understand
their ability to define a search-order, over-ride domains, cache lookups.
Others misunderstand and abuse these facilities, but the primary fault
lies with those administrators - not elsewhere.

Resolving only DNS would even hinder an administrators ability to fix
these problems. Many sites have RFC1918 bogons in their zones (forward
and reverse), some even listed as MX. It can ocasionally be useful to
over-ride such sillyness locally. I'm not saying administrators should
have to work around other's problems, de-incentivising the need to really
fix them, but ocasionally we do.

> is in DNS.

I would argue that really only an application with specialised DNS
functionality (for instance an SMTP implementation) needs to know what
really is in DNS. Certainly more applications than host/dig and so on 
need to know what's really is in DNS, but I don't think the term
"specialised" is unsuited.

A the issue of link-locals in DNS, I agree that they should be returned
by getaddrinfo, for the same reason I cite below. 

> Many apps need consistent views of DNS without having to

Whilst it's extremely desirable that apps not have to deal with API
implementation inconsistency, the application writers sense of priorities
should come much lower than the local administrators IMO.

-- 
Colm MacCárthaigh                        Public Key: [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 3 Nov 2003 16:22:55 -0500

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

> 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.
 
> hosts file, dns, WINS or another source.  

That's simply insane.

Apps (and users) often care if the results from whatever lookup service
getaddrinfo/gethostname happens to use are not consistent with reality.
Apps sometimes care if the results of those lookups at different points 
in the network are not consistent with one another.

People are often claiming that apps should not use IP addresses for
referrals - that they should use DNS names instead.  Indeed, it would 
be nice for apps to be able to do that, but that would imply (among
other things) that a name means the same thing from all points of 
the application - NOT whatever some random lookup service or stale
host file happens to return to a particular host.

Every additional oracle that attempts to provide name to address translation
is another potential source of variation and error.  Every additional 
configuration knob that attempts to choose which source of name lookup should
be used (whether it be an API, a config file, or a DHCP option) is yet
another knob that can be set wrong.  All of this garbage makes applications
that ought to be portable from one host to another and one network to another,
overly sensitive to host and site configuration.  It causes bugs that are often 
difficult to troubleshoot.

> power from administrators.

It removes the power to screw things up.  I don't see this as a bad thing.

Administrators can already set the meanings of DNS names in the zones that
they control.  Why do they need multiple ways to screw things up ?

> Many administrators cherish and understand

And many administrators should be terminated with extreme prejudice, too.  

> fix them, but ocasionally we do.

Okay, fine.  Maybe admins need a way to work around occasional problems
that occur.  But we don't need a hodgepodge of different lookup methods
and APIs and configuration mechanisms that interact with each other in 
arbitrary ways that vary from one host or site to another.

> really is in DNS. 

You're wrong, of course.

> by getaddrinfo, for the same reason I cite below. 

Well, link-local addresses should never be in DNS in the first place.  
My argument is not that link-local addresses should be returned by 
getaddrinfo() , it is that getaddrinfo() should be transparent.  It 
shouldn't be yet another layer (in addition to all of the ones 
mentioned above) that is getting in the way of the app finding out 
what the DNS name means.

> should come much lower than the local administrators IMO.

Quite often local administrators forget that their purpose is to support
users, that those users need to run apps, and that for the apps to run
reliably they need a reliable and predictable environment. 

Keith

---

From: Colm MacCarthaigh <[email-masked]>
Date: Mon, 3 Nov 2003 22:41:31 +0000

> DNS is a specific lookup service.  not a random one that just might happen

NIS is a specific lookup service, as is WINS, and well I could go on ...
DNS may be more standardised, more widely-deployed and frankly - more
tasteful, but it is no more specific. It's not the only show in town :)

I don't mean to be facetious here, of course I regard DNS as the "standard"
name to number resolver, but I'm a long long way from thinking it should 
be the only means allowed for applications to resolve names.

> then at least some apps should not be using it.

Could you give some specific examples of the type of apps you're talking
about?

> getaddrinfo/gethostname happens to use are not consistent with reality.

When you say "reality", do you really mean - "DNS"? If so, what makes
DNS more authorative than the decisions of the local administrator ? 
What about site to site inconsistencies in DNS ?  

I don't think many people would argue that Global DNS names should be
broken by local administrators. But is making that slightly harder
worth heavily impairing their ability to have site-local name resolution?

> in the network are not consistent with one another.

Certainly, but since this can (and frequently does) happen with DNS on its 
own, surely the problem should be resolved more generally? I don't see how
the problem of distributed applications needing to agree on a network number
is solved by only using DNS to resolve network names. 

> host file happens to return to a particular host.

I disagree. And there are many examples of when people consider it useful
for domains to return inconsistent results. Many end-users wish to blackhole
the domains of web-banner advertiser; integral to many testing and staging 
procedures is the ability to spoof production domains; users of RFC1918
space frequently wish to resolve to different addresses depending on scope.  

Whilst all of this is possible with control over a resolving name-server
(assuming there is one), it very much removes power from the administrator
which they find useful.

> difficult to troubleshoot.

Agreed, however I view the alternative as worse. I've been involved in the
IPv6 development of widely-deployed applications, and have experience
dealing with obsure user problems, extremely tenous getaddrinfo bugs and
other such madness, and I can't think of many such problems occuring. On
the other hand, I've been saved by the ability to quickly over-ride
local name resolution more than once.

> they control.  Why do they need multiple ways to screw things up ?

Because local administrators arn't always in control of their DNS names.
All that would happen is that more local administrators would run local
DNS resolvers. It just gets you right back to square one :)

> > functionality (for instance an SMTP implementation) needs to know what

Could you provide an example ? Personally I consider lookup-agnosticism
as a good feature of getaddrinfo. It will take a lot to persuade me 
otherwise.

"really in DNS" and "globally consistent" are not equatable statements, 
because well ... they're not. Unless you're arguing for a global 
short-list of resolvers ?

The problems seen with name-resolsution inconsistency are the result
of stupid operators - they arn't going to go away. They're just going
to be stupid with DNS instead :)

> reliably they need a reliable and predictable environment. 

Totally, but it is not for an API to dictate to local administrators how
best to achieve this. Extra lookup methods can be part of providing a
more reliable and predictable environment.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Nov 2003 08:52:24 +0200 (EET)

> be the only means allowed for applications to resolve names.

My personal experience is that the lookup mechanisms are rarely fully
equivalent/replaceable.  They give different kinds of results.  
/etc/hosts and DNS are (typically) pretty close to each other, but if you
pluck in e.g. WINS, the names it'll give you are typically entirely
different (starting from the format) from those learned from DNS.

I'd expect similar inconsistancies if queries were done using LLMNR or 
ICMP Node Information Queries.

The important point here is who configures the names to be looked up.  
Looking them up e.g. in LDAP would probably yield similar results than
lookup up from the DNS (as they're very probably configured by the same
entity) -- but asking from the node itself what it thinks its name is is
*very* likely to yield different results than one would get asking his
network administrator..

I think typically we have been interested of the latter, that is, what the 
network administrator of a node thinks a node's name is (and NOT what the 
node or its user thinks!)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

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

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

what you are describing is not transparent to applications that actually
need to know what is in DNS.  

Keith

---

From: "Eugene M. Kim" <[email-masked]>
Date: Tue, 04 Nov 2003 10:59:15 -0800

(Trimmed v6ops@ from Cc: as I believe this has less to do with network 
operation.)

>need to know what is in DNS.  

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

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.

If most of the applications would be broken, it would certainly be worth 
the trouble to go for the first option (this means going through the 
lengthy process of updating POSIX as well, because these functions are 
specified in it too).

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.

I'd gladly stand corrected if there are statistics that say otherwise.

My 20 Korean Wons (1 USD ~= 1200 KRW last time I checked :p),
Eugene

---

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

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

Keith Moore wrote:

>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 
*shudder*).

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.

>>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().'

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

Regards,
Eugene

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 5 Nov 2003 07:21:31 +0900 (JST)

> defined to be equivalent of obtaining address records via res_XXX() calls.

	for dns-only query i recommend getrrsetbyname(), available in BIND9
	(if I remember correctly).

itojun

---

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

> defined to be equivalent of obtaining address records via res_XXX() calls.

That makes sense.  If you just want A/AAAA records do getservbyname()
with the DNS only flag; otherwise use res_XXX/dn_XXX.  The only problem 
is that the res_XXX/dn_XXX functions have really awkward interfaces.
But there's something to be said for stability.

> Otherwise people might start thinking that 
> whole mess 

People already *are* thinking that, and have been for many years.  IMHO 
one of the biggest botches of getaddrinfo() is the srvname parameter,
partially because it tempts people to have getaddrinfo() do SRV lookups (and
there's nothing in the specification that says not to do that) and partially
because it can cause additional errors.

(It is utterly insane to look up a symbolic constant in a file or
network-accessible database when that constant is part of the specification
for the protocol you're implementing.  When I was a sysadmin I lost track of
how many times I had to diagnose an application that was failing because 
getservbyname() for some well-known protocol returned NULL - usually because
the YP server wasn't bound or some stupid thing like that.)

> finding a similar API then victimizing it.

Agree.   In particular, lots of problems result from changing existing APIs 
in ways that introduce new failure modes.

> be. 

I'm sympathetic to that view.  I suppose I'm griping that getaddrinfo()
was a poor design that we're kind of stuck with now.   I certainly agree that 
a poor design doesn't necessarily justify a retroactive change.  

At the same time I think it might help to recommend somewhat more 
uniform behavior for getaddrinfo() - both the code and the way hosts
are configured to use it - e.g. 

- specify more precisely what it means in terms of DNS queries 
  (e.g. no SRV records)
- discourage use of proprietary or platform-specific query methods
  like NIS, NIS+, netinfo, WINS, without forbidding it entirely
- specify requirements for consistency between different services
  that provide lookup for the same names

> as if they weren't there. 

I agree with this.  We don't want to break existing apps.  But the desire
to have (more) reliable apps in the future implies a need to define components
precisely enough that apps can get repeatable behavior from them - even
when those apps run on different platforms, and in different parts of the
network.

Well, I guess I know what kind of Internet-Draft to write...

Keith

---

From: [email-masked] (Niels Möller)
Date: 05 Nov 2003 00:46:56 +0100

Keith Moore <[email-masked]> writes:

> there's nothing in the specification that says not to do that)

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. It can ask for SRV-records, and sort the returned addresses
according to some combination of SRV priority, weight and other
destination address selection rules. If no SRV was found, it can ask
for A and/or AAAA records, and use getservbyname to find the port
number. Sounds like an easy and reasonable way to deploy SRV.

Compare to the non-SRV usage scenario: I use getaddrinfo, to make my
code nice and protocol independent, and I want to use some fix port
number. Then I'll want getaddrinfo to write the number into the
returned sockaddr structures, in the nice protocol neutral way of
getaddrinfo. But to do that, I have to convert my fix number into a
*string*, and let getaddrinfo convert it back to a number. To me, that
mode of operation makes a lot less sense than having getaddrinfo
perform SRV lookups...

Regards,
/Niels

---

From: Keith Moore <[email-masked]>
Date: Tue, 4 Nov 2003 17:50:08 -0500

> lookups.

that's not a good reason, that's a disaster.  it would change the behavior
of every application on the Internet in an incompatible way, and it would
add new failure modes to every application that isn't already specified 
to use SRV.  it would also tempt NATs to tweak DNS in even more preverse
ways than they already do.

there's a reason that RFC 2782 contains the following text:

> Applicability Statement
> 
>    In general, it is expected that SRV records will be used by clients
>    for applications where the relevant protocol specification indicates
>    that clients should use the SRV record. Such specification MUST
>    define the symbolic name to be used in the Service field of the SRV
>    record as described below. It also MUST include security
>    considerations. Service SRV records SHOULD NOT be used in the absence
>                    -----------------------------------------------------
>    of such specification.
>    ---------------------

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Nov 2003 10:11:14 +0100 (CET)

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

> 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

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Nov 2003 07:07:44 -0500

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

Wrong.  One problem is that the various apps that don't use SRV 
now won't all get upgraded at once.  So when you turn on a SRV record
you will break all of the clients and servers that don't support SRV
yet.  Either that or you have to configure the server to support both
old and new ports.  Another part of the problem is that the server has to be
explicitly configured to listen on the alternate port - there's no reliable
way for the server to automatically determine this.  So SRV creates yet
another way for DNS to get out of sync with host configuration - another
knob that can be set incorrectly.

And yes, we went through a similar transition with MX records and email;
but the net was much smaller then, and this was a deliberate change to a 
single app by the people who maintained that app rather than a change to
every app made by people who had nothing to do with most of those apps.  
Even so, my recollection that it wasn't until the mid-1990s that you could
count on MTAs recognizing MX records, even though RFC 974 was published 
in 1986.  I'd expect the net to transition even more slowly today.
 
> > it would also tempt NATs to tweak DNS in even more preverse
> 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.

NAT vendors do stupid things all the time, like producing NATs that
modify the contents of packets where they don't even know what protocol
is being used.  What makes you think they would stop there?

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

and the server has to listen on that port and honor requests.

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

Funny, you want the admin to have this choice, but you apparently
don't want the application specification to have a choice (as RFC 2782
insists must be done)

SRV can be useful, but its utility varies widely depending on the
application.  For some apps it's completely inappropriate.  Should
ping honor SRV?  What about ssh?  SNMP?  NFS?  FTP?  Sometimes a
domain names a service; sometimes it names a host.

and is it really worth it to double the time required to do DNS lookups
FOR EVERY APP, when DNS lookups are already abysmally slow and unreliable?

> My current interest in SRV is that I'm hacking Ian Jackson's resolver
> library "adns" to support IPv6 and SRV. 

That's fine and useful as long as you make the SRV lookup optional.
Apps need to choose whether they want to do SRV or not; not have that
choice made for them.

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

The reason is: it violates the SRV specification to use SRV with an app
that doesn't specify the use of SRV, and it also violates the specifications 
of those applications that specify a port number to be used.

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

It does.  I believe there's a spec for use of SRV with Kerberos also.
I am fairly confident that ftp, http SRV records are bogus and should
not be honored by standards-conforming clients.

Keith

---

From: [email-masked] (Niels Möller)
Date: 05 Nov 2003 18:09:13 +0100

> is being used.  What makes you think they would stop there?

*No* protocol can work under the assumption that there's a NAT box on
the path that makes arbitrarily stupid changes to packets. Therefore,
it's not possible or useful to consider that scenario in protocol or
application design.

> don't want the application specification to have a choice (as RFC 2782

The default ssh port is 22. Say that I operate an ssh server, and for some
arbitrary reason I want it to listen on a different port, say 80. To
make this work, I can send out a mail to all my users telling them to
use ssh -p 80, and hope they read and remember that. Or I could
install an SRV record in the DNS tree that says that I'm using port
80, and hope the the users' ssh clients will notice. Or both.

The ssh spec only says that "the server normally listens for
connections on port 22", and that the number is registered with IANA.
Just descriptive, no normative language at all. Given that, I can't
read the ssh spec as saying which methods, email or SRV or a sign on
the wall, I may use to tell my user's and their ssh clients that I use
a different port.

> ping honor SRV?

To use SRV for ICMP ping seems quite far out.

> What about ssh?  SNMP?  NFS?  FTP?  Sometimes a

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.

> not be honored by standards-conforming clients.

Thanks for the answers, even if I'm not totally convinced.

Let's look at http again, where the spec for http-url:s says clearly
that of no port number is given explicitly, port 80 should be used
(the text is descriptive here too, "if the port is empty or not given,
port 80 is assumed"). Say I have a SRV aware browser that breaks the
spec and looks up _http._tcp SRV records, and uses ports given in SRV
records instead of the default port 80. Then my SRV aware browser and
a traditional browser will get different content for the same URL,
which seems like a bad thing. But that's not a new problem. One
example is http://www.kame.net (CNAME orange.kame.net), where you,
intentionally, get slightly different content for the same URL
depending on whether or not your browser and operating system happen
to use IPv6. I'm not sure it's a real problem that this kind of
"misconfiguration" is possible.

Regards,
/Niels

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Nov 2003 12:42:02 -0500

> > modify the contents of packets where they don't even know what
> > protocol is being used.  What makes you think they would stop there?
> 

No, but it is entirely reasonable to realize that having applications 
support SRV is a temptation for NAPT boxes to intercept DNS queries
for SRV records, allocate an external port for that service, map it
to the internal address and default port for that service, and returning

A SRV record that indicates the external port - thus furthering the 
pollution of the network.

> > don't want the application specification to have a choice (as RFC
> > 2782 insists must be done)
> 
> The default ssh port is 22. Say that I operate an ssh server, and for
> some arbitrary reason I want it to listen on a different port, say 80.
> To make this work, I can send out a mail to all my users telling them
> to use ssh -p 80, and hope they read and remember that. Or I could

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.

The point is - it's not within either the purview of the DNSext group,
or the network administrator, to change how the ssh application
operates.  Unilaterally imposing SRV records violates the expectations
behind the design of the app, and may violate users' expectations also.

> To use SRV for ICMP ping seems quite far out.

To use SRV for lots of protocols seems far out.  ICMP is just one end
of a broad spectrum.

> particular service instance.

Nor, for that matter, can the DNS server administrator.

> > The reason is: it violates the SRV specification to use SRV with an
> > app that doesn't specify the use of SRV, and it also violates the
> > specifications of those applications that specify a port number to
> > be used.
> 
> > I am fairly confident that ftp, http SRV records are bogus and
> > should not be honored by standards-conforming clients.
> 
> records instead of the default port 80. 

There's WAY too much code out there that assumes that the lack of an
explicit port number in an HTTP URL means port 80.  Imposing SRV on HTTP
would break all of that code. 

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.

It's incredibly naive to think that you unilaterally can change an
interface used by nearly all apps and not break things.  To insist on 
doing it anyway is criminally irresponsible.

Keith

---

From: [email-masked] (Niels Möller)
Date: 05 Nov 2003 22:56:38 +0100

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

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

> 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, but it still seems like it could be a
real problem with using SRV records for http.

Regards,
/Niels