headers
Dave Crocker | 6 Nov 20:03

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

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.
(Continue reading)

Permalink | Reply |
headers
Keith Moore | 8 Nov 20:41
Picon

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

> 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.
Permalink | Reply |
headers
Stig Venaas | 8 Nov 18:26
Picon
Picon

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

Keith Moore wrote:
[...]
> 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.
> 

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
Permalink | Reply |
headers
Keith Moore | 8 Nov 22:12
Picon

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


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

> Keith Moore wrote:
> [...]
>> 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.
>>
> 
> 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.

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
(Continue reading)

Permalink | Reply |
headers
Ned Freed | 6 Nov 22:53

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

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

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.

> ...

> 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?)
(Continue reading)

Permalink | Reply |
headers
Eliot Lear | 9 Nov 02:34
Picon
Favicon

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

Ned Freed wrote:
>> 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?
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
Permalink | Reply |
headers
Ned Freed | 9 Nov 19:49

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

> Ned Freed wrote:
> >> 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?
> 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 ;-)

I fully support all of these goals.

				Ned
Permalink | Reply |
headers
Chris Newman | 10 Nov 00:33
Picon

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

Ned Freed wrote on 11/9/06 10:49 -0800:
>> Ned Freed wrote:
>> >> 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?
>> 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 ;-)
>
> 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
Permalink | Reply |
headers
Dave Crocker | 9 Nov 20:10

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


Ned Freed wrote:
>> 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 
> 
> I fully support all of these goals.

+1

--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
Permalink | Reply |
headers
Philip Guenther | 6 Nov 23:15
Favicon

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

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.
(Continue reading)

Permalink | Reply |
headers
Stig Venaas | 7 Nov 15:41
Picon
Picon

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

Philip Guenther wrote:
> On Mon, 6 Nov 2006, Ned Freed wrote:
>> I wasn't entirely clear on what Eliot was trying to say about SRV 
>> records.
>> Perhaps someone could recap that here?
> 
> 
> 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

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

> 
> 
> Philip Guenther
(Continue reading)

Permalink | Reply |
headers
Ned Freed | 6 Nov 23:16

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

> 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.
(Continue reading)

Permalink | Reply |
headers
Dave Crocker | 6 Nov 23:32

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


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
   Brandenburg InternetWorking
   bbiw.net
Permalink | Reply |
headers
Ned Freed | 6 Nov 23:50

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


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

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
Permalink | Reply |
headers
Randall Gellens | 6 Nov 22:53

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

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.
>
>  So changing our model to focus on SRV has some interesting implications.

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
Permalink | Reply |

Gmane