Subject: Re: [Doh] Clarification for a newbie DoH implementor

From: "Mark Delany" <[email-masked]>
Date: 18 May 2019 23:38:15 +0000

On 18Apr19, Mark Delany allegedly wrote:
> I'm working on a proxy/server DoH implementation designed to install on CPE

> The questions:

I have another.

## Truncated response

In the scenario where a DoH server is implemented as a HTTPS server
that relays the query onto a cache, say by using nginx/ATS as HTTPS
front-ends, RFC848 is silent on the matter of a truncated response
coming back from the cache and passing thru the DoH server.

Presumably the DoH server should simply pass the response back to the
DoH client with the TC bit intact.

However relegating TC handling to the DoH client can't work as the DoH
client has no way to re-issue the query with an "ask the DoH server to
use TCP" signal.

I also worry that a dumb stub/DoH client combo could easily get in a
loop as it sees the TC bit and re-issues the query gets another TC bit
and re-issues the query - rinse and repeat.

One solution is to have the DoH server detect TC and directly re-issue
the query via TCP on behalf of the DoH client but that seems to go
against the implicit design whereby a DoH server is mostly just a dumb
relay rather than an intelligent intermediary. It's also unlikely to
be a viable solution when using most of the off-the-shelf HTTPS
front-ends.

Another solution might be to have one of the DoH components
arbitrarily zero the TC bit to protect agsinst dumb stubs but that
doesn't seem right or resilient in terms of applications consuming the
results.

It seems to me that a TC response from a DoH server can never be
handled correctly which probably excludes otherwise legitimate
implementations which want to use off-the-shelf HTTPS front-ends.

Alternatively, if TC is never allowed as a return from a DoH server it
needs to be explicitly stated in the RFC or if it is allowed, provide
a mechanism for the client to signal the need for a TCP re-query.

For the curious, this whole question came about because I observed a
TC response and a subsequent TCP re-query from a "stub" in my
lab. Specifically from a macOS platform - which admittedly has an
interesting relationship with client-side DNS. Nonetheless, the
problem seems real enough to warrant trying to find a solution.

Mark.

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 18 May 2019 22:27:26 -0400

*From: *Mark Delany <[email-masked]>
*Date: *Sat, May 18, 2019 at 7:38 PM
*Cc: * <[email-masked]>

> client has no way to re-issue the query with an "ask the DoH server to

Correct.

> relay rather than an intelligent intermediary.

I don't think the implication you describe is intended.  This sort of
reissuance is the expected implementation in the architecture you're
describing.

> It's also unlikely to

In practice all the various DoH implementations do not seem to have
encountered a problem with this.  That might be because the easiest DoH
implementation is simply a wrapper around a traditional stub or recursive
resolver core, which already has to handle query reissuance.

> a mechanism for the client to signal the need for a TCP re-query.

DoH servers are permitted to return TC responses.  Clients can do whatever
they like with their truncated response, which may or may not be of any use
to them.  Certainly a DoH server that returns TC frequently is not likely
to be very useful.  As RFC 8484 notes, when truncation cannot be avoided,

   a DoH server could use an HTTP error instead of a non-error
   response that has the TC bit set.

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

---

From: "Mark Delany" <[email-masked]>
Date: 19 May 2019 05:52:55 +0000

> reissuance is the expected implementation in the architecture you're

Thanks. I think you're right that I've been thinking of a DoH server
as being a dumber component than perhaps intended.

But having to glean this model from potentially unintended
consequences - such as a forced outcome for sensibly dealing with TC -
is a bit disconcerting.

If you infer from RFC8484 that a DoH Client is a simple call to an
HTTPS library embedded in an application you get quite a different
architectural perspective than if you infer a DoH client as being a
service on your home/office gateway or portable wifi AP.

In the former there is only one resolver library in the path, in the
latter there are two (per your "easiest implementation" comment). How
you divvy up roles and responsibilities in each of these models
substantially differs.

In the former model most, if not all, of the stub resolver smarts live
in the DoH server. That could include nameserver timeouts, TC retries,
ECS settings and more. That agrees with the inference you suggest.

