powerdns / draft-dnsop-nsec-ttl Goto Github PK

https://mailarchive.ietf.org/arch/msg/dnsop/rUPpYxd_fHv0Ee-XtzX-6OSFAQU

Benjamin wrote:

| A signer MAY cause the TTL of the NSEC RR to have a
| deviating value after the SOA record has been updated, to allow
| for an incremental update of the NSEC chain.

I don't think I understand what a "deviating value" would be (and in
which direction it would deviate).

This sentence was added because some implementations may need time to rework the whole NSEC/NSEC3 chain after a TTL change. The deviation would be 'part of the chain still has the old, wrong, value - for a while'. I'll ponder better words - suggestions are very welcome, of course.

Section 4

If signers & DNS servers for a zone cannot immediately be updated to
conform to this document, zone operators are encouraged to consider
setting their SOA record TTL and the SOA MINIMUM field to the same
value. That way, the TTL used for aggressive NSEC and NSEC3 use
matches the SOA TTL for negative responses.

Are there any negative consequences of such a move that would need to be
weighed against the stated benefits?

Signers might use either value (the SOA TTL or the SOA MINIMUM) as a default for some other value. For example, PowerDNS uses the SOA MINIMUM value as the TTL for DNSKEYs. So, lowering the SOA MINIMUM would also lower the DNSKEY TTL (in PowerDNS).

A quick skim of the BIND dnssec-keygen manual page suggests that BIND might sometimes take the SOA TTL as the DNSKEY TTL.

So, yes, there might be consequences. I will add a note.

0cb1965 removes this sentence:

(Note that, because .com uses opt-out NSEC3, such aggressive use would not in fact apply to this zone -
it is merely used as a very visible example here.)

The removal was because the sentence was irrelevant, especially with the change to .example. However, a conversation I had with @mnordhoff today reminded me that an opt-out NSEC(3) is basically a 'no-DS' claim over a range of (hashed) names. This means that the 86400 TTL on .com NSEC3s does in fact matter, because resolvers can act on it for the strict purpose of deciding if a delegation is insecure. This, then, means that the .com NSEC3 TTL in fact has operational impact.

20:41Z <Peng> Habbie: I thiiiiiiink Unbound is affected by this. It doesn't automatically do explicit DS queries like PowerDNS, and in my experience it caches "this domain is insecure" for a long time, but I don't know precisely how long or what its logic is.
20:41Z <Habbie> Peng, ok, will note that too
20:42Z <Peng> (I believe, if a user does "dig @unbound example.com ds", it will do an explicit DS query even if it had a cached there-is-no-DS referral.)
20:42Z <Habbie> Peng, can I quote your thiiiink in a public github ticket?
20:42Z <Peng> (Because its logic doesn't account for it, or so it can get the SOA record, or something. I don't know.)
20:43Z <Peng> Habbie: Sure. :D I haven't checked a recent version of Unbound, and I haven't examined its source code to see what the logic is, but I'm ~certain of my observation.
20:43Z <Habbie> the uncertainty is clear
20:43Z <Habbie> and I don't want to forget this
20:43Z <Habbie> thanks :)
20:44Z <Peng> I am certain of my observation, but I'm uncomfortable saying so out loud without carefully testing it for sure. :D
20:45Z <Habbie> Peng, do note that 'dig dnsdist.com @c.gtld-servers.net +dnssec' includes the denial

While any update we could do to 8198 would be without function, there's still wrong language in 5.4 and perhaps it would be better to 'delete' the third paragraph (because it's no longer true after this document) and fourth paragraph (because resolvers should not do that and if they did, it would just be wasted cycles) or replace them with a clarification.

https://mailarchive.ietf.org/arch/msg/dnsop/rUPpYxd_fHv0Ee-XtzX-6OSFAQU