[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6f0e88160040c586605f0174e712b9ee2caf4115@linux.dev>
Date: Sun, 23 Jun 2024 04:09:57 +0000
From: "Lance Yang" <lance.yang@...ux.dev>
To: "Rich Felker" <dalias@...c.org>
Cc: musl@...ts.openwall.com, "Lance Yang" <ioworker0@...il.com>
Subject: Re: [PATCH 1/1] improve DNS resolution logic for parallel
queries
June 22, 2024 at 10:37 PM, "Rich Felker" <dalias@...c.org> wrote:
>
> 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>
> >
>
Hi Rich,
Thanks for taking time to review!
> 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
Missed that, thanks.
>
> 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.
Thanks again for clarifying!
It seems ensuring reliability across multiple separate DNS namespaces
probably require a different approach, such as using a proxy nameserver
that we can control locally to do specific policies.
Have a good weekend!
Lance
>
> 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.
