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

[Warren Kumari]

On Sat, Mar 31, 2018 at 7:39 AM, Peter van Dijk
<peter.van.dijk at powerdns.com> wrote:
> 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.

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

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" ?


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

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

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

W

>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf