[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240622143712.GE10433@brightrain.aerifal.cx>
Date: Sat, 22 Jun 2024 10:37:16 -0400
From: Rich Felker <dalias@...c.org>
To: Lance Yang <lance.yang@...ux.dev>
Cc: musl@...ts.openwall.com, Lance Yang <ioworker0@...il.com>
Subject: Re: [PATCH 1/1] improve DNS resolution logic for parallel
queries
On Sat, Jun 22, 2024 at 05:54:29PM +0800, Lance Yang wrote:
> From: Lance Yang <ioworker0@...il.com>
>
> musl’s resolver queries some configured nameservers in parallel and accepts
> the first response. However, if the first response's RCODE indicates
> NXDOMAIN, the resolver terminates the resolution process too early,
> potentially missing valid responses from other nameservers.
>
> There is a DNS issue that is reproducible under specific conditions. For
> instance, it occurs when one of the nameservers does not have the domain
> name and responds first. Even worse, if this nameserver consistently
> responds the fastest, the domain name will never be resolved successfully.
>
> This commit introduces a 'send_tracker' counter to track the number of
> queries sent. The resolver now continues waiting for responses from other
> nameservers unless only one query was sent, ensuring more robust DNS
> resolution.
>
> Signed-off-by: Lance Yang <ioworker0@...il.com>
The behavior you're trying to "fix" is intentional and necessary. See
the recent question here on the list:
https://www.openwall.com/lists/musl/2024/06/14/2
and the answer:
https://www.openwall.com/lists/musl/2024/06/14/3
If you don't accept a (semantically conclusive) NxDomain response but
keep waiting for replies from other nameservers, you necessarily
undermine the whole redundancy purpose of the resolver allowing more
than one nameserver. Negative results at least stall until all servers
respond or time out, and if any of them do time out, you're forced
either to report a temporary failure (making the redundancy breakage
not just slow response but functional distinction) or reverse your
decision to treat the NxDomain as inconclusive (making it so that
attacker who can disrupt network controls how a name resolves).
Neither of these is acceptable.
It sounds like what you want is unioning of multiple disjoint DNS
namespaces served by different nameservers. Doing this in any reliable
and consistent way depends on a lot of policy, that's completely
outside the scope of what libc/stub-resolver could let you define. You
need an actual proxy nameserver running on localhost or somewhere else
you control that performs the unioning according to the particular
policy you want.
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.