In the latter model the division of labor is much more ambiguous as in
effect you have one stub resolver calling another with both having
local configurations and both assuming they have sole responsibility
for client-side errors, retries and feature management.

Put another way, in the former model a DoH server most closely
performs the role of a stub resolver in the latter model a DoH server
most closely performs the role of a recursive resolver but it has no
clue as to which one it is being used as.

It's a pity the second model didn't get much attention because if DoH
becomes pervasive, it's hard to believe it will be as a dumb HTTPS
client embedded in a bazillion applications.

Not much to be done about all of that now I supposed. The main
conclusion I've drawn thus far is that the first model is relatively
straightforward, but the second model could benefit from both
specification guidance as well as possible protocol support to
negotiate overlapping roles and responsibilities.

Mark.

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 19 May 2019 11:41:28 -0400

*From: *Mark Delany <[email-masked]>
*Date: *Sun, May 19, 2019 at 1:53 AM
*To: *DoH WG

> consequences - such as a forced outcome for sensibly dealing with TC -

Given the large number of potential deployment scenarios (including the two
you've noted), the authors felt that it was best to focus on specification,
and avoid attempting to enumerate the expected patterns of usage in each
scenario.

> clue as to which one it is being used as.

The classic DNS protocol doesn't have any such role indications either.
Thus, when I send a query to my network's advertised DNS server, I have no
idea whether it is acting as a recursive, forwarding my query to a
recursive (e.g. dnsmasq), or something in-between.  This is transparent and
generally does not cause problems.

DoH is a transport for DNS.  Since DNS has no protocol-level indication of
these responsibilities, neither does DoH.

> negotiate overlapping roles and responsibilities.

In practice, none of this seems to be a problem.  DoH servers simply do
their best to fully answer the query, securely and in a timely fashion.
The details of that are left to the implementor, as it is with classic DNS
servers, whose detailed behavior varies widely according to the preferences
of the operator.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 20 May 2019 09:12:10 +0100

On 19/05/2019 16:41, Ben Schwartz wrote:

> Thus, when I send a query to my network's advertised DNS server, I have 
> no idea whether it is acting as a recursive, forwarding my query to a 
> recursive (e.g. dnsmasq), or something in-between.  This is transparent 
> and generally does not cause problems.

Not so - see RFC 5625 and SSAC035.

Ray

---

From: "Mark Delany" <[email-masked]>
Date: 21 May 2019 04:48:50 +0000

On 19May19, Ben Schwartz allegedly wrote:

> This is transparent and generally does not cause problems.

> In practice, none of this seems to be a problem.

I'm interested to know how you came to those conclusions. When you say
"generally" and "seems" that sounds more anecdotal than empirical.

(Was there ever a bake-off for DoH? Three independent implementations and all
that jazz?)

Having said that I accept the reality that as long as at least one IP address
gets returned in a response, then everything else that the DNS community has
layered on top of a DNS query/response is mostly icing on the cake.

IOWs the lowest common denominator is all that most clients rely on so all my
hand-wringing around TC and ECS and roles is so much esotericism. Sad for me but
hardly important.

As just one example of how indifferent clients are; as you observe, many DoH
servers re-query TC responses locally thus insulating clients. Contrast this
with dnsmasq which appears to arbitrarily clear TC and return the truncated
response to client as if it were whole.

That the Internet functions with these two completely opposing outcomes is
impressive. I'm not sure how that guides a DoH implementor to a robust solution
but it does seem to perpetuate the notion that any solution is legit as long as
it generally "seems" to work.

> DoH is a transport for DNS.

That misapprehension on my part is what initiated this thread in the first
place.

I initially saw DoH as a port 53 tunnel, but it is anything but that if you
include client and server behavior.

At the very least the DoH server is content-aware and responds to TC=1 and
server timeouts and who knows what else based on what local resolver it is
using. In addition the DoH client is specified to be aware of TTLs and HTTP
"Age" headers and modify the response accordingly.

We also saw earlier in this thread some discussion around DoH components
participating in ECS settings.

To my mind that makes DoH more akin to an RPC interface created by slicing thru
a stub resolver.

Enough ranting. You provided useful feedback that I can act on, so thanks for
that.

Mark.