Re: on DNS records

I think the main argument for using a DNS record (which I am less fussed
about) is the complexity issue.

Yes we can keep finding per-protocol hacks to describe upgrade mechanisms.
But they mean that every HTTP/2.0 will always have to rely on having a
HTTP/1.1 implementation around to bootstrap from. So HTTP/2.0 cannot do
anything to reduce the complexity of the protocol implementation, it has to
be additions, nothing taken away.

Putting the information in the DNS means that we can move towards a
situation where all Internet application protocol servers follow the same
basic pattern on startup or a configuration change:

1) Read the configuration data
2) Communicate the data to a 'service announcement' service
3) Service announcement service configures local network to provide
support, including configuring the DNS, firewalls etc.
4) Periodically tell the service announcement service that the server is
still alive

Put SSL certificates in that configuration mechanism and DANE or something
DANE-like for security policy advertisement becomes practical.


Now the authoritative mechanism by which the service advertises the service
characteristics should be DNS, but that does not mean that the mechanism by
which the client obtains that information has to be the DNS client-resolver
protocol. It has to be a trusted protocol certainly, but it seems rather
silly that in 2012 we still have a situation where my web browser relies on
the DNS server provided by Panera rather than one that I choose and trust.




On Tue, Nov 13, 2012 at 10:07 AM, Eliot Lear <lear@cisco.com> wrote:

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



-- 
Website: http://hallambaker.com/