Re: [Doh] Subsection Server Push: unclear wording

Patrick McManus <> Fri, 11 May 2018 16:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D101D126D05 for <>; Fri, 11 May 2018 09:51:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hH-8OA7TZpvM for <>; Fri, 11 May 2018 09:51:24 -0700 (PDT)
Received: from ( [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by (Postfix) with ESMTP id C67D01242F7 for <>; Fri, 11 May 2018 09:51:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id EEA283A04B for <>; Fri, 11 May 2018 12:51:19 -0400 (EDT)
Received: by with SMTP id v2-v6so5278836oif.3 for <>; Fri, 11 May 2018 09:51:19 -0700 (PDT)
X-Gm-Message-State: ALKqPwdVWshO/Zj9/mbnbbURgGypVjXj3xcRGUn0hWCgBGDrD87xr1/t n9VXKHJyOWpJAUF+BIpby0e50ZFbxStwb45eLcg=
X-Google-Smtp-Source: AB8JxZripaYPxS2HK5qGEIB3cA0bQxpOqne2Y++Ao7835QkX+UxwFL9zmyX5+9IgbSu1x7aMt4WDrtVFgSjgQ1F7UhU=
X-Received: by 2002:aca:f388:: with SMTP id r130-v6mr3514724oih.17.1526057479654; Fri, 11 May 2018 09:51:19 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 11 May 2018 09:51:19 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Patrick McManus <>
Date: Fri, 11 May 2018 18:51:19 +0200
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: =?UTF-8?Q?Mateusz_Jo=C5=84czyk?= <>
Cc: DoH WG <>
Content-Type: multipart/alternative; boundary="000000000000fb59c6056bf0f17b"
Archived-At: <>
Subject: Re: [Doh] Subsection Server Push: unclear wording
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 May 2018 16:51:27 -0000

On Fri, May 11, 2018 at 2:17 PM, Mateusz Jończyk <> wrote:

> Hello,
> The Server Push subsection now reads so:
>         Before using DOH response data for DNS resolution, the client MUST
>         establish that the HTTP request URI may be used for the DOH query.
> For
>         HTTP requests initiated by the DNS API client this is implicit in
> the
>         selection of URI. For HTTP server push ({{RFC7540}} Section 8.2)
> extra
>         care must be taken to ensure that the pushed URI is one that the
> client
>         would have directed the same query to if the client had initiated
> the
>         request.
> The first sentence is very misleading. The intention here was supposedly
> that
> the HTTP request URI is trusted by the client, not that it is working.
> This is
> clear by reading the commit that introduced the sentence:
> t/2a4b0b835358d3c4517ae8a038bc86dcf0df04d2
> Additionally, I do not understand it fully, but to me it seems that the
> situation described as "the pushed URI is one that the client would have
> directed the same query to if the client had initiated the request." would
> be
> very rare.
Its not necessarily rare One way is simply a persistent connection to a
recursive resolver has some information it anticipates you would need - and
so pushes it.

Another possibility is that the recursive resolver is decomposing a DNS
answer that contains multiple answers with different TTLS into a multiple
HTTP responses with multiple HTTP freshness lifetimes.

Yet another use case happens because HTTP supports multiple origins on a
single connection. So its likely a CDN or hosting service (like AWS) could
host your configured DOH server and also many other origins you are
accessing. A pushed DOH entry under those circumstances meet the stated
criteria. There are other scenarios as well.

There is interest, of course, in updating this with looser criteria. But
that's a future effort.

> Suppose that the client connects to, and tries to
> push a
> DNS resolution for It seems (as I get it) that the client could
> only
> use the DNS resolution of when is configured by the
> client
> as the chosen DNS API server.

close. A pushed DOH exchange contains an HTTP Response (obviously), a DNS
Response in the body of the HTTP Response (obviously), and an HTTP Request
(less obvious to people new to HTTP push). There are a bunch of reasons for
this, but mostly its because HTTP only operates on exchanges (i.e. a
request response pair) so parts of the specification fall apart if you
don't have a request (e.g. the definition of the Vary response header). So
the server makes up a request (known as a PUSH_PROMISE) and a response and
pushes them both.

The HTTP Request URI mentioned in the text refers to the URI in the pushed
request (i.e. the PUSH_PROMISE).

So in your example you need to inspect the pushed request URI and if that a
DNS API server you would normally use and this is a valid push then you can
you use the resolution of (valid push is an important part of that
- but that's just part of the 7540 machinery.. the tls certificates of the
connection you are on dictate whether or not that origin can be pushed on
that connection - the origin of the pushed request URI doesn't have to be
the same as the SNI, but it does have to be covered by the cert..
SECONDARY_CERTIFICATES/tls-exported-authenticators are a works in progress
that might be able to dynamically expand the scope of a connection by
adding new certificates to it)

> So, a pushed DNS resolution could only be used
> when contacting a HTTP server that at the same time is configured as a DNS
> API,
> which is exceedingly rare.
> I disagree about the rare part.

> Therefore, it would probably be better to specify that only a configured
> server may push DNS responses.
> The security requirement falls on the recipient imo.

> On the other hand, it may happen that the DNS API server pushes additional
> responses to a DNS query. For example, when the DNS client requests an AAAA
> record for and it happens to be an alias for
>, the DNS API server may push a DNS resolution for
> [1]
yep - or decomposition as mentioned above is a possibility.

> Am I reading the text correctly here?
> Greetings,
> Mateusz Jończyk
> [1] I have to admit I do not know DNS well enough to know whether such
> server
> push could be beneficial and when.
> _______________________________________________
> Doh mailing list