[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Apr 2020 12:07:39 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: Christian <list-christian@....de>, musl@...ts.openwall.com
Subject: Re: Resolver routines, Postfix DNSSEC troubles - how to check
for incompatibilities?
On Mon, Apr 13, 2020 at 05:52:34PM +0200, Florian Weimer wrote:
> * Christian:
>
> > 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. 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.
>
> Are these changes to the RES_DEFNAMES and RES_DNSRCH flags really
> necessary? Why doesn't Postfix use res_query (or perhaps res_send) as
> appropriate?
What I'd really like to see Postfix doing is not trying to poke
at/override configuration, and assuming option edns0 is set in
resolv.conf if the user wants it. Then, if it's set and the resolver
supports making edns queries with DNSSEC result flags available, it
can act on them and treat "valid result for signed domain" differently
from "valid result for unsigned domain".
My preferred behavior if not, that's compatible with what's always
been the intended musl stub resolver usage model, is that treat all
DNSSEC behavior as outsourced to the configured nameserver and simply
lookup records. (If wanted, the user's local nameserver can then drop
TLSA records for unsigned domains, or report them to be honored as if
they were signed, according to the wishes of whoever set it up.) But
it might be unrealistic to expect Postfix to do this.
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.
