NSEC3 TTL errors?


While testing deSEC Managed DNS hosting with a domain I noticed that DNSViz shows some errors related to NSEC3 TTLs. I checked this with your domain desec.org and similar errors where detected:

• RRSIG NSEC3 proving non-existence of 91grntqly6.desec.org/A alg 13, id 6697: The TTL of the RRset (3600) exceeds the value of the Original TTL field of the RRSIG RR covering it (300).
• RRSIG NSEC3 proving non-existence of desec.org/CNAME alg 13, id 6697: The TTL of the RRset (3600) exceeds the value of the Original TTL field of the RRSIG RR covering it (300).

Is this an error with DNSViz or is deSEC doing something wrong?

Note: It is not easy to check NSEC3 RRs using normal tools like dig(1). I tried the following but saw no TTL inconsistencies:

$ dig +dnssec +multi @ns1.desec.io _no_such_subdomain.desec.org A

; <<>> DiG 9.8.3-P1 <<>> +dnssec +multi @ns1.desec.io _no_such_subdomain.desec.org A
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52806
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags: do; udp: 1232
;_no_such_subdomain.desec.org. IN A

_no_such_subdomain.desec.org. 3600 IN RRSIG A 13 2 3600 20201126000000 (
				20201105000000 6697 desec.org.
				iriOKqL7fyzgbyKUqXBEusfHuwfL7KFRYJnW9GyHoA== )
_no_such_subdomain.desec.org. 3600 IN A

dtcqnj8ttpd5ssq8lit9lv3f9pul2hkg.desec.org. 3600 IN NSEC3 1 0 127 A34673C73342DA53 J7V5VHNN5R6P5OIOLLCUHIA31E1F0KTP A RRSIG
dtcqnj8ttpd5ssq8lit9lv3f9pul2hkg.desec.org. 3600 IN RRSIG NSEC3 13 3 300 20201126000000 (
				20201105000000 6697 desec.org.
				A4pnxB0nE2cusqUyGe0rl5xRv1aC1NQAzz8qB2JfWw== )

;; Query time: 19 msec
;; WHEN: Wed Nov 18 16:19:46 2020
;; MSG SIZE  rcvd: 370


(It seems there is a wildcard entry for desec.org A as no matter what subdomain I use I always get the answer But the authority section shows an NSEC3 record and its RRSIG at least.)

BTW: If someone knows a good way to directly read NSEC3 records (and the RRSIG NSEC3) I’d be grateful for a hint :wink:



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,

Hi Peter!

Thanks for the quick and in-depth reply!

Hmm, NSEC ≠ NSEC3. But as their purpose is essentially the same I can understand why this NSEC related comment is applied to NSEC3.

Thanks for the explanation! I’ll ignore these errors at DNSViz, but I will not be asking them for a fix at their end either as strictly speaking they seem to be correct in flagging this.

True, but usually only the operators of authoritative DNS servers have access to the zone files. And as I am developing a DNSSEC monitoring script, I would love to be able to directly list and query all NSEC3 records (and their RRSIGs). I do admit that despite reading RFC 5155 Sec. 3 I do not fully understand how the NSEC3 records are generated (in particular how the cryptic subdomain is generated). I know, that’s probably the point — to prevent leaking information as is the case with NSEC records. But still…

Yes it does. Thanks.


Hi fiwswe,

What’s more: When RFC 4034 (which refers to NSEC) was written, NSEC3 did not exist yet. It was only introduced by RFC 5155, which essentially copied the prescription from the NSEC specs. It would not be reasonable to treat NSEC and NSEC3 differently in that regard, as the objective of NSEC3 is to prevent enumeration, but not alter caching characteristics.

DNSViz also has a warning category. Given that the pertinent RFC prescriptions are SHOULD, not MUST, I’d say that it’s a bug to flag such configuration as an error and not as a warning. – Keep in mind that I was merely suspecting that the circumstances explained above are at the reason for the DNSViz finding. It may also be due to something else, although I would be clueless as to what that could be.

The subdomains essentially are hashes of subdomains that do exist. As you don’t know which ones those are, you can’t enumerate them. So, I’m afraid there is no straightforward way for doing that. DNS is not intended to be enumerated (and upon the introduction of DNSSEC without NSEC3, some considered the enumerability introduced by NSEC a major showstopper).

Stay secure,