[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 18 Apr 2020 19:14:24 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: TCP support in the stub resolver (was: Re: Outgoing DANE not working)
* Rich Felker:
> On Fri, Apr 17, 2020 at 11:22:34AM +0200, Florian Weimer wrote:
>> >> > However it's not clear how "fallback to tcp" logic should interact
>> >> > with such concurrent requests -- switch to tcp for everything and
>> >> > just one nameserver as soon as we get any TC response?
>> >>
>> >> It's TCP for this query only, not all subsequent queries. It makes
>> >> sense to query the name server that provided the TC response: It
>> >> reduces latency because that server is more likely to have the large
>> >> response in its cache.
>> >
>> > I'm not talking about future queries but other unfinished queries that
>> > are part of the same operation (presently just concurrent A and AAAA
>> > lookups).
>>
>> If the second response has TC set (but not the first), you can keep
>> the first response. Re-querying both over TCP increases the
>> likelihood that you get a response from the same cluster node (so more
>> consistency), but you won't get that over UDP, ever, so I don't think
>> it matters.
>>
>> If the first response has TC set, you have an open TCP connection you
>> could use for the second query as well. Pipelining of DNS requests
>> has compatibility issues because there is no application-layer
>> connection teardown (an equivalent to HTTP's Connection: close). If
>> the server closes the connection after sending the response to the
>> first query, without reading the second, this is a TCP data loss
>> event, which results in an RST segment and potentially, loss of the
>> response to the first query. Ideally, a client would wait for the
>> second UDP response and the TCP response to arrive. If the second UDP
>> response is TC as well, the TCP query should be delayed until the
>> first TCP response came back.
> Indeed it sounds like one TCP connection would be needed per request,
> so switchover would just be per-request if done.
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.
> My leaning is probably not to do fallback at all (complex logic,
> potential for unexpected slowness, not needed by vast majority of
> users) and just add TCP support with option use-vc for users who
> really want complete replies. All of this would be contingent anyway
> on making internal mechanisms able to handle variable result size
> rather than fixed-size 512 bytes so it's not happening right away.
> Doing it carelessly would create possibly dangerous bugs.
I still think it's wrong. The protocol says that you must perform TCP
fallback. If you don't, it's rather confusing for the libresolv
interfaces.
> I'm still also somewhat of the opinion that users who want a resolver
> library (res_* API) with lots of features should just link BIND's, but
> it would be nice not to have to do that.
You could drop the res_* interfaces from musl. They are mostly needed
for non-address queries, and those are the ones that tend to be larger
than 512 bytes.
Then it might be possible that no one will notice the missing TCP
fallback.
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.
