[dns-operations] Stale NTA for "peek.ru" at Cloudflare?
ietf-dane at dukhovni.org
Fri Mar 13 23:44:58 UTC 2020
On Fri, Mar 13, 2020 at 06:01:52PM -0400, Viktor Dukhovni wrote:
> That said the "MUST NOT" validate algorithms from that table have the
> following frequencies in the wild based on my (unavoidably incomplete)
> survey of ~10.8 million signed domains:
> dane=> select count(distinct qname), alg from ds where alg in (1,3,6) group by 2 order by 1 desc;
> count | alg
> 288 | 1
> 234 | 3
> 40 | 6
> So the scope of the problem is admittedly rather modest, affecting fewer
> than 600 of the ~10.8 million domains.
After upgrading my system to unbound 1.10.0, I see the same response
from the local unbound server as from Cloudflare:
$ hsdig -CD -t tlsa _25._tcp.beta.peek.ru
_25._tcp.beta.peek.ru. IN CNAME _tlsa.peek.ru. ; NoError AD=0
_tlsa.peek.ru. IN TLSA 3 0 1 ef3d63aa7b10d1f060d43d30b356f19a38fddb36542ab188da787524be265a24 ; NoError AD=0
_tlsa.peek.ru. IN TLSA 3 0 1 925758b9aed10aa43ad72b5cd170eee4744d56cda9e3d970df2769e3085b083d ; NoError AD=0
So perhaps this is to be expected given that DSA-NSEC3-SHA1 went from
to "MUST NOT" for both signing and validation in
In future RFCs deprecating algorithms (e.g. soon I hope RSASHA1 5 and
RSASHA1-NSEC3-SHA1 7) we should perhaps aim to first specify "MUST NOT"
for signing, and only some time (years) later "MUST NOT" for validation.
Which I think ideally means updating "8624" *this year* with a "MUST NOT"
for signing for 5 and 7, with a view to "MUST NOT" also for validation
no earlier than 2022.
More information about the dns-operations