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

[Warren Kumari]

On Thu, Apr 5, 2018 at 1:00 PM, Peter van Dijk
<peter.van.dijk at powerdns.com> wrote:
> 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.

Ah, yes -- that triggered my recollection - yup, I believe that that
was it. I wish I'd documented that better in the Changelog / GitHub
commit log.

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

Yup. Does anyone have even better text to suggest?

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

Oh, words are important :-)
I meant to say "That sounds bestest, but the document should NOT
misbehave under this condition either..."

If auth doesn't conform to RFC4034 the document / mechanism shouldn't
fail in this manner -- it was (imo) an oversight that it did.

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