Subject: Re: DNS SRV question (was Re: please post updated draft)

From: Jeffrey Altman <[email-masked]>
Date: Tue, 26 Oct 99 13:43:48 EDT

> On Thu, Oct 21, 1999 at 03:10:39PM -0700, Levon Esibov (Exchange) wrote:
>>> Or is this meant to refer to a *public* specification?  If so, then
>>> how does that jibe with the "locally defined" services mentioned
>>> earlier?
>>> 
>> You correction is taken. I'll remove the "Only locally defined services may
>> be named locally." from the text if there are no objections.
> 
> Oh boy, that wasn't my intent at all.  I think that locally defined
> services should *stay* in the specification.
> 
> I was hoping to remove the statement "Service SRV records SHOULD NOT
> be used in the absence of such specification."  It's completely
> unenforceable, and anyone who wants to use SRV records for their own
> use (presumably one that has no applicability to the Internet at
> large) will have problems if they want to remain RFC compliant.

I have been trying to make the case for this since Oslo.  But
apparently the IESG opposition to this is so high that any reference
to DNS SRV being allowed for use with protocols that do not specificly
require it will result in the I-D being rejected for Standards Track
RFC status.
 
> What is so wrong with just making it clear that IF you are using a
> service type assigned via STD 2 you MUST use the protocol specified
> for that service type?
> 
> If there is concern about people using a service type inappropriately
> and/or colliding with a non-local service type, why not declare that
> all local service types must start with a double underscore, rather
> than the single underscore that STD 2 types do.
> (i.e. "__mylocalservicetype").  They will then be protected against
> DNS labels that occur in nature, as well as those that occur in STD 2.

I'm not sure that this would be helpful.  My library routine that
replaces getservbyname() takes a service name and protocol name and
then generates a DNS SRV query and if that fails then attempts a
SERVICES file lookup.  Adding the additional underscore would require
that I perform two DNS SRV queries instead of just one.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: David Shaw <[email-masked]>
Date: Tue, 26 Oct 1999 14:01:14 -0400

> that I perform two DNS SRV queries instead of just one.

Understood.

How about doing what many protocol specifications have done by now and
declaring that there will be no "official" services defined with a
name that begins with "x-"?  Thus all unofficial services can be
located easily in SRV or /etc/services.

The real issue, of course, is the wording in the SRV document.  Why
can't it just be accepted that people are going to use SRVs for stuff
that simply has no relevance to the Internet at large, but may be very
relevant/useful/necessary for the local site that is using it?

David

-- 
   David Shaw  |  [email-masked]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson

---

From: Martin Hamilton <[email-masked]>
Date: Wed, 27 Oct 1999 09:04:15 +0100

Jeffrey Altman writes:

| I'm not sure that this would be helpful.  My library routine that
| replaces getservbyname() takes a service name and protocol name and
| then generates a DNS SRV query and if that fails then attempts a
| SERVICES file lookup.  Adding the additional underscore would require
| that I perform two DNS SRV queries instead of just one.

Jeffrey - is that code available to download ?  I'd like to add it to 
the Squid Web Cache for use with (deep intake of breath :-) H-T-T-P!

Cheers,

Martin

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Oct 1999 13:20:01 -0400

> relevant/useful/necessary for the local site that is using it?

It is accepted, people will do that, and in some cases that is fine
(i.e., in a private deployment environment --- if there is such a
thing). The point of the disputed text is to discourage that from
happening (since when has text in a document prevented folks from
doing what they want!!), it is to make it clear that doing so is
non-standard. Consequently, if folks do this in ill-conceived ways and
it leads to real deployment problems, folks can point to the spec and
say "hey, what your doing is broken". Likewise, vendors can't say "the
spec allows us to do what we are doing, don't complain to us".

Also, think about this a bit. For existing deployed services, having
some random client decide it wants to do SRV lookups for a name can
lead to operational problems at sites that aren't using them (e.g., if
clients at one site get upgraded but those clients make use of servers
elsewhere not administered by the same authority as those
clients). And why should they? No standard says they should support
SRVs for their particular service, and their deployed infrastrucure
may not even support them. The point of documenting this is so some
thought goes into how to deal with transition issues between non-SRV
usage and SRV usage and that any application-specific issues get dealt
with appropriately.

Thomas

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 27 Oct 1999 14:06:40 -0700

SRV was originally designed to be overlaid on any traditional A-based service:

