Re: [Doh] [Add] draft-btw-add-rfc8484-clarification (was RE: [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 4A4103A135D for <>; Fri, 10 Apr 2020 17:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Status: No, score=-17.598 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, RCVD_IN_DNSWL_BLOCKED=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 Q99oNCjiaKGA for <>; Fri, 10 Apr 2020 17:23:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 03DFC3A135B for <>; Fri, 10 Apr 2020 17:23:22 -0700 (PDT)
Received: by with SMTP id i10so4037751wrv.10 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=RW0fD+xb70+LfJMDcCSmiILuG4zSZgvu3XUwvr2qv0k=; b=PeQ5wxeiPhbcSgGFAXpZRjSCEi1zcapK5keuEz+8AJfqp6aiCvt49euEwlMM6+0YGd AhIaUIp7NFtcshOGBZekCXP/Vaaiky5mAIEEyO12sAra23iEGffFyolmzJMy+hn4D2Lu INUXHH78o0/BlhySzcRdkxzDO3ldc3IhKrOpO6JkNwngiRilpIimHstg1faRJNpskytz TpPwXxYUlA+Cp6PwisOUJmOeAMejyOAFASIol/Be6e3ZA6xhF6/f1ZO4cx6/wAzozx6+ 6+q0FGtP13CwBxnGlgQRV9WmxS1NZIwQGZ8eng5i4k489Lz5dKFSo7gMKBqBvSG2V52j //ag==
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=RW0fD+xb70+LfJMDcCSmiILuG4zSZgvu3XUwvr2qv0k=; b=H9JAnanyKUYyfJ7eC0uIOIO5S3MjeojbeE8lVK65ecJDwx+oNNQg/Ric1PsiyaJr3Q nd0PEdCQrfeoYUEwXFLp9NcI/RM/bdMKXg62rAxJjnLA8EuUUW4qGQes3IfIVRYKGCoF /cjn8ZEb1tkEAprI9TAcVMyEMhj+MbdSct58YF2+dHcGBuR+8sXrU0+mzygD6e91oWUa fmhCyvlauNGXhAh2YlL5j9857CBQNmbKKLhbkIYwtB6IyK++F1MxxNa9DEtqFU49vzhe dluix/9ojU0uTuAONLpMGzL5tQBSaTbVO4DNzjbTnr7O6j+EpSipW2leEsDrW509vZkt 2nZQ==
X-Gm-Message-State: AGi0Pub8MT3Z3B08jWnaFX8VdyOaQxgkZJMDzN+ZF/WWuGU5Yc79aGKK MphoBJ1iba2VGRWpe0NlrNyCLaIQq3/OITOhM8EEtw==
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="0000000000007e742c05a2f8db2d"
Archived-At: <>
Subject: Re: [Doh] [Add] draft-btw-add-rfc8484-clarification (was RE: [Ext] [Technical Errata Reported] RFC8484 (6033))
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
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