MX lookup fails with "DNSSEC validation failed" for an insecure third-level delegation under an NSEC3 opt-out TLD (v0.16.23)

blaluc · September 24, 2026, 1:27pm

Issue Description

Outbound delivery to port.venice.it fails at the MX lookup stage with a DNSSEC validation error, even though the zone is legitimately unsigned (insecure) and validates correctly with standard tools.

The failure persists with DANE disabled globally, so the validation seems to be applied to the MX lookup itself.

The bounce received by the sender reads:

(failed to lookup 'port.venice.it': DNS resolution error: DNS error: DNSSEC validation failed)

Other .it second-level domains are delivered without problems.

Stalwart version: v0.16.23
Deployment: Docker
DNS resolver: Cloudflare DNS with TLS (also reproduced with the system resolver)
EDNS enabled, Try TCP on Error enabled

Workaround

A static relay route for port.venice.it pointing to port-venice-it.mail.protection.outlook.com:25 (STARTTLS) bypasses the MX lookup and delivery works.

Expected Behavior

The MX lookup should succeed with an insecure (unsigned) result, and the message should be delivered to port-venice-it.mail.protection.outlook.com.

Actual Behavior

Outbound delivery to port.venice.it fails at the MX lookup stage with a DNSSEC validation error, even though the zone is legitimately unsigned (insecure) and validates correctly with standard tools.

Reproduction Steps

Configure any resolver type (e.g. Cloudflare with TLS).
Send a message to any address at port.venice.it.
Delivery fails with delivery.mx-lookup-failed / DNSSEC validation failed.

Relevant Log Output

INFO MX record lookup failed (delivery.mx-lookup-failed) queueName = "remote", from = "[email protected]", to = ["[email protected]"], 
domain = "port.venice.it", causedBy = DNS error (mail-auth.dns-error) { details = "DNS error: DNSSEC validation failed" }, elapsed = 168ms

Stalwart Version

v0.16.x

Installation Method

Docker

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

Additional Context

Validation with standard tools

BIND’s delv (full validation from the root) correctly reports the answer as insecure, both from the host and from a container on the same Docker network querying Cloudflare:

$ delv @1.1.1.1 port.venice.it MX
; unsigned answer
port.venice.it.  3600  IN  MX  0 port-venice-it.mail.protection.outlook.com.

Google Public DNS (validating) returns NOERROR without the ad flag, as expected for an insecure zone.

DNS structure (likely root cause)

venice.it is not a separate zone: port.venice.it is delegated directly from the .it registry to its authoritative servers (ns033.name.cloud.ibm.com, ns176.name.cloud.ibm.com).

The DS query for port.venice.it is answered by the .it servers with an NSEC3 closest encloser proof where:

the closest encloser is the TLD apex it itself;
the next closer name (venice.it) is covered by an NSEC3 record with the opt-out flag set.

$ dig +dnssec DS port.venice.it @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; AUTHORITY SECTION:
it.  3600  IN  SOA  dns.nic.it. hostmaster.nic.it. 2026092414 10800 900 604800 3600
it.  3600  IN  RRSIG  SOA 13 1 3600 20261024110329 20260924110329 53706 it. ...
6EQIAO6UF3HPKVP4A8704T8QV4NV63RL.it. 3600 IN NSEC3 1 1 0 - 6ERRV534H8JG5VFJ7B5IG4SMVMTKVGOA NS DS RRSIG
6EQIAO6UF3HPKVP4A8704T8QV4NV63RL.it. 3600 IN RRSIG NSEC3 13 2 3600 20261024110329 20260924110329 53706 it. ...
RS1N3N7M54PDEM5EUNV9NPKH3B6CGPJC.it. 3600 IN NSEC3 1 1 0 - RS1PG43S35R5V1KF1V10FT5SP409IUBV NS SOA RRSIG DNSKEY NSEC3PARAM
RS1N3N7M54PDEM5EUNV9NPKH3B6CGPJC.it. 3600 IN RRSIG NSEC3 13 2 3600 20261024110329 20260924110329 53706 it. ...

Per RFC 5155 (section 8.6), this is a valid proof of an insecure delegation. My guess is that the validator used by Stalwart (hickory-dns) does not handle the case where the closest encloser is two labels above the queried name within an opt-out span, and returns “bogus” instead of “insecure”.

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

helpbot · September 24, 2026, 1:27pm

This isn’t covered in the current docs. A community member or staff member will follow up.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

stalwart · September 24, 2026, 6:13pm

Please track these two hickory bugs:

github.com/hickory-dns/hickory-dns

DNSSEC "exceeded max validation depth" after upgrading to 0.26.3

opened 12:33PM - 19 Sep 26 UTC

kevincox

