Re: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https

[Patrick McManus <[e-mail]>]

On Mon, Jun 26, 2017 at 9:17 PM, Mark Nottingham <[e-mail]> wrote:

>
>
> I think it's a mistake to bifurcate the request style so fundamentally;
> it's HTTP tunnelling at its worst.
>

I'm going to push back on the tunnel terminology at least a little bit
(while acknowledging one of the use cases has lots of properties of
tunnels) the DoH approach tries to emphasize flexible typing and caching in
order to leverage the HTTP ecosystem. The typing is particularly useful, I
think. Refining that is certainly a goal of any future iterations of the
draft.


> The GET-style request in your example (which I think is pretty
> representative) uses 44 octets to encode the body; the POST serialisation
> is 33 octets. However, with HPACK's huffman encoding (remember, you're
> requiring HTTP/2), that goes down to 34 bytes.
>
> Are we really that sensitive to on-the-wire size? To me, the cache
> efficiency gains as well as simplicity more than make up for a 3%
> difference. The statement that "POST-ed requests are smaller" isn't going
> to be true, in pathological cases.
>
>
So size is one concern that motivates the POST definition but there are
others that should probably be articulated. Most significantly request
header mechanisms that apply to the request message body don't apply well
to GET other than the content-type encoded into the GET URI (which is a
rather unfortunate wart without adding more such warts on). From a size
perspective obviously compression might be a win for POST but not for GET
but I'm also trying to be a pragmatist when thinking about whether 415
applies naturally to the GET mode.

If we were to have only one, and that is a reasonable thing to at least
discuss about a standard (the current situation is definitely a tradeoff,
though one I support), I'd actually be inclined to go POST only to more
naturally delineate the messages in each direction. That of course leads to
the cache discussion - and we know as spec-heads that there's nothing wrong
with caching POST in this model - but we also know that it won't happen.
Thus this flavor of  pragmatism while acknowledging there are 30 other
flavors available on the menu.


> Why shouldn't DNS API servers be able to generate ETags based upon their
> internal state, to reduce outbound bandwidth?
>
>
we should give it a full airing wherever this gets dispatched to, but 2
thoughts:
1 - iirc this boils down to an interaction between the DNS TTL embedded in
the response and the 304.. you really do conceptually need a new DNS entry,
but if its byte-for-byte the same I agree the server could 304 that with
appropriate cache controls. we should figure out the right language to
thread that needle.

2 - these responses are good candidates for immutable