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

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 26 Jun 2017 19:38:21 -0700

[[ Any comments on the -00 that we should incorporate into a -01 before 
the cutoff in a week? ]]

Greetings. Based on the advice from the chairs, we have given a new 
filename to our dns-over-https draft. This will hopefully get the draft 
picked up in the DISPATCH WG tracker page.

--Paul and Patrick

A new version of I-D, draft-hoffman-dispatch-dns-over-https-00.txt
has been successfully submitted by Paul Hoffman and posted to the
IETF repository.

Name:		draft-hoffman-dispatch-dns-over-https
Revision:	00
Title:		DNS Queries over HTTPS
Document date:	2017-06-17
Group:		Individual Submission
Pages:		12
URL:            
https://www.ietf.org/id/draft-hoffman-dispatch-dns-over-https-00.txt
Status:         
https://datatracker.ietf.org/doc/draft-hoffman-dispatch-dns-over-https/
Htmlized:       
https://tools.ietf.org/html/draft-hoffman-dispatch-dns-over-https-00
Htmlized:       
https://datatracker.ietf.org/doc/html/draft-hoffman-dispatch-dns-over-https-00

Abstract:
   DNS queries sometimes experience problems with end to end
   connectivity at times and places where HTTPS flows freely.

   HTTPS provides the most practical mechanism for reliable end to end
   communication.  Its use of TLS provides integrity and confidentiality
   guarantees and its use of HTTP allows it to interoperate with
   proxies, firewalls, and authentication systems where required for
   transit.

   This document describes how to run DNS service over HTTP using
   https:// URIs.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 27 Jun 2017 14:17:30 +1000

Hi Paul,

Thanks for the heads-up.

"""
   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 media type is "application/dns-udpwireformat"
"""

That's needlessly long; suggest "application/dns-uwf".

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.

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

Cheers,

> On 27 Jun 2017, at 12:38 pm, Paul Hoffman <[email-masked]> wrote:
> 
> [[ Any comments on the -00 that we should incorporate into a -01 before the cutoff in a week? ]]
> 
> Greetings. Based on the advice from the chairs, we have given a new filename to our dns-over-https draft. This will hopefully get the draft picked up in the DISPATCH WG tracker page.
> 
> --Paul and Patrick
> 
> 
> URL:            https://www.ietf.org/id/draft-hoffman-dispatch-dns-over-https-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-hoffman-dispatch-dns-over-https/
> Htmlized:       https://tools.ietf.org/html/draft-hoffman-dispatch-dns-over-https-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hoffman-dispatch-dns-over-https-00
> 
> 
> Abstract:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

--
Mark Nottingham   https://www.mnot.net/

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 27 Jun 2017 07:49:02 -0700

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

Issues will be opened for all of these.

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

> 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

---

From: Patrick McManus <[email-masked]>
Date: Tue, 27 Jun 2017 08:50:27 -0700

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

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Jun 2017 12:39:08 -0700

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

See also RFC 7541, which makes this specific sort of
micro-optimization less necessary.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jun 2017 08:01:54 +1000

> micro-optimization less necessary.

They're putting it in the URL, which changes between almost all requests on a connection.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jun 2017 11:05:45 +1000

> On 28 Jun 2017, at 1:50 am, Patrick McManus <[email-masked]> wrote:

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

If it's just Content-Type, I think putting it in the URL is fine, and would prefer a GET-only solution.

If it's going to be more complex than that, I'd recommend that the well-known resource actually be a "directory" / "map" / "home page" document that explains how to interact with the DNS API server, rather than baking everything into the URI. It'll give you far more flexibility for future changes, and AIUI in the use cases for this, it's not onerous to do a single up-front discovery RT.

BTW - If I were to nit-pick here, I'd say that you don't need a well-known URI for this; there's no reason that a DNS API server couldn't be configured with a full URI, instead of a hostname / port pair. 

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

Fair enough. Just didn't want to discount validation out of the gate.