**Describe the bug** Resolution fails with "DNS error: DNSSEC validation failed"…. An error is also logged from hickory_net::dnssec with "exceeded max validation depth". **To Reproduce** Upgrade from 0.26.1 to 0.26.3 **Expected behavior** DNS resolution continues to work. **System:** - OS: Linux - Architecture: x86_64 - Version - rustc version: ? **Version:** Crate: resolver and dependencies. Version: 0.26.3 **Additional context** I am still looking into this issue and will update. I mostly filed this so that others encountering the same issue can help investigate. Quite possibly this is a configuration issue on my end but the configuration wasn't changed as part of the update. ~~So far I am only seeing this error on `.com` domains that **don't** support DNSSEC. (Mostly Google domains)~~ but that may just be based on the distribution of domains that our service resolves.

github.com/hickory-dns/hickory-dns

DNSSEC: NSEC3 opt-out DS denial is treated as Bogus when the next closer name is not QNAME

opened 06:10PM - 24 Sep 26 UTC

mdecimus

**Describe the bug** A validating lookup of a name in an insecure zone fails wi…th `DnsError::DnssecBogus` when that zone is delegated two or more labels below the closest encloser in an NSEC3 opt-out parent zone. The parent's DS NODATA answer is a valid RFC 5155 section 8.6 proof, but hickory only looks for an opt-out NSEC3 covering H(QNAME) and never for the one covering the next closer name. A live example is `port.venice.it`, which is delegated directly from `it.`. `venice.it` is not a zone and has no NSEC3 record of its own: it is an empty non-terminal that exists only because of an insecure delegation inside an opt-out span, and RFC 5155 section 7.1 allows it to be left out. The `it.` servers answer `DS port.venice.it` with this authority section (RRSIGs omitted): ``` it. 3600 IN SOA dns.nic.it. hostmaster.nic.it. 2026092417 10800 900 604800 3600 RS1N3N7M54PDEM5EUNV9NPKH3B6CGPJC.it. 3600 IN NSEC3 1 1 0 - RS1PG43S35R5V1KF1V10FT5SP409IUBV NS SOA RRSIG DNSKEY NSEC3PARAM 6EQIAO6UF3HPKVP4A8704T8QV4NV63RL.it. 3600 IN NSEC3 1 1 0 - 6ERRV534H8JG5VFJ7B5IG4SMVMTKVGOA NS DS RRSIG ``` With an empty salt and 0 iterations the hashes are: | Name | H(name) | In the response | |---|---|---| | `it.` (closest encloser) | `RS1N3N7M54PDEM5EUNV9NPKH3B6CGPJC` | matched by the apex NSEC3 | | `venice.it.` (next closer) | `6ERNUJ3UKNAC1SIO0BB8OPAM3QSHJC7T` | covered by `6EQIAO6U...`, Opt-Out set | | `port.venice.it.` (QNAME) | `IE297EM4H4IQ0305K7H1ED4AQNHRBJUU` | neither matched nor covered | That is a closest provable encloser proof plus an opt-out NSEC3 covering the next closer name, which is exactly what section 8.6 requires when no NSEC3 matches QNAME. The user who ran into this confirmed with BIND's `delv @1.1.1.1 port.venice.it MX` that the answer validates as unsigned, and both 1.1.1.1 and 8.8.8.8 return NOERROR without AD for it. `comune.venezia.it`, an ordinary insecure delegation one label below `it.`, validates fine because its next closer name is QNAME itself. **To Reproduce** ```toml [dependencies] hickory-resolver = { version = "0.26.3", features = ["dnssec-aws-lc-rs"] } tokio = { version = "1", features = ["full"] } tracing-subscriber = { version = "0.3", features = ["env-filter"] } ``` ```rust use hickory_resolver::{ TokioResolver, config::{CLOUDFLARE, ResolverConfig, ResolverOpts}, net::runtime::TokioRuntimeProvider, }; #[tokio::main] async fn main() { tracing_subscriber::fmt() .with_env_filter("hickory_net::dnssec=debug") .without_time() .with_ansi(false) .init(); let mut opts = ResolverOpts::default(); opts.validate = true; opts.num_concurrent_reqs = 1; let resolver = TokioResolver::builder_with_config( ResolverConfig::udp_and_tcp(&CLOUDFLARE), TokioRuntimeProvider::default(), ) .with_options(opts) .build() .unwrap(); for name in ["port.venice.it.", "comune.venezia.it."] { match resolver.mx_lookup(name).await { Ok(lookup) => lookup .answers() .iter() .for_each(|r| println!("{name} {} {}", r.data, r.proof)), Err(err) => println!("{name} error: {err:?}"), } } } ``` `num_concurrent_reqs = 1` only keeps an unrelated failure out of the way: with the default, one of my runs failed earlier on the root DNSKEY fetch with "response was truncated; TCP already tried or no other transport available", which looks like #3963. Relevant output, identical over three runs: ``` DEBUG hickory_net::dnssec: nsec3 proof for port.venice.it., returning Bogus: no valid servicing wildcard proof DEBUG hickory_net::dnssec: returning Nsec error for port.venice.it. Bogus DEBUG hickory_net::dnssec: failed to verify: port.venice.it. record_type: MX: communication failure for query: port.venice.it. IN DS: DNS error: DNSSEC Negative Record Response for port.venice.it. IN DS, Bogus port.venice.it. error: Dns(DnssecBogus) DEBUG hickory_net::dnssec: nsec3 proof for comune.venezia.it., returning Secure: DS query covered by opt-out proof comune.venezia.it. 5 venis01.esvacloud.com. Insecure comune.venezia.it. 5 venis02.esvacloud.com. Insecure ``` **Expected behavior** The MX lookup for `port.venice.it` succeeds and the records carry `Proof::Insecure`. **Suggested fix** Disclaimer: Fix proposed by Claude Opus 5.5, against main at f486d9e: ```diff @@ -220,7 +220,18 @@ pub(super) fn verify_nsec3_insecure_delegation(zone: &Name, nsec3s: &[(&Name, &N return info.nsec3_data.opt_out(); } - false + let Some(parent) = records.first().map(|record| &record.zone_name) else { + return false; + }; + if records.iter().any(|record| &record.zone_name != parent) { + return false; + } + let Ok(cx) = Context::new(&query, Some(parent), &records) else { + return false; + }; + cx.closest_encloser_proof() + .next_closer + .is_some_and(|(_, record)| record.nsec3_data.opt_out()) } /// Convert pairs of record names and NSEC3 RDATA to structures containing hashed record names, zone @@ -425,6 +436,18 @@ fn validate_nodata_response( return cx.proof(Proof::Secure, "DS query covered by opt-out proof"); } + if query_type == RecordType::DS + && cx + .closest_encloser_proof() + .next_closer + .is_some_and(|(_, record)| record.nsec3_data.opt_out()) + { + return cx.proof( + Proof::Secure, + "DS query next closer covered by opt-out proof", + ); + } + let (proof, reason) = match wildcard_encloser_num_labels { // Case 4: // Name is serviced by wildcard that has a record of this type ``` `verify_nsec3_insecure_delegation` has no SOA to work from, so the patch bounds the encloser walk with the parent of the NSEC3 owner names and gives up if they disagree. The change does not accept anything RFC 5155 rejects. `closest_encloser_proof()` already refuses an ancestor-delegation NSEC3 as the closest encloser (RFC 5155 section 8.3, RFC 6840 section 4.1). In a correctly signed zone no existing name falls inside an NSEC3 span, and section 7.1 requires the empty non-terminal above a signed delegation to have its own NSEC3, so without forged signatures this proof cannot be produced for a delegation that has a DS. With the patch applied to main, `cargo test -p hickory-net --features dnssec-aws-lc-rs --lib dnssec::` passes, 31 tests including the new one. The same patch on 0.26.3 makes the program above return `Insecure` for `port.venice.it`, and `comune.venezia.it`, `gmail.com` and `example.com` resolve with the same proofs as before. I can send it as a PR together with the test. **System:** - OS: macOS 26.6.2 (also seen on Linux in Docker by the user who reported it) - Architecture: arm64 - rustc version: 1.98.1 **Version:** Crate: hickory-net, hickory-resolver Version: 0.26.3, and main at f486d9e

