[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200413152913.GT11469@brightrain.aerifal.cx>
Date: Mon, 13 Apr 2020 11:29:13 -0400
From: Rich Felker <dalias@...c.org>
To: Christian <list-christian@....de>
Cc: musl@...ts.openwall.com
Subject: Re: Resolver routines, Postfix DNSSEC troubles - how to check
for incompatibilities?
On Mon, Apr 13, 2020 at 01:20:49PM +0200, Christian wrote:
> Hi again,
>
> So Viktor did some digging:
>
> "The comment on line 25:
>
> https://github.com/runtimejs/musl-libc/blob/master/include/resolv.h#L25
>
> is not encouraging. It suggests that _res is unused.
This is correct. It was probably a really bad idea to offer it at the
header level at all, rather than having a compile-time failure if
software is attempting to use it to configure the resolver. It's
always been intentional that musl's res_* functions are stateless and
thread-safe.
> If so, Postfix DNS does not work correctly with this C library. And
> not just for DANE, since Postfix is also unable to to control
> RES_DEFNAMES and RES_DNSRCH.
>
> Indeed searching the github repo for RES_USE_DNSSEC and RES_USE_EDNS0
> finds hits only the header file, and similarly:
>
>
> https://raw.githubusercontent.com/runtimejs/musl-libc/master/src/network/res_state.c
>
> pretty much rules out support for configurable lookup options."
>
> and
>
> "The musl-libc resolver code also includes [...]:
>
>
> https://github.com/runtimejs/musl-libc/blob/master/src/network/__dns.c#L67-L69
>
> So not terribly safe if using a remote resolver. Definitely no support
> for EDNS(0) or sending the "DO" or "AD" bits in the request.
>
> Always queries all resolvers in parallel without waiting for a short
> timeout from the first one (or use connect(2) for prompt notification of host/port unreachable).
>
> There is no support for truncated responses or TCP failover, so if a
> host has enough IP addresses, some may be dropped, and FcRDNS checks may fail spuriously."
>
> I guess this all shows the incompatibility.
>
> Big questions is now: Will/Can this be resolved?
The intended usage model for musl's resolver has always been that the
stub resolver (which gets static linked into programs if you static
link and is therefore non-upgradeable) be minimal and speak only the
most basic original DNS protocol (RFC 1035) that's understood by all
nameservers. The intended usage model for DNSSEC with this is that you
run your DNSSEC-validating nameserver on localhost (or if you want to
YOLO it, somewhere on a trusted LAN where you daringly assume nobody
can root a random box and use it to spoof DNS replies) and thereby get
ServFail if DNSSEC validation fails (which translates into
EAI_AGAIN/temporary failure with the higher-level functions) and a
trusted result if there's any result at all.
So, the intended fix is simply not doing what Postfix is doing, and
just making the queries normally, and getting DNSSEC protection if
it's configured.
However, that's not necessarily immutable policy. Indeed it doesn't
let a program alter its behavior based on whether the records looked
up were DNSSEC-protected, which presumably Postfix wants to do, since
it's required for conforming use of DANE. (Personally I disagree with
this requirement and believe it's useful to honor TLSA records even on
non-signed domains, but don't expect everyone to just do that.)
However I don't know when or how this sort of change would take place.
The easy short-term fix to use Postfix unmodified with fully
conforming policy is to just link it to a copy (probably static so as
not to conflict with system) of BIND's resolver library.
The easy short-term fix if you don't care that (or are happy that)
TLSA records for unsigned domains would be honored is to just disable
(comment-out/#if 0) the code in Postfix that's checking whether the
result was signed treat all results as if they were.
> Out of what I can understand it makes Postfix with musl pretty much
> unusable, at least less secure (not only because of the lib itself, but
> as well as security features, like DANE get crippled without noticing).
>
> Also I am not sure why there are stubs build to "satisfy broken apps"?
> An exception would have showed right away that something is not working
> and prevented the use.
Indeed I think that was a bad idea, and may remove them (the
header-level parts, not the ABI symbol _res). If so I'll coordinate
with distros first to make sure they have patches ready for any
software that will fail to build (and this might uncover bugs in the
existing packages that need to be fixed, too).
On the other hand if part of the resulting changes end up being
addition of res_n* APIs that do use a configuration context, then it
can't be removed.
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.
