[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200420012441.GW11469@brightrain.aerifal.cx>
Date: Sun, 19 Apr 2020 21:24:41 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: musl@...ts.openwall.com
Subject: Re: TCP support in the stub resolver
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.
> >> Then it might be possible that no one will notice the missing TCP
> >> fallback.
> >
> > Really almost no one has noticed it so far, and the places where it
> > was noticed were buggy (IIRC Google or Cloudflare) nameservers that
> > were sending an empty response on truncation rather than a properly
> > truncated response, which seems to have since been fixed. (And in this
> > case the fallback would have been a major performance hit, so it was
> > nice that it was caught and fixed instead).
>
> SPF lookups for various domains return other TXT records, which push
> the size of the response over the limit. There is no way to fix this
> on the recursive resolver side because the TXT RRset is itself larger
> than 512 bytes.
>
> TXT RRsets for DKIM can also approach, but i have not seen them cross
> it.
>
> This is just one application, receiving mail with some form of
> authentcation, that requires TCP fallback. I'm sure there other
> applications.
Yes. I don't claim there aren't potential cases where it's wanted,
just that it hasn't come up aside from the buggy NS with empty TC
response.
Anything related to mail is a case where you really really should be
running a local DNSSEC-validating nameserver, which adds to the appeal
of just doing TCP to begin with (activated by use-vc) or not at all.
But I think before making any decisions I should get started on the
prereq work to make it even possible. The core is currently built
around having an array of up to 2 (for A and AAAA at same time) [512]
arrays the response packets go into. That's changeable without too
much work but requires some care since this is attack surface code.
Rich
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.