|Domain administrator advice
|
|   Asking everyone to update their telnet (for example) clients when the
|   first internet site adds a SRV RR for Telnet/TCP is futile (even if
|   desirable).  Therefore SRV will have to coexist with A record lookups
|   for a long time, and DNS administrators should try to provide A
|   records to support old clients:
|
|      - Where the services for a single domain are spread over several
|        hosts, it seems advisable to have a list of A RRs at the same
|        DNS node as the SRV RR, listing reasonable (if perhaps
|        suboptimal) fallback hosts for Telnet, NNTP and other protocols
|        likely to be used with this name.  Note that some programs only
|        try the first address they get back from e.g. gethostbyname(),
|        and we don't know how widespread this behaviour is.
|
|      - Where one service is provided by several hosts, one can either
|        provide A records for all the hosts (in which case the round-
|        robin mechanism, where available, will share the load equally)
|        or just for one (presumably the fastest).
|
|      - If a host is intended to provide a service only when the main
|        server(s) is/are down, it probably shouldn't be listed in A
|        records.
|
|      - Hosts that are referenced by backup A records must use the port
|        number specified in Assigned Numbers for the service.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 27 Oct 1999 17:31:48 -0400

> SRV was originally designed to be overlaid on any traditional A-based

This description takes the view of a site wishing to deploy SRV and
how it needs to deal with backwards compatability and old clients.

There is the another side to the story as well. A site that has no
intention of using SRVs (for whatever reason) can be forced to deal
with them because clients it does not control start generating SRV
queries that hit its servers.  It would appear that how best to deal
with this scenario depends on the application. I.e., an application
with relatively few deployed clients might just make the switch. Other
applications might involve huge numbers of SRV-capable clients
appearing overnight (i.e, new browser release). They might want to
handle the transition differently.

Whether or not HTTP clients should use SRV is really for the web folks
to decide.

Thomas

---

From: John Gilmore <[email-masked]>
Date: Wed, 27 Oct 1999 17:09:36 -0700

[In what follows I claim to speak for the IESG.  I'm not part of the
IESG nor was involved in this decision.  I think I understand their
concerns, which is why I'm explaining them this way here.  If anyone
from IESG would prefer to carry on the discussion, I'll gladly retire
from it.]

The reason the IESG is so bothered about people applying SRV to existing
protocols is that doing so changes the protocol.

In the last day we've had two people describe how they are using, or
want to use, SRV with pre-existing, very widely deployed protocols:

> From: Jeffrey Altman <[email-masked]>
> For implementing secure telnet we use a non-standard port number and a
> client that uses DNS SRV to find out the port to use for telnet. 

> From: Martin Hamilton <[email-masked]>

This is ***exactly*** the thing the IESG is deliberately taking a
stand against!

The HTTP protocol works.  If some servers start depending on 
SRV lookups to make their HTTP protocol work, and some clients
start using SRV lookups while others implement the documented
standard in the RFCs, then suddenly different people (supposedly
implementing the same protocol) get different results.  IESG wants
it real damn clear that the guys using SRV are the ones with the
broken implementation, not the guys blithely following the RFC's.

Jeffrey Altman said:
> I really don't understand the IESG's problem with using DNS SRV to
> specify port numbers, priorities, and weights for IETF protocols that
> do not make it a requirement.  

At the moment there is a very clear specification of when to use SRV
with HTTP:  **NEVER**.  The same is true of Telnet.  You guys want to 
muddy the waters.  Let us pray that you fail.

People who want to do something "http-like" but include a SRV lookup
need to define a new protocol; call it HTSRV or something.  Then
whether SRV is appropriate for *that* protocol can be discussed.  IESG
decided that SRV is *not* appropriate for any existing standardized
protocol, and will remain inappropriate until if-and-when a newly
revised standard is defined by the IETF process that changes that.

(Jeffrey, if you need a secure telnet on a different port, and are
hacking your client and server anyway, use a locally assigned port
number and run the service there.  Don't screw things up with
a SRV record because you have one broken telnet client program.)

(Martin, if URNs need to do a SRV lookup, define a protocol that shall
be used to do the lookup, and new applications can choose to use it or
not.  But back-patching HTTP incompatibly is **not** the answer.)

The feeding frenzy to mangle existing protocols with SRV reminds me of
the economists' famous "tragedy of the commons".  People have a
tendency to go for something that makes their individual life easier
(let's just scam the protocol by attaching this little thing on the
side) while polluting and destroying the commons of the Internet (global
interoperability).  Remember what life was like when everybody had
a different network and ran different protocols and they didn't
interconnect?  Do you really want to go back to that?

	John Gilmore

---

From: Terry Lambert <[email-masked]>
Date: Wed, 27 Oct 1999 16:35:55 -0700

Thomas Narten wrote:
> The point of the disputed text is to discourage that from
> happening (since when has text in a document prevented folks
> from doing what they want!!), it is to make it clear that
> doing so is non-standard. Consequently, if folks do this in
> ill-conceived ways and it leads to real deployment problems,
> folks can point to the spec and say "hey, what your doing is
> broken". Likewise, vendors can't say "the spec allows us to
> do what we are doing, don't complain to us".

Actually, all of the above statements, with the exception of
"to discourage that from happening" can't be said, unless the
wording were "MUST NOT" instead of "SHOULD NOT".

I think this is a tempest in a teacup, and it's time to move
one (and approve the thing), since it doesn't prohibit what
the detractors want to do with the records, just discourages
it from being done.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.