[dns-operations] RFC2308, negative answer caching, and the largest gTLDs

[Peter van Dijk]

Hello Warren,

On 2 Apr 2018, at 17:21, Warren Kumari wrote:

> On Sat, Mar 31, 2018 at 7:39 AM, Peter van Dijk
> <peter.van.dijk at powerdns.com> wrote:
>> In other words, where before 8198 an NXDOMAIN would deny that single 
>> name
>> for 900 seconds, with 8198, that name and a large group that hash 
>> ‘close to
>> it’ will be denied for 86400 seconds.
>
> Speaking as *one* of the authors, that was not the intended / expected 
> behavior.
>
> At one point we had
> (https://github.com/wkumari/draft-ietf-dnsop-nsec-aggressiveuse/blame/1aef852a9f1960ebcd245417dab6e6fba0af1944/draft-ietf-dnsop-nsec-aggressiveuse.xml#L314)
> "A resolver that supports aggressive use of NSEC and NSEC3 should
> reduce the TTL of NSEC and NSEC3 records to match the TTL of the SOA
> record in the authority section of a negative response, if the SOA TTL
> is smaller."
>
> and then we updated it to the new text, but I'm having a hard time
> determining / remembering what triggered the change (other than the
> assumption that SOA MIN would be less than or equal to SOA TTL).

Ralph Dolmans helpfully points out that when the NSEC(3)s are replied 
due to a wildcard expansion, the resolver has no SOA TTL to look at, it 
only has the NSEC(3) TTL which is unhelpfully copied from the SOA MIN. I 
don’t know, of course, if that is what prompted your change.

> What should the correct wording be?
> "A resolver that supports aggressive use of NSEC and NSEC3 SHOULD
> reduce the TTL of NSEC and NSEC3 records to:
> MINIMUM(TTL of NSEC / NSEC3 records, SOA TTL, SOA MINIMUM)"
>
> or
> "A resolver that supports aggressive use of NSEC and NSEC3 SHOULD
> reduce the TTL of NSEC and NSEC3 records to match the smaller of the
> SOA TTL or the SOA MINIMUM field in the authority section of a 
> negative
> response (if either of these are smaller than the TTL of the NSEC / 
> NSEC3
> records" ?

Assuming the auth is conformant to 4034, these two texts should be 
identical. If we let go of that assumption, the second text is better. 
However, Ralph’s comment on wildcard expansion stays relevant then.

>> This is a serious change in
>> resolver-understood intent of the numbers typed in by the zone 
>> operator.
>>
>> We could update these RFCs but it would take a long time for 
>> implementations
>> to follow along.
>
> While it is unclear to me that an errata could be Verified against
> this, one could be reported (once we agree what the change should be).

+1

>> I think the conclusion here should be that (Duane, are you reading 
>> along?)
>> yes, the SOA MIN field should be set identical to the SOA TTL to 
>> avoid these
>> bad interactions between 2308, 4034 and 8198. It will also avoid some
>> confusion in the large group of people that haven’t read up on DNS 
>> since
>> before 2308.

Following up on myself here: with Ralph’s comment, it’s obvious that 
the fixes are ‘operational guidance being this paragraph above’ or 
‘fixing 4034 section 4 to take min(SOA TTL, SOA MIN)’ - the latter 
having a major long tail deployment problem.

> Indeed. That sounds bestest, but the document should misbehave under
> this condition either...

Assuming you meant to write ‘could misbehave’: how?

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/