Massimo_di_Gregorio · October 6, 2026, 10:19am

Same issue here on v0.16.24 (binary, Debian 12), System resolver, DANE disabled on the default TLS strategy (also after “Reload server settings” + “Invalidate all caches”).

It affects Italian municipalities using the standard comune...it naming, e.g. comune.casalattico.fr.it: “it.” uses NSEC3 opt-out, fr.it and casalattico.fr.it are empty non-terminals in the “it.” zone, and comune.casalattico.fr.it is an unsigned delegation directly from “it.”. delv reports “unsigned answer”; a manual SMTP session to the MX is accepted up to RCPT TO.

Packet capture during a retry: MX? → NS? → DS? (NOERROR, NSEC3 proof) → no A/AAAA query, attempt aborted.

Since thousands of Italian municipalities use this naming scheme, outbound mail to a large share of Italian public administrations is stuck. Any ETA for the hickory fix, or a way to skip DNSSEC validation on MX/IP lookups when DANE is disabled? Thanks!

mdecimus · October 6, 2026, 11:26am

Disabling DANE validation from settings is the only solution until hickory releases the fix.

stalwart · October 11, 2026, 3:49pm

Hi everyone,

This is an update on the DNSSEC and DANE delivery failures reported across several threads here. They come from bugs in hickory, the DNS library Stalwart uses to validate DNSSEC, and each one now has a fix submitted upstream:

Google Workspace MX hosts (aspmx.l.google.com and the altN hosts) failing with “exceeded max validation depth”: hickory#3974, fixed in #3976 and #4007. Both are merged but not yet in a hickory release.
Domains delegated two or more labels below an NSEC3 opt-out zone, such as port.venice.it and the comune.*.fr.it municipality domains: hickory#3985, fix in #4001.
Unsigned zones without an NS record at their apex, for example akokan.pl: hickory#4027, fix in #4028.
Microsoft 365 hosts (*.mail.protection.outlook.com) failing when the upstream resolver answers SERVFAIL for them, which Google Public DNS and many local resolvers do: hickory#4063, fix in #4064.
Truncated UDP responses never retried over TCP when several name servers are queried at the same time: hickory#3963, fix in #4062.
Valid answers rejected because the response also carries an unrelated NSEC record, plus some correctly signed wildcard answers rejected: hickory#4047, fix in #4055.
Validating queries sent without the CD bit, which makes a validating upstream resolver answer SERVFAIL: hickory#3966, fix in #4014 and #4036.

DANE delivery has been broken for some of you for weeks now, and the hickory maintainers seem to be busy at the moment, so most of these PRs are still waiting for review. We have forked hickory at stalwartlabs/hickory-dns with all of the fixes above applied, and Stalwart will build against that fork until hickory publishes a release that contains all of them. We ran the patched resolver against every domain reported in these threads, with Cloudflare, Google and Quad9 as upstream resolvers, and they all validate correctly now.

v0.16.26 ships with the patched resolver and will be out today or tomorrow. After upgrading you can remove any TLS strategy you added to turn DANE off for specific domains. If a domain still fails after the upgrade, post it in this thread together with the DNS resolver you use and we’ll look into it.

velidtf · October 14, 2026, 9:03am

Still happening on v0.16.26 for unsigned domains under .aero (an NSEC3 opt-out TLD).

Setup: v0.16.26 in Docker, DNS resolver set to "System".

Outbound delivery to an unsigned .aero domain fails at the MX lookup on every retry:

  delivery.mx-lookup-failed ... causedBy = DNS error (mail-auth.dns-error) { details = "DNS error: DNSSEC validation failed" }

The domain is legitimately unsigned (no DS in aero.; aero. uses NSEC3 with opt-out, NSEC3PARAM 1 0 0 73).
delv returns "; unsigned answer" with the correct MX, and public resolvers (1.1.1.1, 8.8.8.8) answer normally.
In the same instance, TXT lookups for that domain (SPF/DKIM/DMARC) succeed; only the outbound MX lookup fails.
Delivery to .com domains works.

This looks like the hickory NSEC3 opt-out issue (hickory-dns #3985 / PR #4001) is not yet covered for .aero
in the resolver shipped with 0.16.26.

Workaround: a static Relay route per affected domain. I can share the domain privately if needed for testing.

stalwart · October 15, 2026, 1:30pm

@velidtf I ran the patched resolver from 0.16.26 against sita.aero and emirates.aero, both unsigned delegations straight from aero., with Cloudflare, Google and Quad9 upstream. All three come back insecure and the MX lookup succeeds, so .aero opt-out by itself isn’t the problem any more.

Since TXT works for your domain and MX doesn’t, I suspect something specific to its MX answer, so yes, please send me the domain in a private message (or to [email protected]). Please also include the contents of /etc/resolv.conf inside the container and what the host itself resolves through (systemd-resolved, the router, Pi-hole…). With “System” in Docker, queries go to Docker’s embedded DNS at 127.0.0.11, which forwards to whatever the host uses, and some of those don’t handle DNSSEC well. Switching the resolver to Cloudflare or Quad9 for a test would tell us quickly whether it’s the upstream.

A TLS strategy with DANE disabled for those domains gets the mail out with less setup than a relay route per domain, because the MX lookup is only validated when DANE is on.

Topic		Replies	Views
MX lookup fails with "DNSSEC validation failed" for signed zone (mail.de, RSA/SHA-512) on 0.16.21, regardless of DANE setting Issues	13	388	October 11, 2026
Outbound: "DNSSEC validation failed" on MX host lookup when the recipient domain is signed but its MX hosts are in an unsigned zone (Google Workspace). Still present in 0.16.24 Issues	4	120	October 12, 2026
Transmission problem to outlook.com Questions	20	336	October 11, 2026
Outbound delivery to all .org and .io recipients stalls with "DNSSEC validation failed" Issues no-ai	1	117	September 18, 2026
Outbound delivery to .aero / .org / .email fails with "DNSSEC validation failed" — follow-up to #3316 (still present in v0.16.22) Issues	2	14	October 16, 2026