Re: [Doh] No truncation for DNS over HTTPS

[Ray Bellis <[e-mail]>]

On 22/03/2018 14:51, Davey Song wrote:
> Sorry. We are talking about two different things. One is about DOH as a
> dns transport protocol. One is about the proxy use case.
> 
> I'm told by the author that the doh draft is to define HTTPS as DNS
> native transport, just as DNS UDP and DNS TCP, that's why I'm asking
> more clarification on truncation.  There is nothing to do with proxy use
> case.

IMHO you can't separate the two.

The client shouldn't be able to tell the difference between a "native"
DOH Server endpoint and one that's being proxied through some smart
middleware to a DNS server that only speaks "normal" UDP and TCP
wire-format queries.

[the analog is those using e.g. stunnel to provide DNS-over-TLS support
as a front end to servers that don't natively support DNS-over-TLS]

> If the DNS API server is deployed as a proxy, it is introduced as a doh
> use case in another draft in dnsop:
> https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02 
> 
> In the doh proxy draft, it keeps the transparent principle which is
> proposed in rfc5625 as well as full support on TCP proposed in s4.4.1 of
> rfc5625. So the "WAN interface" speaking normal UDP must recognize TC
> bit and be able to fall back to TCP. But the "LAN interface" speaking
> DOH should not do truncation. The process of truncation for
> stub-resolver should be done in the"LAN interface" of DNS API client, If
> I understand correctly. 

I believe that's consistent with what I wrote in my second paragraph:

"The alternative is that the proxy has to have sufficient smarts to
recognise the returned +TC and re-issue the request over TCP to the
backend DNS server."

That said (and as suggested a few messages back) a pool of persistent
TCP connections between proxy and server would be preferable to using
UDP and risking truncation.

> I will add your suggestion on doh proxy draft. It is recommended in
> rfc5625 though.

Look at who wrote that RFC :p

Ray