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

["Paul Hoffman" <[e-mail]>]

On 26 Jun 2017, at 21:17, Mark Nottingham wrote:

Issues will be opened for all of these.

> """
>    A DNS API Client encodes the DNS query into the HTTP request using
>    either the HTTP GET or POST methods.
>
>    When using the POST method, the DNS query is included as the 
> message
>    body of the HTTP request and the Content-Type request header
>    indicates the media type of the message.  POST-ed requests are
>    smaller than their GET equivalents.
> """
>
> I think it's a mistake to bifurcate the request style so 
> fundamentally; it's HTTP tunnelling at its worst.
>
> 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.

The bifurcation was not at all due to size, but instead the likelihood 
of HTTP caching. As the draft says in the paragraph after the quoted 
ones: "Using the GET method is friendlier to many HTTP cache 
implementations." We recognized that POST-ed requests can be cached, 
they rarely are. Also, not needing to encode the GET means that a client 
that doesn't already have a base64url encoder doesn't need to add one.

I'm kinda speaking for my co-author there; I'm fine with having just one 
type and dealing with the trade-offs. We're open to what the WG might 
want.

>
> """
>   The media type is "application/dns-udpwireformat"
> """
>
> That's needlessly long; suggest "application/dns-uwf".

Is there a length-equivalent of bike-shed colors? :-)

> There's a laundry list of questions about what HTTP functionality the 
> client needs to support. I'm hoping a draft will emerge shortly that 
> will help with this.

Great.

> Why shouldn't DNS API servers be able to generate ETags based upon 
> their internal state, to reduce outbound bandwidth?

Can you say more? The current text is:

"""
    In the HTTP responses, the HTTP cache headers SHOULD be set to 
expire
    at the same time as the shortest DNS TTL in the response.  Because
    DNS provides only caching but not revalidation semantics, DNS over
    HTTP responses should not carry revalidation response headers (such
    as Last-Modified: or Etag:) or return 304 responses.
"""

--Paul Hoffman