On Mon 2021-11-22 11:27:50 -0500, Ben Schwartz wrote: > On Fri, Nov 19, 2021 at 6:48 PM Daniel Kahn Gillmor <[email protected]> > wrote: > ... > >> To avoid incurring additional minor timeouts for such a recursive >> resolver, the pool operator should either: >> > > Nit: These should not be timeouts. The non-participating backends are > expected to return TCP RST or ICMP Destination Unreachable (Port > Unreachable), leading to immediate fallback after 1 RTT. Maybe the draft > needs some guidance to that effect. > > A timeout is still possible if the network is misbehaving (e.g. ICMP > blackhole), but it shouldn't happen otherwise.
Thanks, Ben!
I agree that these shouldn't necessarily be "timeouts" -- but it's not
just network misbehavior that could cause them to be timeouts, there are
some service administrators who believe that having ports in "stealth
mode" (i.e. not responding with a "port closed" ICMP response) is
somehow safer; and, in the event of extreme resource exhaustion, it's
conceivable that TCP RST messages wouldn't get sent.
So "timeout" is there to make sure we handle all of these cases, and we
do still want to minimize the number of places where we risk incurring
them, since neither sender nor receiver can guarantee that the
appropriate signalling makes it through in a timely fashion.
Any concrete proposals for what text to change or add would be welcome!
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
