Re: [dns-privacy] DNS over DTLS

Shane Kerr <> Thu, 01 December 2016 14:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1FAA1129468 for <>; Thu, 1 Dec 2016 06:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VK38ztHwuXkb for <>; Thu, 1 Dec 2016 06:01:31 -0800 (PST)
Received: from ( [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DACC51294AB for <>; Thu, 1 Dec 2016 06:01:28 -0800 (PST)
Received: from [2001:470:78c8:2:8451:b161:196c:6f38] ( by with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1cCRw3-00026g-HF; Thu, 01 Dec 2016 14:02:03 +0000
Date: Thu, 1 Dec 2016 15:01:21 +0100
From: Shane Kerr <>
To: Tariq Saraj <>
Message-ID: <>
In-Reply-To: <>
References: <>
X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/YBWVUVPYMUKfA+I4.gmjp.O"; protocol="application/pgp-signature"
Archived-At: <>
Subject: Re: [dns-privacy] DNS over DTLS
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Dec 2016 14:01:38 -0000


At 2016-12-01 12:50:16 +0500
Tariq Saraj <> 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.