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

From: Jeffrey Altman <[email-masked]>
Date: Fri, 29 Oct 99 13:01:57 EDT

> At 17:48 28.10.99 -0700, Randy Bush wrote:
> >a lot of traffic over one draft on our full plate.  could someone sum up the
> >'discussion' in a somewhat balanced manner?
> 
> I can hardly be called balanced, but....
> 
> - Everyone agrees that this document needs to go forward.
> - No technical changes to the record format have been proposed.
> - People disagree about whether the warnings and SHOULD NOTs currently in the
>    document are too strong, too weak, or exactly right.
> - There are problems with defining how to use SRV for locally-defined
>    services.
> - I believe Paul Vixie holds the editor token, and Keith Moore holds the
>    IESG token. If those 2 agree that it can go forward, we're done.
> 
> Is that a rough summary?

Harald, well done.

In a note that was privately sent to John Gilmore I believe I have hit
the nail on the head with what I consider to be the one remaining
problem with this draft:

  The sentence "Service SRV records SHOULD NOT be used in the absence
  of such specification." makes no attempt to describe the concerns
  that the IESG (and some members of this list) have with the use of
  DNS SRV in conjunction with other protocols.  This sentence is too 
  general and  either too strong and should be removed entirely or is
  too weak and needs to be strengthened.

According to this sentence, the only thing that prevents me from using
DNS SRV with the "telnet" service (which is distinct from the telnet
protocol) is that I have not published an I-D entitled "How to use DNS
SRV with the Telnet Services".  "Such an I-D would say to use

  _telnet._tcp.<host or domain> IN SRV p w port hostname.

It would then copy the Security Considerations section of 2052bis and
state that due to the fact that not all Telnet clients support DNS SRV
that it is possible that if DNS SRV is being used to advertise a
service on a port other than port 23; and if the "hostname" does not
match the "host or domain" name that not all clients will be able to
find it.   And of course that DNS is an unauthenticated service and
therefore its results should not be trusted in the absense of some
other form of mutual authentication between the client and the
server.

In this light the statement is too strong because it results in the
need for I-Ds to be published when the use of DNS SRV really has
nothing at all to do with the protocol in question.  DNS SRV provides
a method for distributing service location information.  I don't know
of very many protocol RFCs that specify that the location of a service
is to be determined by calling gethostbyname() and getservbyname()
which in turn will look at the local /etc/hosts and /etc/services
files or contact a DNS or NIS or other directory service.  Where a
client application goes to get the service location information is
usually left up to the implementor.  Whether I use DNS SRV or a local
configuration file to determine the location of the service I want to
connect to does not affect what goes on the wire when I am using the
protocol (ie, telnet) after establishing the connection.  Do you see
my point?

Now clearly there is some concern that the establishment of DNS SRV as
a mechanism for distributing service location information to clients
may be mis-implemented.  I'm not sure exactly what should be done
about that.  I would much rather have a well defined MUST NOT section
in the RFC than have an overly general SHOULD NOT with no explanation
for why implementors SHOULD NOT.  The "Implementor advice" section
already describes co-existance issues; when round robin should not be
used; when second servers should or should not be listed.  

If there is a security issue that is not currently covered by the
"Security Considerations" section then it obviously should be added.

Harald, perhaps you can come up with a well worded MUST NOT
restriction to guide potential implementors since you clearly have a
better understanding of the issue than I do.

    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: Thomas Narten <[email-masked]>
Date: Fri, 29 Oct 1999 15:29:29 -0400

> other form of mutual authentication between the client and the

There is one other small detail needed. The ID needs to become an RFC,
which entails review and approval by the community. That is the real
point of the exercise, i.e., to ensure the community has reviewed the
proposed change and agrees that it is reasonable for the particular
application at issue.

Thomas