Subject: [Doh] Support requirements for Get and Post

From: Ólafur Guðmundsson <[email-masked]>
Date: Sat, 17 Mar 2018 12:27:09 +0000

Based on experience at the IETF101 Hackathon this issue came up.

dns-over-https-03 draft is silent on the topic if Get and Post are both
required or implementations can only support one of them.

I would like to see a section like this added to the document:

Implementation requirements

Post MUST be supported Get MAY be supported, when GET is not supported the
error code retuned should be 405 (HTTP RFC 7321, section 6.5.5).

Reasoning: In many web servers POST is not logged but GET is. Thus from a
privacy point of view clients that do not want to have their queries logged
by servers stand a better chance by using POST.

Olafur

---

From: Daniel Stenberg <[email-masked]>
Date: Sat, 17 Mar 2018 13:40:37 +0100 (CET)

> error code retuned should be 405 (HTTP RFC 7321, section 6.5.5).

You didn't say this, and it is a side-note about methods, but I still wanted 
to just mention that when imlementing support for HTTP/2 server push for DOH, 
you want the server to send that as a GET so that the query string tells the 
client about the request it also sends the response to...

-- 

  / daniel.haxx.se

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Sat, 17 Mar 2018 13:16:42 +0000

What is the usage case to Server push of DNS answers ?

Olafur

On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg <[email-masked]> wrote:

> You didn't say this, and it is a side-note about methods, but I still
> wanted to just mention that when imlementing support for HTTP/2 server push
> for DOH, you want the server to send that as a GET so that the query string
> tells the client about the request it also sends the response to...
>
> --
>
>  / daniel.haxx.se

---

From: Miek Gieben <[email-masked]>
Date: Sat, 17 Mar 2018 13:21:22 +0000

[ Quoting <[email-masked]> in "[Doh] Support requirements for Get ..." ]
>by servers stand a better chance by using POST.

I agree with this.

On a side note: as an DNS library implementer I would like to expose as little 
knobs as possible and just default to one way of using DoH.

/Miek

--
Miek Gieben

---

From: Dave Lawrence <[email-masked]>
Date: Sat, 17 Mar 2018 09:25:39 -0400

> What is the usage case to Server push of DNS answers ? 

Minimizing the amount of time spent on DNS lookups for other assets
and links in a page.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 17 Mar 2018 13:27:53 +0000

> On 17 Mar 2018, at 12:27 pm, Ólafur Guðmundsson <[email-masked]> wrote:
> 
> Thus from a privacy point of view clients that do not want to have their queries logged by servers stand a better chance by using POST. 

That seems like a really weak guarantee of privacy.

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

---

From: Dave Lawrence <[email-masked]>
Date: Sat, 17 Mar 2018 09:31:10 -0400

[email-masked] wrote:
>> Thus from a privacy point of view clients that do not want to have
>> their queries logged by servers stand a better chance by using POST.

> That seems like a really weak guarantee of privacy.

Delightfully understated, in a "sure you're using that word
'guarantee' sarcastically" kind of way.

---

From: Ian Swett <[email-masked]>
Date: Sat, 17 Mar 2018 13:41:31 +0000

FWIW, unless there is a specific exception for Doh POSTs I'm not aware of,
using POST prevents clients from sending 0RTT Doh requests.

On Sat, Mar 17, 2018 at 9:31 AM Dave Lawrence <[email-masked]> wrote:

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Patrick McManus <[email-masked]>
Date: Sat, 17 Mar 2018 13:43:17 +0000

push #1: anticipate other needs of the client (as mentioned)

push #2: its a different way to express additional records if that's a
desirable thing (e.g. ttl granularity)

On Sat, Mar 17, 2018 at 1:16 PM, Ólafur Guðmundsson <[email-masked]>
wrote:

>> Post MUST be supported Get MAY be supported, when GET is not supported
>>> the error code retuned should be 405 (HTTP RFC 7321, section 6.5.5).
>>>
>>

---

From: Patrick McManus <[email-masked]>
Date: Sat, 17 Mar 2018 13:47:17 +0000

Overall I think the draft does an OK job of describing the merits of
get/post (post is more efficient but is not http cache friendly, get is
needed for cases like push and is more http cache friendly). If folks think
its imperative to have that summary in one place in the document I'm happy
to make that change.

I would think most clients relying on http caches for performance would use
get, but if they have a DNS cache they are populating they would use post.
A server can choose not to implement one of these (and "method not allowed"
is the right response for that imo), but its limiting what clients can
achieve with it.

-P

On Sat, Mar 17, 2018 at 1:43 PM, Patrick McManus <[email-masked]>
wrote:

> On Sat, Mar 17, 2018 at 1:16 PM, Ólafur Guðmundsson <[email-masked]
> > wrote:
>

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 17 Mar 2018 13:22:28 -0400

On Sat, Mar 17, 2018 at 9:47 AM, Patrick McManus <[email-masked]>
wrote:

> I would think most clients relying on http caches for performance would
> use get, but if they have a DNS cache they are populating they would use
> post. A server can choose not to implement one of these (and "method not
> allowed" is the right response for that imo), but its limiting what clients
> can achieve with it.
>

SHOULD clients handle a "method not allowed" by retrying with the other
method?

>> On Sat, Mar 17, 2018 at 1:16 PM, Ólafur Guðmundsson <
>> [email-masked]> wrote:
>>

---

From: Patrick McManus <[email-masked]>
Date: Sat, 17 Mar 2018 18:30:18 +0000

imo normative SHOULD is a tad too strong.

One thing to note is that the 405 ought to include an allow response header
indicating what methods it can process.. so your fallback ought to be in
that set, at a minimum.

But its also possible that the other method might not meet your
requirements.. e.g. a GET is 405'd and you require an HTTP cache to meet
performance requirements - you might not use doh, or use a different
server, or whatever instead of SHOULD retry.

may is really ok imo.

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 18 Mar 2018 06:09:44 -0400

So does that mean that a DOH server and client that both comply with all
SHOULD-strength requirements still may not be able to exchange any DNS
data?  That seems like a weaker guarantee of compatibility than is typical
at the IETF.

If following all the SHOULD-level recommendations is not sufficient to
ensure compatibility, then as an implementor I would appreciate some clear
additional guidance on what I have to do to make my client compatible with
any compliant DOH server (and vice versa as a server implementor).

On Sat, Mar 17, 2018 at 2:30 PM, Patrick McManus <[email-masked]>
wrote:

> One thing to note is that the 405 ought to include an allow response
> header indicating what methods it can process.. so your fallback ought to
> be in that set, at a minimum.
>
>>>>>> Post MUST be supported Get MAY be supported, when GET is not
>>>>>>> supported the error code retuned should be 405 (HTTP RFC 7321, section
>>>>>>> 6.5.5).
>>>>>>>
>>>>>>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 18 Mar 2018 13:11:39 +0000

On Sat, Mar 17, 2018 at 12:27:09PM +0000,
 Ólafur Guðmundsson <[email-masked]> wrote 

> Based on experience at the IETF101 Hackathon this issue came up.

A related issue is HEAD support. Today, one implementation rejects
both GET and HEAD (405), one accepts GET but HEAD triggers a 400
(probably a bug, reported).

My personal opinion is "if you support GET, you MUST support
HEAD". Any HTTP advice? (Technically, it's nothing, the vast majority
of DoH clients and servers already handle HEAD.)

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 18 Mar 2018 14:30:34 +0100 (CET)

On Sun, 18 Mar 2018, Stephane Bortzmeyer wrote:

> My personal opinion is "if you support GET, you MUST support HEAD". Any HTTP 
> advice? (Technically, it's nothing, the vast majority of DoH clients and 
> servers already handle HEAD.)

That is not strictly stated in RFC 7231 and the web is already populated with 
lots of servers that don't respond to HEAD while responding fine to GET.

-- 

  / daniel.haxx.se

---

From: Massimiliano Fantuzzi <[email-masked]>
Date: Sun, 18 Mar 2018 15:19:50 +0100

Either answer with 405 or support it as "cache-primer" helper ?
As Daniel says, many servers drop this method... but in DOH context it may
come helpful, IMHO.

HEAD is there to asses the existence of a resource, why shall we not bring
it along ? (i.e. may be supported but not a must ?)

Best regards,
max

On Sun, Mar 18, 2018 at 2:30 PM, Daniel Stenberg <[email-masked]> wrote:

> My personal opinion is "if you support GET, you MUST support HEAD". Any
>> HTTP advice? (Technically, it's nothing, the vast majority of DoH clients
>> and servers already handle HEAD.)
>>
>
> That is not strictly stated in RFC 7231 and the web is already populated
> with lots of servers that don't respond to HEAD while responding fine to
> GET.
>
> --
>
>  / daniel.haxx.se
>

-- 

*Massimiliano Fantuzzi*
*IT professional, expert in DB Linux and networks.*

*+41 76 754 1037 <%2B41%2076%20754%201037>*

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 18 Mar 2018 16:35:22 +0000

On Sun, Mar 18, 2018 at 02:30:34PM +0100,
 Daniel Stenberg <[email-masked]> wrote 
 a message of 17 lines which said:

> the web is already populated with lots of servers that don't respond
> to HEAD while responding fine to GET.

"The Web is large, and full of errors" (the red priestess, in Game of
Thrones).

Seriously, I know that no RFC will make errors and bugs disappear but
we can at least express a preference?

---

From: Daniel Stenberg <[email-masked]>
Date: Sun, 18 Mar 2018 17:43:59 +0100 (CET)

On Sun, 18 Mar 2018, Stephane Bortzmeyer wrote:

> Seriously, I know that no RFC will make errors and bugs disappear but we can 
> at least express a preference?

I argued against a MUST where the HTTP spect itself doesn't have a MUST. I 
think that is stronger than "a preference".

I'm fine with a preference!

-- 

  / daniel.haxx.se

---

From: Dave Lawrence <[email-masked]>
Date: Mon, 19 Mar 2018 13:57:04 -0400

Ben Schwartz writes:
> SHOULD-strength requirements still may not be able to exchange any DNS data? 
> That seems like a weaker guarantee of compatibility than is typical at the
> IETF.

Has an answer to this question come through yet?

> If following all the SHOULD-level recommendations is not sufficient
> to ensure compatibility, then as an implementor I would appreciate
> some clear additional guidance on what I have to do to make my
> client compatible with any compliant DOH server (and vice versa as a
> server implementor).

Very much agree.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 19 Mar 2018 18:01:25 +0000

this is an open issue I was planning to address with f2f time of the wg as
part of the slot related to this document (of course in addition to any
mailing list comments).

On Mon, Mar 19, 2018 at 5:57 PM, Dave Lawrence <[email-masked]> wrote:

> data?

---

From: Petr Špaček <[email-masked]>
Date: Mon, 19 Mar 2018 22:59:31 +0100

On 19.3.2018 19:01, Patrick McManus wrote:
> this is an open issue I was planning to address with f2f time of the wg
> as part of the slot related to this document (of course in addition to
> any mailing list comments).
> 
> On Mon, Mar 19, 2018 at 5:57 PM, Dave Lawrence <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Ben Schwartz writes:
A subversive question:
Do we *actually* need GET and POST? Could we get away with just one of
these?

Please apologize my lack of HTTP knowledge, but it seems to me weird to
start with both (as opposed to gradual addition of new ones as necessary).

-- 
Petr Špaček  @  CZ.NIC

---

From: "Hewitt, Rory" <[email-masked]>
Date: Mon, 19 Mar 2018 22:05:37 +0000

This thought has occurred to me also...

At an ABSOLUTE MINIMUM, we'd need GET for typical DNS requests and POST for e.g. AXFR. But if we didn't worry about AXFR (yet), then maybe only GET.

Of course, complex queries can get pretty out of hand size-wise, especially if we're passing a Base64-encoded udpwireformat query string...

Rory

-----Original Message-----
From: Petr Špaček [mailto:[email-masked]] 
Sent: Monday, March 19, 2018 3:00 PM
To: [email-masked]
Subject: Re: [Doh] Support requirements for Get and Post

On 19.3.2018 19:01, Patrick McManus wrote:
> this is an open issue I was planning to address with f2f time of the 
> wg as part of the slot related to this document (of course in addition 
> to any mailing list comments).
> 
A subversive question:
Do we *actually* need GET and POST? Could we get away with just one of these?

Please apologize my lack of HTTP knowledge, but it seems to me weird to start with both (as opposed to gradual addition of new ones as necessary).

--
Petr Špaček  @  CZ.NIC

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 22 Mar 2018 08:40:56 +0000

On Mon, Mar 19, 2018 at 10:59:31PM +0100,
 Petr Špaček <[email-masked]> wrote 

> Do we *actually* need GET and POST? Could we get away with just one of

No, we don't NEED. But today, as Ben Schwartz and Dave Lawrence
noticed, we have a much worse situation: clients and servers can choose
and, as a result, they may be unable to interoperate. So, mandating
GET *or* POST *or* both is necessary, to solve this interoperability
problem.

Now, regarding your question: experience from the hackathon seems to
indicate that supporting both GET and POST is very little work.