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
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?
dns-privacy mailing list