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

[Geoff Huston]

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?

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
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover