Re: [Doh] Support requirements for Get and Post

Ben Schwartz <bemasc@google.com> Sun, 18 March 2018 10:09 UTC

Return-Path: <bemasc@google.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D1012741D for <doh@ietfa.amsl.com>; Sun, 18 Mar 2018 03:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgojnK-rF8TE for <doh@ietfa.amsl.com>; Sun, 18 Mar 2018 03:09:46 -0700 (PDT)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C596A1200A0 for <doh@ietf.org>; Sun, 18 Mar 2018 03:09:45 -0700 (PDT)
Received: by mail-it0-x235.google.com with SMTP id y20-v6so6838001itc.5 for <doh@ietf.org>; Sun, 18 Mar 2018 03:09:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y5h5jiCAJ+bj7EmKviTBaH60Ld3rJTr1HmTSXFBam+k=; b=C6IgO2bnQgj8gfwulhaH3I8rMstHZhA4FWML8sMC+/2J2dhuF7iwqYwlcrnubP30ie kfrnezA+P8k2CSsAygshqoJytOJASCRccLsefjmdUsv5/u/VvE2XdnwY/XG2VL7KvxBS 3iNiC/t/K/n2gWIx3IUvEihvVK9Zj3SBmYiRAo2y0u1f5UvyFcyf8GrKXMpvcVIOYj+3 RT6y//ysBqyYpBltnAWHJvB3LnfB4IbWyh4A7vl39m+kAb0TFSQrYqhKxqFql0MM4imk uRs45zcRt9OM31b6vTFL8sGCMNJusmvKiKtue1U5HgtiBCJQUPhc5U8+mH0e3bmAdjI1 /0+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y5h5jiCAJ+bj7EmKviTBaH60Ld3rJTr1HmTSXFBam+k=; b=a13uSX1KxGbWab+ueWKbyjkAylLErTiAfTCtjkQWcQJPzlF6XlqHDYZLPoMduTK9U9 ChqzlSB+a0PGu6U4u4GjIPpDhnEv4PUIkAXnUY7fvT+q1RIkPoW0jCniKGjoSn1Z0krC rN+VvgYGbtZIUfJvU0HaSAqOMdNh+ChY4iViz77aLZ1i4EAcNLHJHLs0CBpX/7ctDFas VxPe1AESl/cPKrWDH1GoZqvMfLlHOa0TBciFHc1hw3LO0BVstL1cSN/z930OQdqUwN7v RMrlJqB/dl3cI2a4RtUQAGpYl9mclKucySjSLRI/jHJDsrDo6wni6cuka2q1vG5zrw6q +jow==
X-Gm-Message-State: AElRT7FoBWIy31nnk1h2jDHcpYIkMfUWQnaL4YgBv4kkpA9DwGKOY0ou 22hDzVDHw9Cwk/iTQIbZUSf8ge5tFMM3BhSkpBSvPQ==
X-Google-Smtp-Source: AG47ELuPF/+MIrPx/Qqtr8XGDhjrWRS7AvVodgVnlr/qWK2fH+qkTLcX8NjZzN8C+qRvrisHBMiPt0Ftr5hkE9ChwXs=
X-Received: by 2002:a24:d803:: with SMTP id b3-v6mr8703158itg.7.1521367784609; Sun, 18 Mar 2018 03:09:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.168.210 with HTTP; Sun, 18 Mar 2018 03:09:44 -0700 (PDT)
In-Reply-To: <CAOdDvNpFqavszS_OzOdOOd+e0E+ufDcqkyQzCrnAtWPZnKEZFQ@mail.gmail.com>
References: <CAN6NTqzkUeF79y=heQ7PK7T3mQVDDk5WRtqB-npi6PuQ2s5bNQ@mail.gmail.com> <alpine.DEB.2.20.1803171337530.1331@tvnag.unkk.fr> <CAN6NTqykeU1gT0TaDKahBPeF-a8gwYG7gsAEK_aSE0fNP-AsfQ@mail.gmail.com> <CAOdDvNq7e5YGtUap6tHu34zX5q1PvmQjAh+fc0m=xcRDUrmKhA@mail.gmail.com> <CAOdDvNqGvPRH3SzP_tkHVZHr-geacqDBa+QfoqXGVxFWW2qr2A@mail.gmail.com> <CAHbrMsAkU+KKwCFpyLD40aPZLEVtRj=aEZsaC+=Y2yYwKCiEyA@mail.gmail.com> <CAOdDvNpFqavszS_OzOdOOd+e0E+ufDcqkyQzCrnAtWPZnKEZFQ@mail.gmail.com>
From: Ben Schwartz <bemasc@google.com>
Date: Sun, 18 Mar 2018 06:09:44 -0400
Message-ID: <CAHbrMsBYcO_1v-dPKP8vvubqfjLyRJhZPsmHHE_ReVRiczbuYA@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= <olafur@cloudflare.com>, doh@ietf.org, Daniel Stenberg <daniel@haxx.se>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000006aedb40567ad0a2a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/OED9F-rzmGnCD_KCAFkZb2IYUGk>
Subject: Re: [Doh] Support requirements for Get and Post
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Mar 2018 10:09:48 -0000

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 <pmcmanus@mozilla.com>;
wrote:

> 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.
>
>
>
> On Sat, Mar 17, 2018 at 5:22 PM, Ben Schwartz <bemasc@google.com>; wrote:
>
>> On Sat, Mar 17, 2018 at 9:47 AM, Patrick McManus <pmcmanus@mozilla.com>;
>> wrote:
>>
>>> 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.
>>>
>>
>> SHOULD clients handle a "method not allowed" by retrying with the other
>> method?
>>
>>
>>>
>>> -P
>>>
>>>
>>> On Sat, Mar 17, 2018 at 1:43 PM, Patrick McManus <pmcmanus@mozilla.com>;
>>> wrote:
>>>
>>>> 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 <
>>>> olafur@cloudflare.com>; wrote:
>>>>
>>>>> What is the usage case to Server push of DNS answers ?
>>>>>
>>>>> Olafur
>>>>>
>>>>>
>>>>> On Sat, Mar 17, 2018 at 12:40 PM, Daniel Stenberg <daniel@haxx.se>;
>>>>> wrote:
>>>>>
>>>>>> On Sat, 17 Mar 2018, Ólafur Guðmundsson 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).
>>>>>>>
>>>>>>
>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Doh mailing list
>>>>> Doh@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/doh
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Doh mailing list
>>> Doh@ietf.org
>>> https://www.ietf.org/mailman/listinfo/doh
>>>
>>>
>>
>