Re: [Doh] No truncation for DNS over HTTPS

[Massimiliano Fantuzzi <[e-mail]>]

Hi Ray, list,

>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.

That is key statement, shall be clear to everyone implementing clients-only
!

> 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.

Agree but driving towards TCP-only is not exactly desired either, is it ?
More largely, we look at future.
By the way, I agree to have two wireformats, UDP and TCP, helps the client
flagging/react quicker.

Today's DNS is *UDP and TCP only *wether DOH could benefit of other than
TCP-only transport.
IMHO, being liberal on any future transport, and be "sort of strict" on how
backend messaging has to happen, has negative effect of limiting UDP/DNS
initial usage.
In a sense, setting or handling TC bit and siizes should not even be task
of the DOH but demanded to the client implementation, what you think ?

What is the sense of passing a wireformat, if "extra intelligence" is
required outside of the specs of the proto ??
What's better than "forging" out the packet as-is in a pure DNS way ?
Ok you might skip the forgery part but you already have a good packet to
work with DNS standard stuff, why rework it further?

I also wrote this comment on >512 sizes, few minutes ago:
https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/110#issuecomment-375335739

Client implementation should be as easy and standard as possible. To copy
dig source code and make it dig-o-h just a joke.
Quick example, my pre-doh implementation used CURLlibs and system's
resolver, so easy that is almost ugly (server-only from a DNS point of
view).
Works on every DNS client (and TCP was left in the TODO, just for the sake
of precision).
AND as a plus, enables DOH client and server implementations (client C,
server PHP).
I changed nothing in how the local and remote systems acquire or query DNS
informations (i.e. DOH is already a proxy itself)

Quoting your last, Ray
> The client shouldn't be able to tell the difference
Proxy specific reasoning has always represented an "added complexity" to
become really transparent...

I believe re-describing truncation or mentioning how-to proxyfication
happens, are not primary goals in doh-draft, what are your thoughts ?
If (1035) then (DNS). If (HTTP) then (stateless).
 = burden of the client to find it's way through standards of DNS querying
(i.e. retry the same server after timeout, try next server and assume
broken, retry in TCP, whatever).

Sorry for long post.


With kind regards,
max


On Thu, Mar 22, 2018 at 4:02 PM, Ray Bellis <[e-mail]> wrote:

> 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
>
> _______________________________________________
> Doh mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/doh
>



-- 

*Massimiliano Fantuzzi*
*IT professional, expert in DB Linux and networks.*

*[phone] <%2B41%2076%20754%201037>*