DNSSEC issues

[exander77]

Checking if DNS resolvers are DNSSEC-verifying...

WARNING: It looks like the DNS resolvers configured on your system do not
verify DNSSEC, or aren't trusted (by having loopback IPs or through "options
trust-ad" in /etc/resolv.conf).  Without DNSSEC, outbound delivery with SMTP
used unprotected MX records, and SMTP STARTTLS connections cannot verify the TLS
certificate with DANE (based on a public key in DNS), and will fall back to
either MTA-STS for verification, or use "opportunistic TLS" with no certificate
verification.

Recommended action: Install unbound, a DNSSEC-verifying recursive DNS resolver,
ensure it has DNSSEC root keys (see unbound-anchor), and enable support for
"extended dns errors" (EDE, available since unbound v1.16.0). Test with
"dig com. ns" and look for "ad" (authentic data) in response "flags".

cat <<EOF >/etc/unbound/unbound.conf.d/ede.conf
server:
    ede: yes
    val-log-level: 2
EOF

NOTE: It looks like the DNS records of your domain (zone) are not DNSSEC-signed.
Mail servers that send email to your domain, or receive email from your domain,
cannot verify that the MX/SPF/DKIM/DMARC/MTA-STS records they receive are
authentic. DANE, for authenticated delivery without relying on a pool of
certificate authorities, requires DNSSEC, so will not be configured at this
time.
Recommended action: Continue now, but consider enabling DNSSEC for your domain
later at your DNS operator, and adding DANE records for protecting incoming
messages over SMTP.

Checking if outgoing smtp connections can be made by connecting to gmail.com mx on port 25... OK
Checking whether host name IPs are listed in popular DNS block lists... OK

I have Unbound installed with DNSSEC enabled.

# dig +dnssec example.com @127.0.0.1

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> +dnssec example.com @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7579
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        3600    IN  A   93.184.215.14
example.com.        3600    IN  RRSIG   A 13 2 3600 20241004193403 20240913094253 19367 example.com. i58J0XADDeC8XJTOr6N1hj/YXyp/QS8xAIKi7LnRACTJSg5BdD3kArlc uhpGjjIedmnQ+Ax/tzPGJgWzkVpmlQ==

;; Query time: 332 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Sat Sep 14 12:01:49 BST 2024
;; MSG SIZE  rcvd: 163

Btw, my domain has DNSSEC fully working.

[mjl-]

Could you try mox dns lookup a xmox.nl? It will use the same checks/logic to determine dnssec-status as the quickstart. For me it prints:

$ mox dns lookup a xmox.nl
records (1, with dnssec):
- 84.22.96.237

And what is in your /etc/resolv.conf? Your dig example is for @127.0.0.1. But after installing unbound on a typical linux system, /etc/resolv.conf may not be updated to actually use it...

[exander77]

You are correct. My system was actually checking my local DNS server and not localhost.

But weird is that my local DNS server (on my router 10.9.8.253) is running DNSSEC as well:

# dig +dnssec example.com @10.9.8.253

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> +dnssec example.com @10.9.8.253
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3131
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        3431    IN  A   93.184.215.14
example.com.        3431    IN  RRSIG   A 13 2 3600 20241004193403 20240913094253 19367 example.com. i58J0XADDeC8XJTOr6N1hj/YXyp/QS8xAIKi7LnRACTJSg5BdD3kArlc uhpGjjIedmnQ+Ax/tzPGJgWzkVpmlQ==

;; Query time: 4 msec
;; SERVER: 10.9.8.253#53(10.9.8.253) (UDP)
;; WHEN: Sat Sep 14 12:34:29 BST 2024
;; MSG SIZE  rcvd: 163

Shouldn't it work against my local DNS server as well?

[mjl-]

Shouldn't it work against my local DNS server as well?

Mox only trusts the "ad" bit in the response if the nameserver is a loopback IP, or when /etc/resolv.conf has "options trust-ad". Otherwise, it ignores the ad bit. The idea is that communication to loopback IPs should be secure enough. For public IPs (with plain UDP across the internet) it's clear it can't be trusted. For internal IPs like 10.0.0.0/8, it may be secure (e.g. over VPN), but we don't know, so cautiously don't trust communication and require "options trust-ad".

[exander77]

Makes sense. So I can reconfigure it to my local name server on the network, but have to change options trust-ad.

Thank you.

[mjl-]

Excellent, seems solved, so closing this issue. Feel free to reopen is there's work to be done.