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

[Petr Špaček]

On 25.7.2018 16:17, Paul Hoffman wrote:
> On Jul 25, 2018, at 1:51 AM, Petr Špaček <petr.spacek at nic.cz> wrote:
>> 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.
> 
> The authors of RFC 8145 knew that there would be plenty of ways in which the data would not be sent to the root servers, including the two you list here. Despite what some people have said, the data was never meant to represent a statistical sample because of all the ways that it might never reach the root servers.
> 
>> Are there any results using the KSK root sentinel method?
> 
> ICANN has an extensive set of results at:
>    http://root-trust-anchor-reports.research.icann.org/index.html
> The charts and the dataset of addresses is updated daily.

I'm sorry for not being clear!

In fact I was looking at the site you linked above when I noticed there
is no mention of these limitations in section "Known Limitations of this
Strategy".

Anyway, my last question was actually about the "sentinel", i.e.
https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel

Is there a plan to have site with charts similar to the RFC 8145 one?

-- 
Petr Špaček  @  CZ.NIC