[dns-operations] broken 'apex' NSEC3 for ma. denies big number of delegated names

[Patrik Wallstrom]

.ma has changed the NSEC3 salt at least once between the reports, so something is happening. But the NSEC3 records still points to the wrong records, and this bad gap is for like half of the delegations. Which is of course bad.

So no, it is not a problem with the SOA serials, nor the opt-out. I also have no problems with IPv6.

https://gonemaster.evilbit.de/result/NnMCgAgOIkxs

/ Patrik

On Mon, 05 Oct 2026, Winfried via dns-operations wrote:

>From: Winfried <walists at mailbox.org>
>Date: Mon, 5 Oct 2026 15:02:22 +0200
>To: dns-operations at lists.dns-oarc.net
>Subject: Re: [dns-operations] broken 'apex' NSEC3 for ma. denies big number
> of delegated names
>User-Agent: Mozilla Thunderbird
>
>Hello,
>
>This problem has recurred (or still persists).
>
>We are seeing repeated NXDOMAIN responses for names that appear to 
>exist in the ma. zone. This does not seem to affect just one name. The 
>signed NSEC3 data in NXDOMAIN responses can cover the hash of an 
>existing name. Resolvers using aggressive NSEC caching may then use 
>that data to generate further NXDOMAIN responses.
>
>One example is bankalmaghrib.ma.:
>
>- For a query for horizonalmaz.ma. A, authoritative nameservers return 
>a signed NSEC3 record covering the range MFB8... → 4TEST... This range 
>includes the hash of bankalmaghrib.ma. (QH1M...).
>- A direct query for bankalmaghrib.ma. NS returns the delegation to 
>four Azure DNS nameservers. It also returns an NSEC3 record for the 
>exact hash QH1M..., listing the NS record type.
>- A resolver cached the first NSEC3 proof while processing 
>horizonalmaz.ma. A, then used it to generate an NXDOMAIN response for 
>bankalmaghrib.ma. SOA.
>
>During our tests, the SOA serial numbers differed between 
>authoritative 'ma.' nameservers. This may indicate that they are 
>serving different versions of the ma. zone and could be related to the 
>inconsistent NSEC3 responses.
>
>As a separate observation, some ma. nameservers (a.tld.ma, b.tld.ma, 
>c.tld.ma, d.tld.ma) are not reachable over IPv6, although their names 
>have AAAA records. But that's not the main issue.
>
>We have already sent a report to ma at anrt.ma. No response so far. Does 
>anyone happen to know a better contact?
>
>Kind regards,
>Winfried
>
>>Hello,
>>
>>"dig +dnssec txt @b.tld.ma ma." (as do other queries) returns a non-
>>opt-out NSEC3 covering
>>EPNGG6KIP1BA66LLJKNBLULI9PUL8OJ9...LB0AJ7AEMMSB3B556MI0DC1GFDUGO17E.
>>This NSEC3 covers a large number of existing delegations in the zone,
>>denying their existence.
>>
>>Resolvers using NSEC/NSEC3 aggressively (as described in RFC9077) then
>>end up replying NXDOMAIN for names covered by that range.
>>
>>One example of such a name is afmagroup.ma, which hashes to
>>EUKB329VQPC6CRF4VLLEB9BALQU169UO, falling inside the EPN..LB0 range.
>>
>>I suspect your signer is broken. The offending NSEC3 is returned by all
>>.ma name servers I can find.
>>
>>Can you please investigate? Thank you!
>>
>>Kind regards,
>>-- 
>>Peter van Dijk
>>PowerDNS.COM BV -https://www.powerdns.com/
>>

>_______________________________________________
>dns-operations mailing list
>dns-operations at lists.dns-oarc.net
>https://lists.dns-oarc.net/mailman/listinfo/dns-operations