Re: on DNS records

Adrian,

My question is how important is it to make use of different transport
protocols?  I'm asking because there are at least three approaches that
we can take to address DNS:

1.  SRV.  SRV is just fine at providing indirection for host and port,
but not for protocol, and not in such a pretty way when a port number is
specified.  The cost is typically one query per host, which can
SOMETIMES be included in additional information, when the zone is the
same, and when the client considers additional information.
2.  NAPTR combined with SRV.  This provides an additional level of
indirection to allow the choice of protocol.  SIP uses this.  The cost
is two fold: an additional query plus some additional complexity in
terms of processing NAPTR.  It also would prove challenging to handle
the case where different HTTP servers are running on the same host.
3.  An as-of-yet undefined record that describes what services are
running over what protocols on a host.  Think of it as the old WKS
record on steroids.  I've actually spec'd out the record and written
some code for bind to test this idea, but it has its own set of costs:
the first – and biggest – is that it scales linearly with the number of
services that are to be advertised for a given host.  Put another way:
you could just see the advice in an applicability statement "don't use
me unless you really have to."

One other note about SRV:

Use of SRV of any form with regard to TLS would require a substantial
change in how we clients validate hostnames.  I tell you from personal
experience that having a new SAN "Other" type is *not* an easy thing to
ask of CAs.

Comments please?

Eliot



On 11/14/12 9:05 AM, Adrien W. de Croy wrote:
>  
> IMO it's a real shame that the designers of the SRV record decided to
> code the transport protocol into the record name, rather than the
> record data.
>  
> It means the client must pre-suppose what the transport protocol must
> be before doing the lookup, whereas if the transport were in the
> record, it would become server-driven, and extensible, e.g. add
> tls-over-tcp to indicate that the server is available over tls on tcp.
>  
> Then you'd just look up something like _service.name and get back
> everything you needed to make a connection, e.g. the server, transport
> and sub-channel (e.g. port number or whatever describes the
> sub-channel for the transport).
>  
> Adrien
>
> ------ Original Message ------
> From: "Eliot Lear" <lear@cisco.com>
> To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
> Sent: 14/11/2012 4:07:18 a.m.
> Subject: on DNS records
>> As I promised last week, I've substantially developed a draft (and
>> some code) to look more closely at whether a DNS record can be
>> helpful.  Before I get it out there, I wanted to check goals.  The
>> situation is this: there is a 2.0-enabled client and it must
>> determine whether or not the other end can speak 2.0.  Gabriel and
>> Willy have already shown us that it can be done INSIDE the protocol
>> at the expense of one roundtrip, but at the risk of a proxy doing the
>> wrong thing (a classic case being that it allows an Upgrade: header
>> but then barfs all over the upgrade).  So let's state our goals:
>>
>> 1.  Keep latency down.
>>
>>   * First, is this a reasonable goal?
>>   * Can it reasonably be done better than what Willy & Gabriel have
>>     laid out?
>>
>> 2.  Transport Protocol Discovery
>>
>>   * Some have suggested that it would be useful to do HTTP over UDP
>>     or SCTP.  Is that something that is a reasonable goal?
>>
>> 3.  Handle the case where multiple instances of the same application
>> protocol reside on the same host, but on different ports.
>>
>>   * Is this a reasonable goal?
>>
>> 4.  No new URI schema
>>
>>   * Address the 'side of the bus' problem.
>>   * Is this a reasonable goal?
>>
>>
>> Does this about cover it?  I claim we can solve all four, but not
>> easily with SRV.
>>
>> Eliot