Subject: [Doh] No truncation for DNS over HTTPS

From: Davey Song <[email-masked]>
Date: Thu, 22 Mar 2018 17:20:56 +0800

Hi,

Although the dns-udpwireformat MIME type was defined, the dns wireformat
data should not be treated as a datagram encapsulted in a HTTPs header but
a new byte stream over HTTPs (similar with DNS TCP usage). No truncation
loop is needed. Peopole may take it for granted, but It should be
explicitely mentioned in this draft.

I mentioned this before in other mails but I notice it is not mentioned in
the latest 03 version.

Best regards,
Davey

---

From: Ray Bellis <[email-masked]>
Date: Thu, 22 Mar 2018 10:24:32 +0000

On 22/03/2018 09:20, Davey Song wrote:

> data should not be treated as a datagram encapsulted in a HTTPs header
> but a new byte stream over HTTPs (similar with DNS TCP usage). No
> truncation loop is needed. Peopole may take it for granted, but It
> should be explicitely mentioned in this draft.   

If the DNS API Server is proxying between DOH and a real UDP DNS server
then the UDP DNS server might still set the TC bit and the proxy could
return that, so the client may still have to cope with +TC.

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.

Ray

---

From: manu tman <[email-masked]>
Date: Thu, 22 Mar 2018 10:31:47 +0000

> recognise the returned +TC and re-issue the request over TCP to the

There is not much the client can be doing with the TC but here right. I
mean it is using tcp already. When producing, IMO the proxy should be aware
of the TC bit and retry over TCP when it happens.
Manu

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Mar 2018 13:05:18 +0000

> explicitely mentioned in this draft.

Agreed.

The implementation I would like (when DOH is implemented by a proxy in
front of an old-transport DNS server) has a pool of TCP connections from
the proxy to the back-end DNS server(s), over which incoming requests can
be multiplexed.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Forties, Cromarty, Forth, Tyne, Dogger: Southwest, backing south, 4 or 5,
increasing 6 or 7. Slight or moderate, becoming rough. Rain later. Good
occasionally poor.

---

From: manu tman <[email-masked]>
Date: Thu, 22 Mar 2018 13:28:07 +0000

edit: fixing autocorrect....

There is not much the client can be doing with the TC bit here right. I
mean it is using tcp already. When proxying, IMO the proxy should be aware
of the TC bit and retry over TCP when it happens.
The client does not need to be aware of that. There would need to be some
involvement from the proxy in not just passing around a packet, but
actually introspect it a bit and make accurate decisions when this happens.

Manu

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Mar 2018 09:37:17 -0400

> the proxy to the back-end DNS server(s), over which incoming requests can

That sounds like an implemntation decision or maybe a policy, not a
protocol decision.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Mar 2018 13:48:32 +0000

> That sounds like an implemntation decision or maybe a policy, not a

True :-) I think my point is that if you have persistent back-end TCP
connections (which you want for performance), there's no advantage to
doing UDP - the TC dance slows things down, and dual-protocol backends
have a complexity cost.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: North, backing west or northwest, 4 or 5. Moderate, occasionally
rough at first. Rain later in northwest. Good, becoming moderate later in
northwest.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 22 Mar 2018 09:52:03 -0400

> doing UDP - the TC dance slows things down, and dual-protocol backends

No question that an implemntation that did _not_ do as you say would
be boneheaded.  I am totally prepared to support a paragraph with
advice to implementers with this observation, but it's not 2119
protocol words, I think.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Davey Song <[email-masked]>
Date: Thu, 22 Mar 2018 14:51:04 +0000

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.

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 will add your suggestion on doh proxy draft. It is recommended in rfc5625
though.

Davey

---

From: Ray Bellis <[email-masked]>
Date: Thu, 22 Mar 2018 15:02:05 +0000

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

---

From: Davey Song <[email-masked]>
Date: Thu, 22 Mar 2018 15:30:04 +0000

> middleware to a DNS server that only speaks "normal" UDP and TCP

 Fair enough

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

Yes. I re-read your first comment. It is not a disagreement to my mail, but
an adding. Thanks.

> Look at who wrote that RFC :p

OK. You are the boss ; p

Davey

---

From: Massimiliano Fantuzzi <[email-masked]>
Date: Thu, 22 Mar 2018 16:43:08 +0100

Hi Ray, list,

>middleware to a DNS server that only speaks "normal" UDP and TCP

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

> 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

-- 

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

*+41 76 754 1037 <%2B41%2076%20754%201037>*