[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87mu75uq3p.fsf@mid.deneb.enyo.de>
Date: Tue, 21 Apr 2020 11:48:10 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: TCP support in the stub resolver
* Rich Felker:
> On Mon, Apr 20, 2020 at 08:26:45AM +0200, Florian Weimer wrote:
>> * Rich Felker:
>>
>> > On Sun, Apr 19, 2020 at 10:12:56AM +0200, Florian Weimer wrote:
>> >> * Rich Felker:
>> >>
>> >> >> No, you can reuse the connection for the second query (in most cases).
>> >> >> However, for maximum robustness, you should not send the second query
>> >> >> until the first response has arrived (no pipelining). You may still
>> >> >> need a new connection for the second query if the TCP stream ends
>> >> >> without a response, though.
>> >> >
>> >> > That's why you need one per request -- so you can make them
>> >> > concurrently (can't assume pipelining).
>> >>
>> >> Since the other query has likely already been cached in the recursive
>> >> resolver due to the UDP query (which is already in progress), the
>> >> second TCP query only saves one round-trip, I think. Is that really
>> >> worth it?
>> >
>> > If the nameserver is not local, absolutely. A round trip can be over
>> > 500 ms.
>>
>> Sure, but you have to put this into context. In this situation, you
>> already need three roundtrips (UDP query, TCP handshake, TCP query).
>> The other TCP handshake increases the packet count quite noticeably.
>
> Yes but they happen concurrently. Of course it's possible that you
> have bandwidth so low that latency is affected by throughput, but I
> think the far more common case nowadays is moderately fast connection
> (3G cellular, possibly rate-limited, or DSL) but saturated with other
> much-higher-volume traffic causing the latency.
I'm not sure. It should be possible to measure this.
Generally, once you have to use TCP, performance will not be good in
any case, especially if the recursive resolver is not local.
I'm excited that Fedora plans to add a local caching resolver by
default. It will help with a lot of these issues.
> BTW, am I mistaken or can TCP fastopen make it so you can get a DNS
> reply with no additional round-trips? (query in the payload with
> fastopen, response sent immediately after SYN-ACK before receiving ACK
> from client, and nobody has to wait for connection to be closed) Of
> course there are problems with fastopen that lead to it often being
> disabled so it's not a full substitute for UDP.
There's no handshake to enable it, so it would have to be an
/etc/resolv.conf setting. It's also not clear how you would perform
auto-detection that works across arbitrary middleboxen. I don't think
it's useful for an in-process stub resolver.
> Do you think EDNS support eliminates the need for TCP?
There is a window of package sizes where it avoids TCP and works (from
512 to something between 1200 and 1500 bytes) *if* the recursive
resolver does EDNS at all. For decent compatibility, you would have
to have heuristics in the stub resolver to figure out if
FORMERR/NOTIMP and missing responses are due to lack of EDNS support.
The other problem with EDNS is that for sizes on the large end
(certainly above the MTU), it depends on fragmentation. Fragmentation
is completely insecure because in DNS packets, all the randomness is
in one fragment, so packet spoofing only needs to guess the fragment
ID (and the recipient IP stack will provide the UDP port for free).
Some of us have been working on eliminating fragmented DNS responses
for that reason, which unfortunately reduces the reach of EDNS
somewhat.
Above 4096 bytes, pretty much all recursive resolvers will send TC
responses even if the client offers a larger buffer size. This means
for correctness, you cannot do away with TCP support.
Some implementations have used a longer sequence of transports: DNS
over UDP, EDNS over UDP, and finally TCP. That avoids EDNS
pseudo-negotiation until it is actually needed. I'm not aware of any
stub resolvers doing that, though.
(Things change if you connect to a local stub resolver, of course.)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
