<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello,</p>
    <p>This problem has recurred (or still persists).</p>
    <p>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.</p>
    <p>One example is bankalmaghrib.ma.:<br>
      <br>
      - 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...).<br>
      - 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.<br>
      - A resolver cached the first NSEC3 proof while processing
      horizonalmaz.ma. A, then used it to generate an NXDOMAIN response
      for bankalmaghrib.ma. SOA.<br>
      <br>
      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.<br>
      <br>
      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.</p>
    <p>We have already sent a report to <a class="moz-txt-link-abbreviated" href="mailto:ma@anrt.ma">ma@anrt.ma</a>. No response so far.
      Does anyone happen to know a better contact?<br>
      <br>
      Kind regards,<br>
      Winfried<br>
      <br>
      <blockquote type="cite">
        <pre>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 - <a href="https://www.powerdns.com/"
        class="moz-txt-link-freetext">https://www.powerdns.com/</a>

</pre>
      </blockquote>
    </p>
  </body>
</html>