Re: [Doh] Clarification for a newbie DoH implementor

["Mark Delany" <[e-mail]>]

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.