W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: on DNS records

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Wed, 14 Nov 2012 14:58:48 -0500
Message-ID: <CAMm+LwjdpGN3P1gZFxPsuwFNyJa_LThX0jabBwB9Bsigmqa=cw@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Well there are two things here that have the name http

1) The http: URL prefix
2) The HTTP protocol

These are two separate things.

Resolving the first requires the domain and the port (and possibly a method
identifier). The second is where SRV might come in.

So a layered resolution protocol might look something like:

To resolve: http://example.com:2033/fooo

First take the XXX record using the port and protocol as modifiers:

_2033._http.example.com XXX "v=2.0 d=srv tls=r"

This says use http/2.0 as the transport protocol use SRV for discovery and
TLS is required.


The ability to specify the discovery mechanism in the XXX record permits a
site to use SRV or URI or some completely new discovery scheme. We decouple
the URL resolution mechanism from everything else. People could even use
NAPTR if they must.

A really simple deployment would just omit the discovery (d) attribute
entirely and it would fallback to A or AAAA discovery depending on how
people want to be.


In a more complex environment there might be a desire to specify protocol
version on a per host basis. In this case the initial XXX record would have
to announce the protocol variants on offer and then these would form
additional prefixes to the corresponding discovery records:

_2033._http.example.com XXX "v=2.0 v=1.1 vd=srv tls=r"
_1_1._http._tcp.example.com SRV 1 1 80 www1.example.com
_2_2._http._tcp.example.com SRV 1 1 80 www2.example.com


Alternatively people might want to treat port numbers as second layer
decorations in the same way as protocol versions. This has advantages for
use of DNS wildcarding but for reasons I don't want to explain a particular
DNS RR type should NEVER have a prefix or ALWAYS have a prefix. Mixing the
two cases causes horrible corner cases to surface. Only a record that NEVER
takes a prefix should be wildcarded unless you want horrible things to
happen.



On Wed, Nov 14, 2012 at 2:18 PM, Eliot Lear <lear@cisco.com> wrote:

> Martin,
> On 11/14/12 8:13 PM, Martin Thomson wrote:
> > On 14 November 2012 11:09, Eliot Lear <lear@cisco.com> wrote:
> >> That's a fair point.  Question: how would you handle SRV with
> >> http://www.example.com:49080?
> > That was raised in the meeting.  SRV isn't enough for that reason
> > alone.  I know too many hosts that operate on different ports.
> > Obviously, each port could be given a new name, but that eventually
> > leads to an increase in the number of wildcard certificates out there.
> >
> >
>
> Thanks.  So you would prefer some other record that simply indicates
> what version runs on what port and dump transport protocol?  What do
> others think?
>
> Eliot
>
>


-- 
Website: http://hallambaker.com/
Received on Wednesday, 14 November 2012 19:59:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 14 November 2012 19:59:18 GMT