Re: [Add] draft-btw-add-rfc8484-clarification (was RE: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033))

Ben Schwartz <> Sat, 11 April 2020 00:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E7243A135E for <>; Fri, 10 Apr 2020 17:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VibCoPoEqKTb for <>; Fri, 10 Apr 2020 17:23:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CBCE3A135D for <>; Fri, 10 Apr 2020 17:23:23 -0700 (PDT)
Received: by with SMTP id v5so4036243wrp.12 for <>; Fri, 10 Apr 2020 17:23:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZmZv+g3oRTdE1Y2mwW54ttJ/tkCQoyWVQNM3D7V00pM=; b=C176MYlWYd8hC+U2Vt3CDi2DPlGfNhYzHEja52SFldByb5jX3w6paRBgyLyFZB1Nyv Hyg/5xp7iywnL7r37TPqeV7DsGgr4DfCzdZNAq4bq5y8kRu2OJx+h9le4oE7r+jR163o i3Lmh/LifNoe3hZM1LZiTXFVRtaBZ/LgrYrcF8rlGpo8yaDgLuFhPcVb6RFA2hCAlQzT azXBf8DZeD/wQwNlY7inDH8UUF0aNuULh8/LKc2nyNT3SvAXqB18OsUzpzzuzq4iudS9 /OLzmR6FuwhHdlWYHfzcj+0+U6P5TOcMIvJMSIpoP59Ar4M/6vzMF1vZMYZRIRbZ6sSp cYhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZmZv+g3oRTdE1Y2mwW54ttJ/tkCQoyWVQNM3D7V00pM=; b=RN5WXp+uBzlm3rt/bCzGrb6latqCpfYg7I6bhiHg5jOZqqzdgB+3XE/AQW6f7ybzDW 9A2cnYW83Qb8H2D2wXjzSlVVMKcBBEyVjlZu8jiC67RrTSPLnfjybSC0lSRUdweukHn2 66tZLqZGTOyuIKFukHMgsoO88kyzhXgxYpYx4a6X4QQRaSbeBsVrE5EQbJTuTpLTsAOU FImMRA5xPTguRXKpwnAPXaV6qa4MQkoAdtFQrcEsUnWuh9mIybPszOrxqio4MovL/kjQ /pfn4RiOumizz3FUQ7XEwgiT32GQiVVMkJG0HRnUvCvbv//Ex1DYLY27eX6N5DpBwYkk Qk5g==
X-Gm-Message-State: AGi0PuYwiHRjHxvMRxMl0lkgBqFUaGxXZoWHDtj3Qjq2Ums65jjjYTAp Sc7S8UDRSi+iJ98l0x7U5gEFlwUebx1M5n1A3nXg6A==
X-Google-Smtp-Source: APiQypLAnd/Nw7EHUlA32TMhyawEby+NAznnGR9VEfPJcY98xw7RADfuPsTzuZf2IXVO7jMY0G12RZ0TN1o9P63SZls=
X-Received: by 2002:adf:e7c6:: with SMTP id e6mr6853101wrn.159.1586564600972; Fri, 10 Apr 2020 17:23:20 -0700 (PDT)
MIME-Version: 1.0
References: <787AE7BB302AE849A7480A190F8B93303149307D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93303149307D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Ben Schwartz <>
Date: Fri, 10 Apr 2020 20:23:09 -0400
Message-ID: <>
Cc: Paul Hoffman <>, "Murray S. Kucherawy" <>, "" <>, "ADD Mailing list (" <>, Barry Leiba <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000007e8c7505a2f8db62"
Archived-At: <>
Subject: Re: [Add] draft-btw-add-rfc8484-clarification (was RE: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033))
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Apr 2020 00:23:25 -0000

On venue: ADD is not chartered for core protocol development work, and DoH
is shutting down, so I think the correct venue is probably DNSOP.  However,
you should also get input from HTTPBIS, where there is expertise on HTTP

On the draft:
* The draft introduces new MUST-level requirements, so I don't think it can
reasonably be called a clarification.  Sending DNS records in a 3XX
response body, for example, is a novel construction.

* I would remove the HTTP/2 PUSH version of the proposal, which seems more
complicated without much benefit, and I would make the 3XX response body
optional.  If the response body is absent, clients SHOULD resolve the
target hostname in the same way that they resolved the original DoH server
hostname, or fail if this is not possible.

* I think RFC 8484 is pretty clear on the main point in question: HTTP
redirection applies in the usual way, whatever that might be.  Don't trust
DoH URIs from strangers.

* In practice, redirection may have been given little attention because it
doesn't necessarily give us the behavior we want.  For a GET request (where
DoH encodes the query in the URI), a redirect only applies to that specific
query.  A server that is trying to refer users to a different server would
have to redirect each DoH GET individually -- not a recipe for good
performance.  Permanent redirects for all those queries would also bloat
the client's HTTP cache.  Alt-Svc, in contrast, would allow relocating the
whole origin, which seems closer to the intended behavior.

For POST, all queries share a URI, so permanent redirects might work OK.
However, clients are permitted to convert POST to GET (dropping the body)
when encountering a 302 redirect, so only a 308 will work.  However, as
noted in RFC 7238:
   "initial use of status code 308 will be restricted to cases
   where the server has sufficient confidence in the client's
   understanding the new code"

Perhaps support for 308 is now sufficiently universal that DoH servers can
safely rely on it, but I would recommend checking with HTTPBIS.

* Despite all these concerns, I'm glad to see interest in improving DoH,
and I agree that a way to offer an updated DoH URI template would be nice.
If we can't find an elegant solution using redirects, we can find another
way, e.g. an HTTP response header containing the new template.

On Fri, Apr 10, 2020 at 4:22 AM <> wrote:

> Hi Paul, Barry, all,
> (+add wg as I guess the draft should be discussed there)
> We prepared a document to clarify the redirection issue:
> The document specifies also how redirection can be done in DoH.
> Cheers,
> Med
> > -----Message d'origine-----
> > De : Paul Hoffman []
> > Envoyé : mardi 31 mars 2020 16:48
> > Cc :; David Lawrence; Ben Schwartz; Patrick McManus;
> > Murray S. Kucherawy; Barry Leiba; RFC Editor
> > Objet : Re: [Doh] [Ext] [Technical Errata Reported] RFC8484 (6033)
> >
> > On Mar 31, 2020, at 2:03 AM, wrote:
> > > I'm now more puzzled about the intent of the document with regards
> > to redirection:
> >
> > That's fine, and you are not alone. But the proper resolution of that
> > puzzlement is not an erratum, it is a document update.
> >
> > --Paul Hoffman
> --
> Add mailing list