On Thu, 8 Feb 2018, Joe Abley wrote:
I don't disagree with the need for more data, but I think the hole you mention is not so giant. As far as I can tell it's a result of:
How do you know without the data?
1. RFC5011 support not being turned on in nameservers that have been upgraded but whose older, DNSSEC-validating configuration has been preserved across updates (most cases), and 2. RFC5011 support exercising a code path that requires a writable, persistent filesystem to store an updated trust anchor, which turns out not to be available (fewer, but some cases).
3. gold images instantiated in private clouds 4. AMI images used in AWS 5. docker containers 6. kubernetes containers 7. old configs not getting updated unrelated to 1. and 2.
unbound-anchor and its use in package and system start scripts is, I think, a key reason why the two problems described above don't show up in unbound.
Even for bind, the OS vendors update the packages with the new keys, so I think your statement is somewhat simplified. It could also be that we keep seeing new updated software doing initial old keys then going to new keys. Or it could be that we see the same readonly containers/chroot instances starting up. the uptime of OS tells you if these are highly customized containers. the uptime of the process tells you if this is an instance that might update itself still (maybe no hold timer via cron, only via daemon?)
I think that the sentinel approach of measuring end-user impact from the end-user perspective gets us much closer to useful data in general. However, it's not clear to me how even a trusted, accurate sense of uptime across all resolvers would help with those questions.
I didn't say anything about not using sentinel. I was only wondering if we can use those to get more data with respect to resolver state. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
