Hi fiwswe,
The error message “The TTL of the RRset (3600) exceeds the value of the Original TTL field of the RRSIG RR covering it (300).” is incorrect: I checked the zonefile for desec.org, and the TTLs of all non-RRSIG records are identical to the original TTL field of the corresponding RRSIG record.
It is the case, however, that our TTLs for the non-existence proof records (NSEC3 records) do not strictly conform to RFC 5155 Sec. 7.1, which states that
The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL value field in the zone SOA RR.
The SOA minimum TTL value is the last field of the SOA record. This value would be 3600 in the case at hand.
At the same time, RFC 4034 Sec. 4 states that
The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL field. This is in the spirit of negative caching ([RFC2308]).
The problem is that the “spirit of negative chaching” would lead to a different conclusion, namely to use the smaller of the SOA minimum TTL field and the SOA TTL itself (RFC 2308 Sec. 3). The former in our case is 3600, while the latter is 300. It may be that the DNSViz error message is due to the fact that our NSEC3 TTLs are the minimum of these two (300) and not simply the former (3600).
PowerDNS developers have decided to honor the “spirit of negative caching” (RFC 2308) over the word of RFC 5155, so that non-existence proofs are cached the same way as non-DNSSEC negative answers. This is because the literal approach leads to an undesirable coupling of the NSEC(3) TTL with other, more stable records, such as DNSKEY and NSEC3PARAM, or CDS and CDNSKEY. For details, please see the corresponding section in the PowerDNS documentation.
In any case, making this choice is “legal” in the RFC sense, as the specifications quoted above are SHOULD phrases (as opposed to MUST, i.e. they can be disregarded for a good reason).
I’m not sure what the issue is: As you observed yourself, your dig output does contain an NSEC3 record. This will always be the case when you ask for something that does not exist.
You are right that *.desec.org is a wildcard record. That’s why you get a non-existence proof if you ask for a specific subdomain, plus the record values configured at the wildcard. The reason you get the non-existence proof is to provide evidence of the fact that there is no additional record with the qname that would override the wildcard. You can try that by querying an A record for ns2.desec.org, which is explicitly configured and thus overrides the wildcard – so you get it returned without a non-existence proof.
Does that make sense?
Stay secure,
Peter