[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 4 Nov 2023 11:41:40 -0400
From: Rich Felker <dalias@...c.org>
To: Ayush Agarwal <ayush@...shnix.com>
Cc: musl@...ts.openwall.com
Subject: Re: questions about musl DNS resolver
On Sat, Nov 04, 2023 at 12:12:58PM +0530, Ayush Agarwal wrote:
> Hi,
>
> I was reading about how DNS works in Linux distributions and I noticed
> some differences in the way libc resolvers work in glibc and in musl.
> I hope it's okay if I ask a few (potentially stupid) questions?
>
> 1. Why not offer a different man page on musl distributions for pages
> like resolv.conf(5) and resolver(3) considering how their
> implementation details and behavior are different from glibc? Is not
> offering them intentional or does it require someone to step up and
> write the documentation?
Ideally the linux-man provided ones would document which things are
glibcisms vs widely available elsewhere, but short of that, maybe it
would be nice for someone to maintain musl-specific versions for
distros to use.
> 2. Which options in the resolv.conf(5) man page are supported by musl?
> I know "search" and "nameserver" are supported but what about
> "options" like "ndots", "edns0", "use-vc", "trust-ad"?
search/domain, nameserver, and options: ndots, attempts, and timeout.
trust-ad would be a no-op; it's always on. glibc's having it optional
and off by default badly breaks anything trying to use dnssec/dane
right.
edns0 is not supported, intentionally because it would require munging
and unmunging queries behind the caller's back (or treating
libc-internal queries differently). use-vc is not supported because it
doesn't really play well with our parallel query model or stateless
design.
> 3. It seems that version 1.2.1 added support for DNSSEC queries but
> how do I confirm if DNSSEC queries are sent and received with musl? Do
> I need to use the "option edns0 trust-ad" directive in resolv.conf for
> it work? The usual suspects like drill and kdig seem to use their own
> resolver.
I'm not sure what you man by "DNSSEC queries". The normal application
usage for DNSSEC that's supported by musl is for the stub resolver to
make a normal query, with the AD bit set, to a trusted (ideally should
run on localhost so trust is not crossing network boundaries)
nameserver that will validate DNSSEC, ServFail on anything
invalid/spoofed, and report via the AD bit of the answer packet
whether the result is DNSSEC-protected.
As of musl 1.2.1, the AD bit of the query is always set when you use
the res_* API. All you have to do is interpret it in the answer.
If you want to actually do DNSSEC validation yourself, or just see the
RRSIG, etc. records, you need to construct a suitable query in EDNS0
form with the DO bit set. It can be sent (and the answer received) via
the res_send function. Strictly speaking this does not depend on the
musl version, but you'll need 1.2.4+ to get answers larger than 512
bytes (which these answers usually are).
The resolv.conf edns0 option has nothing to do with this. It's about
whether the stub resolver's construction of queries will make them in
EDNS0 form, not whether res_send will accept EDNS0-form packets from
the caller.
> 4. The musl version 1.2.4 added TCP fallback to DNS. Is this fallback
> intended to work automatically when the size of a DNS query is large
> or does it need any configuration?
Yes, it works automatically. Originally I intended to add capability
to skip fallback if there's a non-empty answer list in the truncated
packet, which might be an option at some point in the future, but
right now it always happens, and by default it will continute to
automatically happen.
So, TL;DR: no configuration is needed for any of the stuff you want.
It just all works, or at least is intended to. If you run into
problems, please reach out here for help.
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.
