[musl] Clarification on the NOERROR resolving choices

[musl] Clarification on the NOERROR resolving choices

[Rob de Wit]

[-- Attachment #1: Type: text/plain, Size: 1220 bytes --]

Hi

I ran into some issues lately and found this in the mailing list archive
https://www.openwall.com/lists/musl/2019/05/30/3

The problem I had was with Alpine containers that suddenly failed resolving
any hostname. I ended up tracing it back to a change I made in a domain
that was in the "search" fiels in /etc/resolv.conf. The change was a
wildcard TXT field. So when the resolver was resolving
<host>.<tld>.<searchdomain>.<tld> it received an NOERROR reply. This
indicates there is a record but just not a "A" or "AAAA" one. Perfectly
valid as far as I know, but the resolver then quits the search.

Maybe someone here can clarify this behaviour, because from the referred
thread in the mailing list I get that this is caused by malfunctioning DNS,
but in my case I don't think it is.

Right now our options are:

   - adjusting ndots in resolv.conf - but we actually use the search path
   - adding a dot at the end - this can only work if we know up front we
   don't want the search path
   - replacing Alpine with some libc-based image - this involves many
   changes
   - not to do it again (adding wildcard for something other than A or AAAA
   records)



Met vriendelijke groet / Kind regards

*Rob de Wit*

[-- Attachment #2: Type: text/html, Size: 2067 bytes --]

Re: [musl] Clarification on the NOERROR resolving choices

[Rich Felker]

On Tue, Jun 27, 2023 at 07:12:51AM -0700, Rob de Wit wrote:
> Hi
> 
> I ran into some issues lately and found this in the mailing list archive
> https://www.openwall.com/lists/musl/2019/05/30/3
> 
> The problem I had was with Alpine containers that suddenly failed resolving
> any hostname. I ended up tracing it back to a change I made in a domain
> that was in the "search" fiels in /etc/resolv.conf. The change was a
> wildcard TXT field. So when the resolver was resolving
> <host>.<tld>.<searchdomain>.<tld> it received an NOERROR reply. This
> indicates there is a record but just not a "A" or "AAAA" one. Perfectly
> valid as far as I know, but the resolver then quits the search.

This is the intended behavior. When reaching a name that exists, the
search stops and uses that result. Otherwise the search outcome will
be unstable depending on factors like which address family was
queried. In theory, that particular case could be precluded by always
performing both A and AAAA queries, even when only one was requested
by the caller, but users would likely not be happy with this behavior,
especially if it meant waiting for an uncached AAAA result that's not
even desired or erroring out in sloppy IPv4-only environments where
something is setup to make the AAAA fail. But not even getting into
that specific case, it's just having consistent high level semantics.
Search continues if and only if the attempted name does not exist.

> Maybe someone here can clarify this behaviour, because from the referred
> thread in the mailing list I get that this is caused by malfunctioning DNS,
> but in my case I don't think it is.

It's not "malfunctioning", just returning something whose semantics
mismatch what you want.

> Right now our options are:
> 
>    - adjusting ndots in resolv.conf - but we actually use the search path

Setting ndots greater than 1 always gives undesirable behaviors like
adding potentially substantial delay when looking up a name that was
already fully qualified, independently of whether you're using musl or
something else. It really should be treated only as a way to support
legacy setups, not part of new designs.

>    - adding a dot at the end - this can only work if we know up front we
>    don't want the search path
>    - replacing Alpine with some libc-based image - this involves many
>    changes
>    - not to do it again (adding wildcard for something other than A or AAAA
>    records)

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

Re: [musl] Clarification on the NOERROR resolving choices

[Rob de Wit]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

Op di 27 jun 2023 om 16:36 schreef Rich Felker <dalias@libc.org>:

>
> 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.

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.

[-- Attachment #2: Type: text/html, Size: 1394 bytes --]

Re: [musl] Clarification on the NOERROR resolving choices

[Rich Felker]

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 <dalias@libc.org>:
> 
> >
> > 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.

Exactly.

Rich