Subject: Re: [dns-privacy] DNS over DTLS

From: Shane Kerr <[email-masked]>
Date: Thu, 1 Dec 2016 15:01:21 +0100

Tariq,

At 2016-12-01 12:50:16 +0500
Tariq Saraj <[email-masked]> wrote:

> My question is that, at one side "Specification for DNS over Transport
> Layer Security (TLS) i.e. RFC7858" is a proposed standard now.
> Whereas, on the other side in the "draft-ietf-dprive-dnsodtls-13",
> The motivations for proposing DNS-over-DTLS are that
> 
>    o  TCP suffers from network head-of-line blocking, where the loss of
>       a packet causes all other TCP segments to not be delivered to the
>       application until the lost packet is re-transmitted.  DNS-over-
>       DTLS, because it uses UDP, does not suffer from network head-of-
>       line blocking.
> In the very next point of this draft it is also mentioned that " However,
> with TCP Fast Open [RFC7413], the implementation can achieve the same RTT
> efficiency as DTLS."
> In addition to that, in the recent IETF97 meeting regarding the DNS privacy
> they have presented a technique of OOOP for TCP.
> So, why the community still need DTLS for DNS?

TCP Fast Open does not work for the first connection between hosts.
This makes it effective in cases where you expect repeated connections
(such as in the stub to resolver case), but possibly less effective in
cases where you do not expect repeated connections, or where you
expect connections to happen a long time apart.

Further, the specific drawback is about the case of lost packets. Since
TCP (and thus TLS) is a stream-oriented protocol, it cannot deliver
data until all packets in the sequence are available. So if packet #2 is
lost, packets #3, #4, and all later packets cannot be delivered to the
application until packet #2 is re-sent. DTLS, since it is a datagram
protocol, does not have this limitation.

To be honest, there has not been a strong push for DNS over DTLS. Even
with DNS over DTLS, we need DNS over TLS as a fallback in the case of
truncation. So adding DNS over DTLS is always an extra cost. It might
be that DNS over DTLS is worth the extra code and complexity, but I
think it is safe to say that we do not have enough operational
experience yet to know for sure.

Cheers,

--
Shane

---

From: Tariq Saraj <[email-masked]>
Date: Fri, 2 Dec 2016 11:22:40 +0500

Hi Shane,
Thanks for your detailed reply, the point I am trying to highlight is the
changes in TCP for DNS which is "TCP out of order packet delivery, i.e. the
OOOP".

-- 
Regards
Tariq Saraj
Riphah Institute of Systems Engineering, Islamabad

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 02 Dec 2016 01:48:25 -0500

> changes in TCP for DNS which is "TCP out of order packet delivery, i.e. the

I think you're referring to "out of order processing" for DNS requests
by a recursive resolver.  While necessary for reasonable performance
over TCP, I don't think this approach remediates TCP
head-of-line-blocking.

imagine a client who makes two queries across a TCP connection in rapid
succession, the first for slow.example and the second for fast.example.

many traditional (old, unoptimized) DNS recursive resolvers will try to
find the answer for slow.example before they even start making the
queries needed for fast.example.  they might not even read the second
query from the TCP connection before responding to the first one.

OOOP says that a DNS recursive resolver should read queries as they come
in over TCP, even if it still has responses pending for other queries
from that connection.

IOW, the dns resolution *itself* should not block based on slow DNS
responses from the authoritative servers it queries.

but none of that resolves the problem of TCP head-of-line blocking.  if
one packet carrying a query on one TCP connection gets dropped, the
receiving server can't see any of the rest of the packets until the
earlier packet is re-sent.  (and vice versa for replies going from
recursor to stub)

does this make sense?

         --dkg

---

From: Tariq Saraj <[email-masked]>
Date: Fri, 2 Dec 2016 18:32:09 +0500

HI Daniel,
So true, and thank you very much.... also thanks to Shane....