mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: Rob de Wit <>
Subject: Re: [musl] Clarification on the NOERROR resolving choices
Date: Tue, 27 Jun 2023 11:22:12 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Jun 27, 2023 at 05:05:13PM +0200, Rob de Wit wrote:
> Op di 27 jun 2023 om 16:36 schreef Rich Felker <>:
> >
> > It's not a matter of whether it's something other than A or AAAA; just
> > that you have a wildcard in your search domain path. This will never
> > give acceptable results unless your goal is to intercept all lookups
> > and have them return the same thing (either NODATA or a fixed
> > address).
> >
> > Rich
> >
> Thanks for the explanation and quick response.
> I'm not sure I agree that NOERROR is a valid response if some other record
> is queried for. I mean most other implentations do the other thing so even
> if this is the correct way, a lot of compatibility is broken, but that is
> up to you guys.

If you didn't have a search going on and just queried the concatenated
name directly yourself, what you're calling NOERROR (I'd call this
NODATA to distinguish from rcode==NOERROR with ancount>0, the more
"normal" success condition) is the expected result. It's a successful
result that means the thing you queried exists, and just has 0 RRs of
the requested type.

Indeed other implementations do continue search on NODATA and
sometimes even on other more-transient conditions, which can produce
really inconsistent results, sometimes even under attacker control.
musl's stub resolver has always aimed to avoid that kind of thing, and
when search support was added (with much hesitation/reservation) many
years ago, the compromise was that it would preserve the kinds of
consistency our resolver aims for and not replicate every behavior of
glibc or other historic implementations.

> This last bit really shows where we went wrong. I'll remember not to use a
> wildcard without a proper subdomain (lightly). If I had a wildcard A in the
> domain (without subdomain) it would have broken even more by resulting in
> the same address for every host tried.



      reply	other threads:[~2023-06-27 15:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27 14:12 Rob de Wit
2023-06-27 14:36 ` Rich Felker
2023-06-27 15:05   ` Rob de Wit
2023-06-27 15:22     ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).