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