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

From: Jeffrey Altman <[email-masked]>
Date: Wed, 27 Oct 99 13:59:05 EDT

> > Can you please describe one scenario where performing a DNS SRV lookup
> > for an entry that does not exist may lead to operational problems?
> 
> Why are my DNS servers being pounded with queries for non-existant
> names (e.g., http servers)?

I don't see how this is an operational problem.  You are going to be
hit with queries for non-existent names even with the protocols for
which DNS SRV is approved by the IESG.

    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: "Peter Ford (Exchange)" <[email-masked]>
Date: Wed, 27 Oct 1999 19:34:43 -0700

>>> and there is a strong need to avoid reinventing mx for every new
>>> protocol.

This requirement (and I agree that it IS a requirement) is proof that the
current language is not too strong, it is incorrect.  Why not move the
architecture towards use of SRV and  encourage/empower people to deploy
appropriate DNS infrastructure so we can all advance the state of services
in the 'net?

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 28 Oct 99 18:31:35 EDT

Terry:

If you have disabled random ordering of IP Addresses by the DNS, that
means that your DNS responds to each and every request with the same
value.  How does this result in load balancing for your servers?

But back to the point of my argument.  There are no new issues raised
by the use of DNS SRV that are not already present in other features
already found in BIND.  Therefore, the added restrictions on the entry
names make no sense.  A restriction of SHOULD NOT is meaningless and
will simply be ignored since it has no impact on RFC compliance.  That
said take it out.

I agree with everyone else on this list who would like to see this I-D
finally advance to P.S.  It was made very clear in Oslo that my
objections were not going to make a difference.  So lets just advance
this draft so that the other I-Ds that depend on it in other groups
may also advance.

I disagree with the restrictions and will ignore them when I feel it
is safe to do so.

- Jeff

> Jeffrey Altman wrote:
> > > Case 1:
> > >
> > >       I contact an HTTP server
> > >       It requests I authenticate
> > >
> > >       I authenticate
> > >       It sends me session specific information
> > >
> > >       I attempt to contact it again to obtain content
> > >       ** SRV redirects me to a different server
> > 
> > how is DNS SRV going to redirect you in the middle of a DH exchange
> > which is taking place over a single tcp connection that has already
> > been established?
> 
> This is not a DH base authentication, it is a simple
> authentication which requires that I return the
> negotiated key in the header of my next request.
> 
> Since I negotiated with one server, and then returned
> the header to a different server, I am screwed.
> 
> > > Case 2:
> > >
> > >       I contact an HTTPS server
> > >       I start a Diffe-Helman exchange
> > >       *** SRV redirects me to another server in the middle
> > 
> > how is DNS SRV going to redirect you in the middle of a DH exchange
> > which is taking place over a single tcp connection that has already
> > been established?
> 
> You mistakenly believe that I am running an HTTP 1.1
> connection in this example, and that I am permitting
> multiple HTTP transactions over a single TCP connection.
> I am not.  I am requiring one TCP connection per HTTP
> operation, per the HTTP 1.0 specification, and per the
> HTTP 1.1 right to refuse to allow persistant connections.
> I am doing this in order to force the client to go through
> my SRV records, so that I may load-balance it against its
> will (but in accord with my own).
> 
> You could argue that these cases were degenerate; they
> are, however, possible, unless there is a specification
> prohibiting them, and thus must be considered for the
> protocol to be correct.
> 
> > > Again, I can get around this by mandating shared state
> > > and secure connections for sharing of state, but I
> > > haven't done that in an RFC anywhere, so the inter-server
> > > communication, not having been specified, is subject to
> > > back-end compromise.
> > 
> > What you are saying is that the above scenarios also break
> > if a DNS has multiple addresses for the same name and
> > issues them in a round robin fashion.
> 
> Yes.
> 
> > Since round robin DNS does not break the above
> > scenarios then how could it break DNS SRV?
> 
> It does break them: I am not allowing persistant
> connections, so a reconnect is necessary each time;
> consider if I set my TTL on my DNS records to the
> minimum allowed value, so that they could not be
> successfully cached, and subsequent lookups after
> a cache expiration resulted in different addresses.
> 
> 
> > If I am missing something really obvious, please let me
> > know.  But I don't think I am.
> 
> It doesn't break your telnet example, because there is
> a persistant connection involved in your telnet example.
> 
> The point was to provide examples of shared state between
> partners in a client-server relationship, in which the
> server answering the request could change between requests;
> HTTP fits the bill for this.  I could have easily used NFS
> locking against servers with a shared back-end file store
> on a Network Appliance box, but that would have been
> rather more obscure than an HTTP example.
> 
> Without a distrubuted cache coherency protocol to ensure
> that the shared state was shared between all the servers
> that could respond in a work-to-do way to a single clients
> request because the state is not identical on all servers,
> breakage results.
> 
> I think the point of "SHOULD NOT" (again: "SHOULD"; feel
> free to violate it locally) is to discourage application
> of SRV records without engaging in protocol considerations
> about shared state.
> 
> Since it doesn't stop you from doing what you are doing
> (though the corrolary is that some clients MAY assume that
> you aren't doing it, and behave badly), I don't really see
> the problem you have with the wording, except that it
> allows clients to behave however they want for a given
> protocol, unless there is a protocol specification that
> prohibits them from doing so.  I am reminded of RMS's
> #pragma implementation in gcc, which started up nethack...
> 
> 
> -- 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.
>

---

From: "Levon Esibov (Exchange)" <[email-masked]>
Date: Fri, 29 Oct 1999 12:43:39 -0700

> > - 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.
> 
> levon has the editing token.
> 

I definitely agree