[ksk-rollover] RFC 8145 interaction with Aggressive DNSSEC cache

[Petr Špaček]

On 25.7.2018 21:08, Geoff Huston wrote:
> It seems to me that the best action right now is to deprecate
> RFC 8145 and move on. As far as I can tell its only value is generating
> a garbled signal at the roots and a garbled signal is indistinguishable
> from noise - obviously this is a personal oipinion!
> 
> I have not launched any tests of the root sentinel method as yet - I was 
> waiting to see the fate of the IETF publication process, but is is worth
> the question on this list: Which resolver vendors have implemented the 
> KSK sentinel and integrated it into deployed resolver code releases?

Draft-14 is implemented in Knot Resolver 2.4.0 and enabled by default.
Older versions implement older versions of the draft.

Petr Špaček  @  CZ.NIC


> Geoff
> 
> 
>> On 25 Jul 2018, at 6:51 pm, Petr Špaček <petr.spacek at nic.cz> wrote:
>>
>> Hello,
>>
>> here is one additional caveat about RFC 8145 signaling which I did not
>> see mentioned anywhere:
>>
>> As long as RR "_TA-4A5C-4F66. NULL" does not exist in the root zone, any
>> resolver which implements RFC 8145 (signaling) together with either of
>> - Aggressive Use of DNSSEC-Validated Cache (RFC 8198)
>> - Decreasing Access Time to Root Servers by Running One on Loopback (RFC
>> 7706)
>> is likely not to send signaling queries to the root.
>>
>> If the resolver implemented only RFC 8198 it might send query from time
>> to time but it very much depends on state of its cache and cannot be
>> relied on. RFC 7706 stops signaling queries altogether.
>>
>> The problem with aggressive cache could be solved by adding the _TA
>> records to the root but I'm not sure if it is worth the effort.
>>
>>
>> Are there any results using the KSK root sentinel method?
>>
>> -- 
>> Petr Špaček  @  CZ.NIC