All,
Replying to both John & Ray's mails at once here. Hopefully that is
okay.
On Thu, 16 Jul 2015 17:22:38 +0100
Ray Bellis <r...@bellis.me.uk> wrote:
> On 16/07/2015 17:10, John Dickinson wrote:
> >
> >
> > On 14/07/2015 11:31, Shane Kerr wrote:
> >>
> >> Second, one possible issue for consideration is that it is already a
> >> problem for resolver operators that a single query can cause a *lot* of
> >> work for the resolver. This issue can be magnified with TCP pipelining:
> >> a bad actor can connect to a resolver and queue a ton of queries in a
> >> few packets (consider how many queries will fit in 1460 bytes).
> >
> > Do you feel this is worse than flooding a server with UDP? Should we
> > have rate limiting?
I think it is worse than flooding with UDP. It allows "fire and forget"
actions from clients:
# we can comfortably fit 20 queries into a single 1280-byte packet
for i = 1 to 20:
packet.append(EXPENSIVE_QUERY)
conn = socket.connect_tcp("someserver", port=53)
conn.write(packet)
# the process can quit and the queries still go...
exit(0)
If you have (for example) a maximum of 5 queries per client, then as
soon as one finishes you'll start another one. All from a 7-packet
exchange on the client side, versus a 40-packet exchange with UDP.
(See, TCP can be more efficient!!!)
The goal of this could be load on the resolver, load on upstream
authoritative servers, or something more creative....
> I think the pipelining is a non-issue, or rather one that already exists.
>
> In practise most (if not all) existing DNS servers that support TCP
> already suffer this potential problem.
True.
It's not clear to me whether out-of-order processing makes pipelining
better or worse, actually.
But perhaps a document about TCP in DNS might want to mention this
issue?
> When the client sends a whole series of queries down the connection
> without waiting for an answer in general this "just works" because
> servers don't routinely flush the incoming TCP read buffer every time
> they respond to a packet.
I don't even think there is a race-free way to flush the incoming
TCP read buffer. :P
Cheers,
--
Shane
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
