Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.