[dns-operations] Contradictory online-signed NSEC3 denials from Akamai Edge DNS (www.shoppersdrugmart.ca)

[Travis Milum]

Hello,

While debugging resolution failures on my validating resolver
(Technitium v14/v15), I isolated a severe protocol anomaly where
Akamai Edge DNS emits flatly contradictory cryptographic proofs for
the same hostname.

I have heavily leveraged AI assistance to help parse the DNSSEC
specifications and accelerate this analysis. To eliminate the risk of
hallucinations, I have manually cross-verified every cryptographic
claim, raw hash, and packet behavior across multiple independent
diagnostic tools (dig, delv, and custom verification scripts). The
data below is fully verified. Multiple tools confirm that
www.shoppersdrugmart.ca returns signed DNSSEC records that fail strict
protocol validation because the A and HTTPS queries yield incompatible
NSEC3 maps.

Zone: shoppersdrugmart.ca (algorithm 13, NSEC3 1 0 0 -, online
signing, SOA a9-66.akam.net). Affected name: www.shoppersdrugmart.ca only.

The zone makes four signed claims about this name:

1) A query: parent-signed A RRset at the name (RRSIG by ZSK 22808,
   labels=3, validates; Google and Quad9 both serve it with AD).

2) HTTPS (TYPE65) query: NODATA, proven by an NSEC3 whose owner is the
   exact hash of the qname, with type bitmap "NS" only:

   i1pqk8g0qpc0ajvjoi8i2cuqc1d56s37.shoppersdrugmart.ca. IN NSEC3 1 0 0 -
       I1VMU2GHT898MU6OLU2IKC19Q7368E1M NS
   (RRSIG NSEC3 13 3 3600, ZSK 22808)

   Hash check (SHA-1, 0 iterations, empty salt):

   python3 -c "import hashlib,base64; print(base64.b32hexencode(
     hashlib.sha1(b'\x03www\x10shoppersdrugmart\x02ca\x00')
     .digest()).decode().lower())"
   -> i1pqk8g0qpc0ajvjoi8i2cuqc1d56s37

   An NS-only bitmap marks the name as a delegation; RFC 6840 4.4 forbids
   this NSEC3 as a non-existence proof for non-DS types. It also asserts
   the name has no A RRset, contradicting (1).

3) NS query (the one type the bitmap claims exists): fails validation.
   Quad9 returns SERVFAIL with EDE 6 (DNSSEC Bogus).

4) DS query: NODATA via the same NSEC3. For DS this proof is permitted,
   and Quad9 validates it (AD) -- i.e. "insecure delegation", which (1)
   and (3) each contradict.

The records are regenerated each day. On 2026-08-04 and
2026-08-06 each have fresh RRSIGs.

Resolver behavior on the TYPE65 denial diverges across
implementations: Technitium rejects it (correctly); Quad9 serves it
without AD; Google 8.8.8.8/8.8.4.4 varied across days but started by
sending a minimal NODATA with the authority section absent (52 bytes)
and then the next day as full proof with AD set, which RFC 6840 4.4
seems to disallow.

The operator's 13 sibling domains all CNAME www to unsigned
edgekey.net and are unaffected; this is their only in-zone-signed
hostname. I probed apex and www TYPE65 denials for all 66
DNSSEC-signed Akamai-hosted domains in the Tranco top 10k and found no
second instance.

End-user impact is currently limited (browsers fall back from TYPE65),
but Technitium's (v14) validating resolver turned this into full
unreachability by rejecting all resolutions to the domain outright.
The latest version (15.3) allows the A records through, but still logs
this as a possible attack.

Full dig outputs and the survey script are available on request.

I haven't submitted a support ticket to the Shoppersdrugmart.ca
website as I highly doubt this would gain traction there. It seems
like the right target would be Akamai, but I have no idea how to
notify them.

Regards,
Travis