Subject: Service vs. Port vs. SRV (following Eliot's presentation)

From: Dave Crocker <[email-masked]>
Date: Mon, 06 Nov 2006 11:03:29 -0800

Folks,

This is in response to Eliot's presentation this morning, in the AppsArea and it 
is merely intended to solicit comment:

I have always understood the construct of Well-Known Ports as being a means of 
standardizing an efficient rendezvous mechanism, for clients to find servers. -- 
without quibbling about the terminology that might better cover use in 
peer-to-peer scenarios.

This creates a means of associating a "channel" to a protocol, in order to 
achieve a "service".

By way of example, SMTP and SUBMIT are (essentially) the same protocol, but they 
are different services (initial MUA-MSA posting, versus MSA/MTA or MTA-MTA or 
MTA/MDA relaying.)

In effect, Port 25 vs. Port 587 define the two different sservice.

SRV clearly serves as a more generalized and long-term mechanism for defining a 
service (and, gosh, doesn't that make the choice of the RR's name particularly 
nice?)

As Eliot notes, however, this builds a dependency on the DNS into the underlying 
construct of IP-to-IP rendezvous.  While most of the Internet use today already 
has that dependency as a pragmatic realtion, for other reasons, it is not built 
into the basics of Internet infrastructure as a formal requirement.

So changing our model to focus on SRV has some interesting implications.

Thoughts?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Randall Gellens <[email-masked]>
Date: Mon, 6 Nov 2006 13:53:35 -0800

At 11:03 AM -0800 11/6/06, Dave Crocker wrote:

>  SRV clearly serves as a more generalized and long-term mechanism 
> for defining a service (and, gosh, doesn't that make the choice of 
> the RR's name particularly nice?)
>
>  As Eliot notes, however, this builds a dependency on the DNS into 
> the underlying construct of IP-to-IP rendezvous.  While most of the 
> Internet use today already has that dependency as a pragmatic 
> realtion, for other reasons, it is not built into the basics of 
> Internet infrastructure as a formal requirement.
>

The implications may depend on who is included in "our" (in "changing 
our model").  A lot of application-level protocols already do, as you 
note, depend on DNS.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I distrust those people who know so well what God wants them to
do, because I notice it always coincides with their own desires.
    --Susan B. Anthony

---

From: Ned Freed <[email-masked]>
Date: Mon, 06 Nov 2006 13:53:27 -0800 (PST)

> without quibbling about the terminology that might better cover use in

I think you're talking past each other here. You're referring to our practice
of saying things like "SMTP servers listen on port 25 by default" or "HTTP
servers normally listen on port 80". Eliot is talking about ports with
numeric values less than 1024 being handled distinctly from those above
1024.

I am complete agree with Eliot that the "below 1024 are special" notion's time
has long since past. It made sense back in the mainframe era, but it was over
the minute we started putting machines directly under the control of random
users.

I certainly don't want to abandon the practice of defining ports associated
with specific services and I don't think Eliot is saying that either.

> ...

> So changing our model to focus on SRV has some interesting implications.

I wasn't entirely clear on what Eliot was trying to say about SRV records.
Perhaps someone could recap that here?

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 06 Nov 2006 14:16:55 -0800 (PST)

> On Mon, 6 Nov 2006, Ned Freed wrote:
> >> This is in response to Eliot's presentation this morning, in the
> >> AppsArea and it is merely intended to solicit comment:
> >
> >> I have always understood the construct of Well-Known Ports as being a
> >> means of standardizing an efficient rendezvous mechanism, for clients
> >> to find servers. -- without quibbling about the terminology that might
> >> better cover use in peer-to-peer scenarios.
> >
> > I think you're talking past each other here. You're referring to our
> > practice of saying things like "SMTP servers listen on port 25 by
> > default" or "HTTP servers normally listen on port 80". Eliot is talking
> > about ports with numeric values less than 1024 being handled distinctly
> > from those above 1024.

> Elliot was talking about both in his presentation.  The first bit was this
> whole thing involving ports 0 to 1023 (which the registry calls "Well
> Known Ports").  The second bit was the recommendation that new protocols
> should consider using SRV instead of having a particular port number.

> > I am complete agree with Eliot that the "below 1024 are special"
> > notion's time has long since past. It made sense back in the mainframe
> > era, but it was over the minute we started putting machines directly
> > under the control of random users.

> I agree.

> > I certainly don't want to abandon the practice of defining ports
> > associated with specific services and I don't think Eliot is saying that
> > either.

> He didn't suggest that, as it's impossible for protocols below DNS or that
> cannot afford to depend on DNS.

> SRV records good:
>   - provides fallback/load-balance location mechanism
>   - avoids tight port # binding
>   - namespace of assignments is strings (that can be a DNS label) instead
>     of 16bit numbers

> SRV records bad:
>   - add dependency on DNS
>   - add latency on first connect, maybe later
>   - complexity

I agree with all of this. On balance I don't think we use SRV records often
enough, but I also think there's a point past which they'd be overused.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Mon, 06 Nov 2006 14:31:14 -0800

Randall Gellens wrote:
> The implications may depend on who is included in "our" (in "changing our
> model").  A lot of application-level protocols already do, as you note,
> depend on DNS.

sorry for being fuzzy.  i mean 'out model' as in 'our transport/ip' model, which
currently does not rely on the DNS.  I believe that re-targeting service
selection to be in terms of SRV records changes this.  (I'm not offering an
opinion about whether to do this, but am merely noting the import -- and I am
merely echoing what others have said before.)

Ned Freed wrote:
> numeric values less than 1024 being handled distinctly from those above 1024.

I heard him make comments that seemed to clearly indicate that *some* 
infrastructure service almost certainly need to stay with port numbers.  He 
cited examples.

> I am complete agree with Eliot that the "below 1024 are special" notion's
> time has long since past.

I too heard the reference, but didn't hear any of the rest of his comments 
seeming to be related to the security function that the 1024 block was initially 
used for.  So I decided the 1024-is-special reference was useful mostly as an 
introduction to the discussion rather than intended to be a technical focus on 
what followed.

Might not be what Eliot meant, but it worked for me...

> with specific services and I don't think Eliot is saying that either.

Actually, I heard a suggestion that we move to using SRV *instead of reserved 
port numbers* as a long-term model.

That the model might apply in some cases and not others (as per the 
infrastructure services point, above) seemed like an issue for further discussion.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 06 Nov 2006 14:32:41 -0800

Ned Freed wrote:
> ..., but I also think there's a point past which they'd be overused.

Can you characterize that limit in some technical or administrative terms?

d/
-- 

   Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Mon, 06 Nov 2006 14:50:42 -0800 (PST)

> Can you characterize that limit in some technical or administrative terms?

I think Phillip's pro and con lists are a start at expressing the criteria for
making a selection between the two mechanisms. There are some clear cases at
the edges, e.g. services that run "below" DNS or which have real time response
requirement cannot use SRV, and services that need lots of redundant servers
with fallback and prioritization should use SRV instead of a bunch of A
records.

We specified use of SRV records in the MSGTRK work and it seems entirely
appropriate to use them in that case. I don't have a candidate protocol
currently being developed in mind where I'd like to see SRV records used, but
sooner or later there will be one.

				Ned

---

From: Philip Guenther <[email-masked]>
Date: Mon, 6 Nov 2006 14:15:26 -0800

I agree.

SRV records good:

SRV records bad:
  - add dependency on DNS

Philip Guenther

---

From: Stig Venaas <[email-masked]>
Date: Tue, 07 Nov 2006 15:41:00 +0100

>  - add latency on first connect, maybe later

Another issue is that there is no standardised API (AFAIK) for
retrieving SRV records. It would be good to have some standard
API to make it easier to write portable applications using SRV.

Not sure if IETF is the right place, but we have done things
like getaddrinfo()...

Stig

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Nov 2006 14:41:48 -0500

> So changing our model to focus on SRV has some interesting implications.

for instance,

SRV puts more fine-grained control in the hands of a DNS administrator - 
  even in cases where the host owner and DNS admin aren't part of the 
same entity.  (do you really want your ISP dictating which ports you run 
services on, or being able to vector traffic intended for your host to 
other hosts?)

SRV slows down connection establishment.  we already have a lot of 
overhead in DNS lookups (A + AAAA records and sometimes PTR records), 
TCP setup, SSL/TLS setup, etc.

SRV has the potential to create problems if retroactively applied to 
existing apps as the behavior of a SRV-aware client will differ from 
that of a non-SRV-aware client.

the design of getaddrinfo() is such that it could be used to do SRV 
lookup, but (if not done carefully) this would break that aren't defined 
to use SRV.

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Nov 2006 14:45:00 -0500

> sorry for being fuzzy.  i mean 'out model' as in 'our transport/ip'
> model, which currently does not rely on the DNS.  I believe that
> re-targeting service selection to be in terms of SRV records changes
> this.

I think it moves us further down a slippery slope.  DNS isn't nearly as
robust as IP, and every additional DNS query not only slows things down 
but also decreases the reliability of the application.

Keith

---

From: Stig Venaas <[email-masked]>
Date: Wed, 08 Nov 2006 18:26:19 +0100

Keith Moore wrote:
[...]
> lookup, but (if not done carefully) this would break that aren't defined 

As I wrote earlier, I believe some standard API for SRV lookups is
needed. getaddrinfo() would be okay for that, but one should probably 
add a new flag (e.g. AI_SRV), where apps specifically set this flag if
they want to do SRV lookups. I would be happy to discuss a possible
API if that is appropriate.

I've personally written SRV lookup code for different platforms, and
I think it's bad to require every application writer to go through
this exercise.

Stig

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Nov 2006 16:12:10 -0500

-------- Original Message --------

>> lookup, but (if not done carefully) this would break that aren't 
>> defined to use SRV.
>>
> 

in general I think DNS APIs need a lot of work.  one problem with 
getaddrinfo() is that it isn't specific to DNS - you don't know where 
it's getting its information.  it might be DNS, it might be a hosts 
file, it might be LLMNR, it might be NIS, it might be something else. 
how can you write apps that perform reliably with such an interface?

that, and getaddrinfo() is a pretty bizarre interface, and I've seen it 
fail in strange ways on various platforms because it encourages the 
caller to include irrelevant information in the call - for instance, 
there's really no reason to include the service name in a DNS lookup 
query _unless_ it's to do a SRV lookup.  (why in the world we think it's 
a good idea to make a program depend on a function that maps one 
constant to another is beyond me.  hard coding "smtp" is no better than 
hard coding "25".  not that there's anything wrong with hard coding a 
constant that is a defined element of the protocol.)

Keith

---

From: Eliot Lear <[email-masked]>
Date: Wed, 08 Nov 2006 17:34:32 -0800

> Perhaps someone could recap that here?
I guess that someone should be me ;-)

There are three goals of my draft:

   1. Get rid of the notion that < 1024 is special;
   2. Encourage documentation of port number usage; and
   3. Have developers consider the use of SRV records.  SRV records may
      be appropriate in some circumstances and not in others.  For
      instance, I wouldn't recommend SRV records for an IGP or for BGP ;-)

Eliot

---

From: Ned Freed <[email-masked]>
Date: Thu, 09 Nov 2006 10:49:43 -0800 (PST)

>       instance, I wouldn't recommend SRV records for an IGP or for BGP ;-)

I fully support all of these goals.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Thu, 09 Nov 2006 11:10:33 -0800

Ned Freed wrote:
>>       instance, I wouldn't recommend SRV records for an IGP or for BGP 
> 

+1

-- 

   Dave Crocker

---

From: Chris Newman <[email-masked]>
Date: Thu, 09 Nov 2006 15:33:56 -0800

> I fully support all of these goals.

Port numbers < 1000 are special in that they have fewer characters and are 
simpler to remember.  Reserving them for IETF standards track protocols is not 
necessarily a bad thing.  But pretending < 1024 have any real security 
characteristics other than being inconvenient to implement on most Unix 
variants would be foolish.

                - Chris

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Nov 2006 11:10:19 -0500

>> that, and getaddrinfo() is a pretty bizarre interface, and I've seen
>> it fail in strange ways on various platforms because it encourages the
>> query _unless_ it's to do a SRV lookup.  (why in the world we think
>> it's a good idea to make a program depend on a function that maps one
>> constant to another is beyond me.  hard coding "smtp" is no better
>> than hard coding "25".  not that there's anything wrong with hard
>> coding a constant that is a defined element of the protocol.)
> 
> Some implementations of getaddrinfo look up "smtp" from a local
> database (i.e., /etc/services), so presumably it serves a purpose
> without SRV's if someone which to change the port used for SMTP on a
> system.

Not in the case of SMTP, because 25 is a defined constant that is 
inherently part of the protocol.  Even if you wanted to run SMTP over a 
port other than 25, it wouldn't change the fact that the way you send 
mail to domain foo (in the absence of explicit agreement) is to talk to 
port 25 on one of the MX servers for domain foo.  You wouldn't want to 
change the definition of "smtp" to do that, you'd want to override use 
of port 25 for that specific case.

For some reason there's a temptation to believe that somehow "smtp" is 
more meaningful than 25, that we should write our code in terms of a 
string constant that isn't part of the protocol we're implementing 
rather than in terms of a numeric constant that is carried on the wire. 
  I think this comes from the practice of using symbolic constants when 
writing computer programs, where

port = htons(SMTP);

is more readable than

port = htons(25);

But it's a leap to assume that

port = getsrvbyname ("smtp", "tcp");

or having getaddrinfo() do the lookup, are improvements over either of 
the above.  the SMTP protocol is not likely to change, so there's no 
benefit and much to lose from the late binding.

> However, I agree that we need better DNS API's.  It would be nice to
> have a standardized API to query for any DNS type in C.  There are
> various libraries out there (e.g., GNU adns,
> <http://www.chiark.greenend.org.uk/~ian/adns/>) but none that in my
> experience that have been widely used.  Other programming languages
> seem better in this regard, alas -- e.g., there are good API's in
> Perl.  I'm not sure the IETF is the best place for that kind of work,
> though..

It's hard to imagine a better place.  DNS is an IETF protocol, and 
nobody understands DNS as well as IETF people.

Keith