Re: on DNS records

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 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).


------ Original Message ------
From: "Eliot Lear" <>
To: " Group" <>
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 
>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.

Received on Wednesday, 14 November 2012 08:06:15 UTC