Subject: Re: Brief summary of Oslo DNSIND/DNSSEC meeting

From: Jeffrey Altman <[email-masked]>
Date: Mon, 12 Jul 99 22:54:54 EDT

> 
> What ought be done with 2052bis was discussed.   General opinion favoured
> continuing to push it as PS.   A long list of IESG requested changes were
> discussed (these to appear on the list soon).   Aside from a bunch of
> trivial changes, the two of most substance concerned the definition of
> the weight field, and its processing - the suggested wording for that will
> still need some more work (either rephrasing, or a complete new method)
> but was generally considered acceptable.   The other concerned the examples.
> There was much feeling that giving examples using protocols that don't
> use SRV records was not a good idea (and that the examples/test that relate
> to SMTP was particularly bad).   What to replace them with wasn't
> as obvious.   There were two basic suggestions - either use some of the
> protocols/usages that are now being created (there are a few in drafts
> scattered about, I will probably find some of them for the next, longer,
> message on 2052bis, but please, everyone, send pointers if you know them).
> Or, create a fictitious protocol, the foobar protocol, or something, and
> use that for the examples.   I detected no consensus on which is the best
> approach.

As was mentioned during the WG there is a significant chicken and egg 
scenario in this process.  One of the most interesting aspects of the
IESG complaint is that the examples complaint is being leveled against
a draft which is meant to replace an existing Experimental RFC that 
has used similar examples for quite some time.  

When I look at the SRV RR records and this draft I see it as a way of
accomplishing two goals which are now achieved by dubious methods:

(1) SRV RR records allow a host administrator to implement a 
    distributed getservbyname() which facilitates new
    services on their networks without:

    (a) requiring their users to add new configuration information
        to their etc/services (or equivalent) file.  This is
        especially important on certain PC operating systems that
        do not provide complete nor up to date copies of
        http://www.isi.edu/in-notes/iana/assignments/port-numbers

    (b) hard coding service name to port number assignments into
        applications in case the entry is not in the etc/services
        file

(2) SRV RR records allow a host adminstrator to redirect a service
    for a domain of machines to a particular subset of those hosts.
    This is of particular use in University lab environments where
    it is desired to not have remote telnet or ssh users logging
    into all of the publicly accessed machines.  In many cases a
    small number of higher power servers in the lab are the ones
    which the adminstrators desire the remote traffic to be handled
    whereas the smaller systems are dedicated to console use.

    A set of _telnet._tcp.domain IN SRV records for each of the
    desired servers does accomplish this purpose quite cleanly
    without requiring hacks like a CNAME telnet.domain which
    may map to multiple machines but does not provide a mechanism
    for distributing the connections based upon capacity.

A third purpose (which I can appreciate the IESGs desire to avoid) is
also possible with SRV RR records.  A SRV RR records allows a host
adminstrator to redirect "clients that know" away from the IANA
allocated port to an alternate locally used port number.  This is
being considered for use at Columbia University to avoid the following
problem:

  We wish to have all students using a Kerberos aware Telnet client
  "kermit" connect to a port that only allows Kerberos authenticated
  connections.  Eventually we will require authenticated connections
  but we have a problem with an installed based of telnet clients
  that break when offered a Telnet Option number great than 36.  It 
  is not possible for political and technical reasons to replace 
  the broken telnet clients.  Therefore, we cannot replace the
  standard OS telnetd on port 23.  In order to support Kerberos 
  authenticated logins we must install the new telnetd on another
  port number (999).  By adding SRV RR records for _telnet._tcp.
  to our DNS we are able to redirect the Kerberos telnet clients
  to the correct ports without breaking applications that are
  ignorant of them.

This flexibility is extremely important.   I don't think it is
appropriate for the IESG to come out and say that SRV RR records MUST
only be used with protocols that specify their use.  I think an
alternate writing should be true SRV RR records should be described as
an alternative to getservbyname() which allows important
infrastructure information to be distributed by host administrators to
clients.  

Does this open the getservbyname() function to a DNS spoofing attack?
Yes.  But this attack is no more dangerous than the spoofing of a
CNAME or A record.

If the IESG is serious about insisting that SRV RR's not be used with
common services for which they are approriate with there being a
specific RFC that declares that they should be used I would recommend
that this working group solicit Internet-Drafts from the appropriate 
groups to ensure their submission to IESG simultaneous to the
re-submission of this draft.  If the group decides to follow this 
direction I will take responsibility for putting my name on a Telnet
SRV RR draft.

> 
> On other business:   Don Eastlake suggested that a doc of IANA considerations
> for DNS RR's needs to be written.   Bill Manning said that he had also been
> asked to put some effort in that direction.   They will co-author a draft.

This is extremely important.  In the TELNET arena the lack of an IANA
considerations document has resulted in IANA giving out Telnet Option
numbers to non-IETF participants at an alarming rate.  It is
especially alarming considering that most people think that Telnet
development has ceased.  Instead it has gone underground with most
Telnet implementors designing things that the IESG would choke on.

    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: Harald Alvestrand <[email-masked]>
Date: Tue, 13 Jul 1999 17:17:25 +0200

At 22:54 12.07.99 -0400, Jeffrey Altman wrote:

>only be used with protocols that specify their use.

This is, as you say, quite useful but architecturally unsound.
It is one example of selecting the service to offer based on the capabilities
of the client; you get to use this trick once - if anything occurs that
means you need to split either the new or the old groups of clients again,
you can't use SRV, because you've already used it up.

It's reasonably architecturally sound to reconfigure the old (or new)
telnet clients to point to the two hosts broken-telnetd.columbia.edu and
fixed-telnetd.columbia.edu instead; you can scale this to any number of
broken clients.
the two things can be different IP addresses on the same host, if you want 
them to be, or one can be a relay; old clients are usually not in a 
desperate hurry.

Disclaimer: I'm not terribly convinced that the total ban on SRV with stuff 
that doesn't tell you how to use it is very important in all cases - but in
this particular case, the example doesn't "smell right" to me.

                    Harald A

--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]