[exim-cvs] stop-gap: doc glibc 2.31 RES_TRUSTAD/trust-ad

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Exim Git Commits Mailing List
Datum:  
To: exim-cvs
Betreff: [exim-cvs] stop-gap: doc glibc 2.31 RES_TRUSTAD/trust-ad
Gitweb: https://git.exim.org/exim.git/commitdiff/dce58c04af4439fec7269f83886e22b503756a8f
Commit:     dce58c04af4439fec7269f83886e22b503756a8f
Parent:     47aaa9d6df68458c03a9fa65c6f2fd2bdee898f9
Author:     Phil Pennock <pdp@???>
AuthorDate: Tue Apr 21 18:59:15 2020 -0400
Committer:  Phil Pennock <pdp@???>
CommitDate: Tue Apr 21 18:59:15 2020 -0400


    stop-gap: doc glibc 2.31 RES_TRUSTAD/trust-ad


    In glibc from release 2.31 onwards (change added in their commit
    446997ff14) setting `dns_dnssec_ok` will not be sufficient.  glibc has
    added a new `options trust-ad` toggle for `/etc/resolv.conf` and a C
    macro `RES_TRUSTAD`.


    This will break existing deployments and binaries.


    Our current mechanism for enabling DNSSEC is with an option named to
    closely match the DNS feature required, so it is probably inappropriate
    to tinker with a second option there.  Instead we probably need a new
    meta-option for the concept of DNSSEC, add the second new flag there,
    and move `dns_dnssec_ok` to a legacy deprecated option.


    That will only work if the machine Exim is built on has the new C macro,
    but will need to be conditional upon that macro being defined, so
    binaries built aren't going to be forward-compatible to other systems
    with newer glibc.  There is no good solution to solve this.


    In the meantime, document the issue and point administrators at how to
    work around the issue with a setting in `/etc/resolv.conf`


    Thanks to Viktor Dukhovni for highlighting the existence of this
    problem.
---
 doc/doc-docbook/spec.xfpt | 26 +++++++++++++++++++++++++-
 src/src/dns.c             |  2 ++
 2 files changed, 27 insertions(+), 1 deletion(-)


diff --git a/doc/doc-docbook/spec.xfpt b/doc/doc-docbook/spec.xfpt
index 0f46896..c544371 100644
--- a/doc/doc-docbook/spec.xfpt
+++ b/doc/doc-docbook/spec.xfpt
@@ -8120,7 +8120,7 @@ daemon as in the other SQL databases.

.new
.oindex &%sqlite_dbfile%&
-The preferred way of specifying the file is by using the
+The preferred way of specifying the file is by using the
&%sqlite_dbfile%& option, set to
an absolute path.
.wen
@@ -13290,6 +13290,18 @@ library, by setting:
dns_dnssec_ok = 1
.endd

+.new
+In addition, on Linux with glibc 2.31 or newer the resolver library will
+default to stripping out a successful validation status.
+This will break a previously working Exim installation.
+Provided that you do trust the resolver (ie, is on localhost) you can tell
+glibc to pass through any successful validation with a new option in
+&_/etc/resolv.conf_&:
+.code
+options trust-ad
+.endd
+.wen
+
Exim does not perform DNSSEC validation itself, instead leaving that to a
validating resolver (e.g. unbound, or bind with suitable configuration).

@@ -15418,6 +15430,18 @@ default. A value of 0 coerces DNSSEC off, a value of 1 coerces DNSSEC on.

If the resolver library does not support DNSSEC then this option has no effect.

+.new
+On Linux with glibc 2.31 or newer this is insufficient, the resolver library
+will default to stripping out a successful validation status.
+This will break a previously working Exim installation.
+Provided that you do trust the resolver (ie, is on localhost) you can tell
+glibc to pass through any successful validation with a new option in
+&_/etc/resolv.conf_&:
+.code
+options trust-ad
+.endd
+.wen
+

.option dns_ipv4_lookup main "domain list&!!" unset
.cindex "IPv6" "DNS lookup for AAAA records"
diff --git a/src/src/dns.c b/src/src/dns.c
index d036162..e13aa74 100644
--- a/src/src/dns.c
+++ b/src/src/dns.c
@@ -501,6 +501,8 @@ const uschar * auth_name;
const uschar * trusted;

if (dnsa->answerlen < 0) return FALSE;
+/* Beware that newer versions of glibc on Linux will filter out the ad bit
+unless their shiny new RES_TRUSTAD bit is set for the resolver. */
if (h->ad) return TRUE;

/* If the resolver we ask is authoritative for the domain in question, it may