Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

["Roy T. Fielding" <[e-mail]>]

> On May 3, 2017, at 11:33 AM, Joe Touch <[e-mail]> wrote:
> 
> Hi, all,
> 
> FWIW...speaking from the experience I have leading the IANA ports expert
> review team and developing BCP165 (RFCs 6335 and RFC7605):
> 
> On 5/3/2017 11:15 AM, Daniel Kahn Gillmor wrote:
>> And Joe Touch pointed out that the draft should explicitly update the
>> HTTP as well as DNS specifications, so i've marked the latest revision
>> of the draft that way.  If you think that's OK (or if you think it's
>> unnecessary), please let me know!
>> 
>> Assumptions about HTTP
>> ----------------------
> I would characterize this as redefining ports 80 and 443 to include DNS
> as part of the HTTP specification.
> 
> That has some very important ramifications, indicated here as
> "assumptions", that limit the future development of HTTP (notably
> reserving certain prefixes and patterns to differentiate DNS requests
> from HTTP). That could constrain all current and future uses of ports 80
> and 443, and could potentially affect any other service that uses HTTP
> as a framing layer.
> 
> Joe

I agree with Joe.  My answer would be "no".  It certainly isn't an Update
for the HTTP specs.

I see no reason to suggest that spraying DNS on an HTTP connection would
be interoperable.  HTTP/1.x has a tradition (good or bad) of allowing
robust parsing of bad messages, which means no analysis of DNS uniqueness
can guard against the potential variance of a thousand or so independent
implementations of servers and intermediaries (there are at least four
figures of independent server development in the craft-your-own-microserver
category).

In contrast, it is trivial to transform a DNS query into a GET request
which can be handled by any current or future version of HTTP.
All you need is the absolute URI, which is already defined, and a
media type for the response payload.  That would just be using HTTP,
so no need to call that an update either.

....Roy