Re: on DNS records

On Tue, Nov 13, 2012 at 7:29 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> 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.
>
>
Well... I've said it before but we're very much going to need a pure http/2
option here that can operate without dns or http/1... basically, just open
a port and start sending http/2 and assume it'll work... Beyond that, the
DNS approach seems to be the most reasonable, non-hacky option on the table
so far.

- James


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