mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Christian <list-christian@web.de>, musl@lists.openwall.com
Subject: Re: [musl] Resolver routines, Postfix DNSSEC troubles - how to check for incompatibilities?
Date: Mon, 13 Apr 2020 12:07:39 -0400	[thread overview]
Message-ID: <20200413160739.GU11469@brightrain.aerifal.cx> (raw)
In-Reply-To: <87imi32xj1.fsf@mid.deneb.enyo.de>

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

  reply	other threads:[~2020-04-13 16:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-13  9:25 Christian
2020-04-13 11:20 ` Christian
2020-04-13 15:29   ` Rich Felker
2020-04-13 15:52   ` Florian Weimer
2020-04-13 16:07     ` Rich Felker [this message]
2020-04-13 16:38     ` Rich Felker
2020-04-13 17:51       ` Christian
2020-04-13 18:04         ` Rich Felker
2020-04-14  9:57       ` Florian Weimer
2020-04-14 15:53         ` Rich Felker
2020-04-14 16:54           ` Florian Weimer

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20200413160739.GU11469@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=fw@deneb.enyo.de \
    --cc=list-christian@web.de \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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

	https://git.vuxu.org/mirror/musl/

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