v15.4: DNSSEC validator returns RRSIGs Missing for unsigned apex CNAME despite authenticated absence of DS

v15.4: DNSSEC validator returns RRSIGs Missing for unsigned apex CNAME despite authenticated absence of DS

Environment

• Technitium DNS Server: 15.4
• OS: Ubuntu 24.04.5 LTS
• Kernel: 7.0.0-31-generic
• .NET runtime: 10.0.12
• DNSSEC validation: enabled
• Forwarding mode: Google Public DNS over DoH
• Forwarders:
  • https://dns.google/dns-query (8.8.8.8)
  • https://dns.google/dns-query (8.8.4.4)
• Concurrent forwarding: enabled
• Reproduced on two independent Technitium DNS Server instances with the same configuration

Summary

Technitium 15.4 consistently returns SERVFAIL for belorast.com with:

EDE: 10 (RRSIGs Missing): (Attack detected! belorast.com/CNAME)

However:

1. The .com parent has no DS record for belorast.com, and returns signed NSEC3 proof of the absence of DS.
2. Therefore belorast.com is an insecure / unsigned delegation.
3. Google Public DNS, Cloudflare, and Quad9 all return NOERROR for the same query.
4. The same Technitium instance returns NOERROR immediately when the query is sent with CD=1.
5. Both authoritative servers return the same unsigned CNAME.
6. The issue reproduces identically on two separate Technitium 15.4 servers.

The authoritative zone itself is malformed/unusual: belorast.com publishes a CNAME at the zone apex while also publishing SOA and NS records at the same owner name.

I understand Technitium may choose to reject malformed DNS data. My concern is specifically the DNSSEC result: since the .com parent proves there is no DS for belorast.com, it appears that an unsigned belorast.com/CNAME should not be rejected specifically because its RRSIG is missing.

Reproduction

1. Query through Technitium with DNSSEC validation enabled

dig @127.0.0.1 belorast.com A +dnssec +comments

Result:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL

; EDE: 10 (RRSIGs Missing): (Attack detected! belorast.com/CNAME)

This is reproducible on both Technitium servers.

2. Same query with checking disabled

dig @127.0.0.1 belorast.com A +dnssec +cd +comments

Result:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR

belorast.com.           847     IN      CNAME   dvesca0tmeg5m.cloudfront.net.
dvesca0tmeg5m.cloudfront.net. 60 IN     A       13.249.74.8
dvesca0tmeg5m.cloudfront.net. 60 IN     A       13.249.74.82
dvesca0tmeg5m.cloudfront.net. 60 IN     A       13.249.74.125
dvesca0tmeg5m.cloudfront.net. 60 IN     A       13.249.74.91

So the forwarded response itself is usable; the SERVFAIL is introduced when Technitium performs DNSSEC validation.

3. Verify that the .com parent has no DS

COMNS=$(dig +short NS com. | head -1)
dig @"$COMNS" belorast.com DS +dnssec +norecurse +comments

Result:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr aa
;; ANSWER: 0

The authority section contains signed NSEC3 records proving the absence of a DS record.

The parent delegation is:

belorast.com. 172800 IN NS dns1.registrar-servers.com.
belorast.com. 172800 IN NS dns2.registrar-servers.com.

Thus the child should be treated as an insecure / unsigned delegation.

4. Query the authoritative servers directly

for ns in dns1.registrar-servers.com dns2.registrar-servers.com
do
    dig @"$ns" belorast.com SOA   +dnssec +norecurse +comments
    dig @"$ns" belorast.com NS    +dnssec +norecurse +comments
    dig @"$ns" belorast.com CNAME +dnssec +norecurse +comments
    dig @"$ns" belorast.com A     +dnssec +norecurse +comments
done

Both authoritative servers return the same data.

SOA:

belorast.com. IN SOA dns1.registrar-servers.com. hostmaster.registrar-servers.com. ...

NS:

belorast.com. IN NS dns1.registrar-servers.com.
belorast.com. IN NS dns2.registrar-servers.com.

CNAME:

belorast.com. IN CNAME dvesca0tmeg5m.cloudfront.net.

The CNAME is returned without an RRSIG.

I understand that this authoritative configuration is malformed because the CNAME coexists with SOA/NS data at the same owner name.

5. Google raw response with CD=1

for t in CNAME A AAAA HTTPS
do
    dig @8.8.8.8 belorast.com "$t" +dnssec +cd +comments
