Re: [dns-privacy] DNS over DTLS

Daniel Kahn Gillmor <> Fri, 02 December 2016 06:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8790F129B8F for <>; Thu, 1 Dec 2016 22:48:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3moi4gxLwWst for <>; Thu, 1 Dec 2016 22:48:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D8E0B12963E for <>; Thu, 1 Dec 2016 22:48:32 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPSA id 90E99F98C; Fri, 2 Dec 2016 01:48:27 -0500 (EST)
Received: by (Postfix, from userid 1000) id D34EB20662; Fri, 2 Dec 2016 01:48:25 -0500 (EST)
From: Daniel Kahn Gillmor <>
To: Tariq Saraj <>, Shane Kerr <>
In-Reply-To: <>
References: <> <> <>
Date: Fri, 02 Dec 2016 01:48:25 -0500
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
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: Fri, 02 Dec 2016 06:48:35 -0000

On Fri 2016-12-02 01:22:40 -0500, Tariq Saraj wrote:
> 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".

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

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?