Future posts will be at:

The next root zone KSK has been published: It will coëxist with the current KSK for some time, giving resolvers many opportunities to update and eventually cut over to the new KSK.

@NGC_3572 Top 10 Tranco ratings of DNSSEC-signed .FI domains: foreca․fi 9291 plat․fi 34059 iki․fi 35603 kapsi․fi 43283 zoner․fi 49867 s-pankki․fi 52346 suomi․fi 53896 gigantti․fi 59963 finlandabroad․fi 61954 kennelliitto․fi 66979

@PhillipStassny Unclear what you had in mind. Security is measured against specific threats. DANE militates "man in the middle" attacks on SMTP transport security...

@FFR31MR_D You can find good DNSSEC support from: * CloudFlare * OVH * Gandi * one․com * GKG * and others I neglected to mention Avoid Route53, WorldNIC, and Neostrada. Their implementations have some warts (last I looked).

@PascalMarcelis You should also be able to see DANE support confirmed by entering the domain name at This does not do any live probes, instead checks ~23M domains delegated from a public suffix once a day.

@chrislehratx Thanks for the article. I think users would be less confused by the Microsoft test screen, if the TLSA records that don't match were simply shown as "neutral", rather than "failing" when others do match. In a resilient configuration is normal to have some non-matching TLSA RRs.

@ccTLDuz While I have your attention, I should say that the DNSKEY RRset of .UZ is needlessly signed by both the KSK and the ZSK. The ZSK RRSIG is redundant bloat, you can reduce DNS packet sizes by signing the apex DNSKEY RRsets with just the KSK (other RRsets with just the ZSK).

@ccTLDuz In any algorithm rollover the RRSIGs for the new algorithm are expected to appear either (ideally) prior to the publication of the new keys in the DNSKEY RRset, or at least at the same time (given short enough TTLs). Here that did not happen.

@Thorb3n

@pbeyssac @gro_tsen Nope, DNSSEC protection of A records does not help with certificate integrity. Only signed CAA records can somewhat alleviate the risk of unauthorised issuance, this is rarely done. For SMTP we have actual use of signed TLSA records by ~4.2 million domains.

@pbeyssac @gro_tsen Actually, the original post is quite right, the 3rd-party observer attestations of your domain control are rather fragile TOFU (trust on first use) leaps of faith, and are susceptible to MiTM at that time. With DNSSEC and "account" in CAA records, one can somewhat harden renewal.

Nice to see @CNicRegistry doing an algorithm rollover for .storage (RSASHA1(7) -> ECDSAP256SHA256(13)).

@SecurityAid Top MSFT DANE Tranco scores: rte․ie 3684 sdu․dk 22317 schiphol․nl 26161 dk-hostmaster․dk 26639 vogel․de 28430 sidn․nl 33594 leaseweb․com 34768 trinidadexpress․com 44232 leaseweb․nl 59114 coop․dk 66491 svb․nl 69013 crimsonlogic․com 72208 bta․bg 73386 asnbank․nl 74011

@SecurityAid With over 2000 domains, the top TLDs are now: 725 nl 421 com 123 de 96 dk 64 au 55 net 54 eu 41 cz 37 org 36 be 36 ca 28 fr 24 se 19 uk 17 ch 14 za 11 nu 11 at 11 no 10 it 9 info 8 cloud 8 us 8 dev 6 co 6 nz 6 ie 5 xyz 5 tech 5 me 5 io 4 solutions 4 br 4 pl 4 email 4 es 4 biz

@simplydotcom It looks like your MX host now supports TLS 1.2 *with* EMS, and also TLS 1.3. Nice it brought up to date.

@lgomezperu The article is misleading, it fails to distinguish between the complexity of implementing DANE for your self-managed domains, vs. opting in to DANE on a provider managed domain, where the provider takes care of the TLSA record upkeep. Much dread, little substance.

Top 12 Tranco-ranked MSFT DANE sites: rte․ie 3638 schiphol․nl 26046 dk-hostmaster․dk 27079 leaseweb․com 29558 sidn․nl 33419 trinidadexpress․com 44090 devolksbank․nl 53745 leaseweb․nl 55533 asnbank․nl 66993 coop․dk 67276 crimsonlogic․com 71699 bta․bg 74971

Congrats to scannet․dk a.k.a. spamfilter․io on enabling inbound DANE SMTP for over 13,000 customer domains including their own. scannet․dk․ MX 0 mx․spamfilter․io․ spamfilter․io․ MX 0 mx․spamfilter․io․ dandomain․dk․ MX 0 mx․spamfilter․io․ Total count now > 4.2M