![]() |
|
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.