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

[Peter van Dijk]

Hello,

On 13 Mar 2018, at 22:24, Andrew White wrote:

>>
>> From: James Stevens <James.Stevens at jrcs.co.uk>
>> "The TTL of this record is set from the minimum of the MINIMUM field 
>> of
>> the SOA record and the TTL of the SOA itself"
>>
>> min(900,86400) = 900
>>
>> "and indicates how long a resolver may cache the negative answer"
>>
>> TTL cache neg = 900
>>
> ​
> Exactly! So what is the point of having an SOA MIN field value greater 
> than
> the SOA TTL?

With reference to what Mark Andrews said elsewhere in the thread: before 
RFC8198, a SOA MIN field higher than the SOA TTL would generally be 
ignored for all practical purposes, other than caching NSEC/NSEC3 
records, which was fine because nobody actually used them aggressively.

However, RFC4034 section 4 has this unfortunate text:

    The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
    field.  This is in the spirit of negative caching ([RFC2308]).

Note how the first sentence in fact -ignores- the min(900,86400) advice 
from RFC2308, even though the second sentence references 2308.

Then we have RFC8198 (aggressive NSEC/NSEC3) section 5.4 
(‘Consideration on TTL’) which tries to fix this but fails 
miserably:

    Section 5 of [RFC2308] also states that a negative cache entry TTL 
is
    taken from the minimum of the SOA.MINIMUM field and SOA's TTL.  This
    can be less than the TTL of an NSEC or NSEC3 record, since their TTL
    is equal to the SOA.MINIMUM field (see [RFC4035], Section 2.3 and
    [RFC5155], Section 3).

    A resolver that supports aggressive use of NSEC and NSEC3 SHOULD
    reduce the TTL of NSEC and NSEC3 records to match the SOA.MINIMUM
    field in the authority section of a negative response, if 
SOA.MINIMUM
    is smaller.

Working through these rules with a negative reply from .com, the TTL on 
the NSEC3 stays 86400. I expect the authors assumed that SOA MIN would 
never be greater than SOA TTL, perhaps.

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. 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.

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.

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