RFC 8145 interaction with Aggressive DNSSEC cache
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
On Jul 25, 2018, at 1:51 AM, Petr Špaček <petr.spacek@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. --Paul Hoffman
On 25.7.2018 16:17, Paul Hoffman wrote:
On Jul 25, 2018, at 1:51 AM, Petr Špaček <petr.spacek@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
On Jul 25, 2018, at 7:45 AM, Petr Špaček <petr.spacek@nic.cz> wrote:
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".
Ah, right. We will update that. Thanks!
Anyway, my last question was actually about the "sentinel"
Is there a plan to have site with charts similar to the RFC 8145 one?
There are no plans yet. There should be a discussion about how to compare different surveys from different researchers getting sentinel results. If the results are comparable, I would imagine ICANN could host them. --Paul Hoffman
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@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@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover
On Thu, Jul 26, 2018 at 05:08:45AM +1000, Geoff Huston wrote:
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?
BIND for one. It's published in all current releases branches (as of 9.9.13, 9.10.8, 9.11.4, 9.12.2, and the 9.13 development branch), and enabled by default. -- Evan Hunt -- each@isc.org Internet Systems Consortium, Inc.
Op 25 jul. 2018 om 21:29 heeft Evan Hunt <each@isc.org> het volgende geschreven:
On Thu, Jul 26, 2018 at 05:08:45AM +1000, Geoff Huston wrote: 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?
BIND for one. It's published in all current releases branches (as of 9.9.13, 9.10.8, 9.11.4, 9.12.2, and the 9.13 development branch), and enabled by default.
And Unbound 1.7.1 (released May 3rd), default enabled. -- Benno -- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/
thanks for these responses - I’ll set up a measurement experiment then! Geoff
On 26 Jul 2018, at 5:36 am, Benno Overeinder <benno@NLnetLabs.nl> wrote:
Op 25 jul. 2018 om 21:29 heeft Evan Hunt <each@isc.org> het volgende geschreven:
On Thu, Jul 26, 2018 at 05:08:45AM +1000, Geoff Huston wrote: 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?
BIND for one. It's published in all current releases branches (as of 9.9.13, 9.10.8, 9.11.4, 9.12.2, and the 9.13 development branch), and enabled by default.
And Unbound 1.7.1 (released May 3rd), default enabled.
-- Benno
-- Benno J. Overeinder NLnet Labs https://www.nlnetlabs.nl/
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
participants (5)
-
Benno Overeinder -
Evan Hunt -
Geoff Huston -
Paul Hoffman -
Petr Špaček