done

Google returns NOERROR for all tested types.

Example:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra cd

belorast.com. IN CNAME dvesca0tmeg5m.cloudfront.net.

The CNAME has no RRSIG.

6. Compare major validating public resolvers

for r in 1.1.1.1 8.8.8.8 9.9.9.9
do
    echo "===== $r ====="
    dig @"$r" belorast.com A +dnssec +comments
done

All three return NOERROR:

Cloudflare 1.1.1.1 -> NOERROR
Google     8.8.8.8 -> NOERROR
Quad9      9.9.9.9 -> NOERROR
Technitium          -> SERVFAIL / RRSIGs Missing

None of the public-resolver responses sets the AD flag, which is consistent with treating the answer as insecure rather than DNSSEC-authenticated.

7. Reproduced on a second Technitium server

On a separate Technitium 15.4 instance:

dig @127.0.0.1 belorast.com A +dnssec +comments

Result:

status: SERVFAIL

EDE: 10 (RRSIGs Missing): (Attack detected! belorast.com/CNAME)

Immediately followed by:

dig @127.0.0.1 belorast.com A +dnssec +cd +comments

Result:

status: NOERROR

belorast.com. IN CNAME dvesca0tmeg5m.cloudfront.net.
...

So this does not appear to be stale state or cache corruption on a single server.

Expected behavior

Since the .com parent provides authenticated proof that there is no DS for belorast.com, I would expect Technitium to classify the child as an insecure delegation.

An unsigned CNAME below that insecure delegation should therefore not fail specifically because its RRSIG is missing.

Possible expected behavior would be either:

• return the unsigned response as NOERROR, similar to Google, Cloudflare, and Quad9; or
• if Technitium intentionally rejects the malformed apex-CNAME configuration, return an error reflecting malformed DNS data rather than a DNSSEC missing-RRSIG attack.

Actual behavior

Technitium returns:

SERVFAIL
EDE: 10 (RRSIGs Missing): (Attack detected! belorast.com/CNAME)

The same validation failure is seen for queries such as A, AAAA, HTTPS, CNAME, DS, and DNSKEY involving this name.

With CD=1, the same server returns the answer successfully.

Related issues

This may be related to several previous reports:

• #2003 - DNSSEC validation failed in Forwarders mode
  https://github.com/TechnitiumSoftware/DnsServer/issues/2003

  This is particularly relevant because it reports the same missing RRSIG ... /CNAME class of failure in forwarder mode. The maintainer stated that the issue was fixed in the development code and released in v15.3. This report reproduces consistently on v15.4.

• #2090 - DNSSEC: DS query goes to the child's own nameservers when following a cross-zone CNAME
  https://github.com/TechnitiumSoftware/DnsServer/issues/2090

  This is an open v15.4 issue involving incorrect DS handling while following CNAMEs. It may or may not share the same underlying cause.

• #1828 - Attack detected! DNSSEC validation failed due to missing RRSIG for owner name: .../CNAME
  https://github.com/TechnitiumSoftware/DnsServer/issues/1828

• #1068 - When using Forwarders, the initial resolution of a CNAME record with DNSSEC may fail
  https://github.com/TechnitiumSoftware/DnsServer/issues/1068

• #1002 - Error "DNSSEC validation failed due to missing RRSIG for owner name"
  https://github.com/TechnitiumSoftware/DnsServer/issues/1002

• #890 - Random DNSSEC errors after 12.1 update
  https://github.com/TechnitiumSoftware/DnsServer/issues/890

The older issues were generally intermittent and often attributed to upstream resolvers occasionally omitting required RRSIG records.

This case appears different because:

• it is consistently reproducible;
• it reproduces on two independent Technitium 15.4 servers;
• Google DNS is the configured forwarder;
• Google, Cloudflare, and Quad9 all return NOERROR;
• the .com parent provides authenticated proof that there is no DS;
• the affected domain is public and can be tested directly;
• CD=1 immediately changes Technitium's result from SERVFAIL to NOERROR.

Question

Could you confirm whether this behavior is expected for an insecure delegation containing a malformed apex CNAME?

Specifically, should Technitium classify belorast.com/CNAME as requiring an RRSIG after the .com parent has authenticated that no DS exists for belorast.com, or is this a DNSSEC validation edge case in v15.4?