12°
Portada del artículo: The DNSSEC root changes its key on 11 October: I measured which environments already trust the new one
DNSDNSSECSecurityNetworking

The DNSSEC root changes its key on 11 October: I measured which environments already trust the new one

On 11 October 2026 the DNS root starts signing with KSK-2024; I measured which distros, Docker images, routers and resolvers already trust it. A freshly started unbound on Alpine 3.20, Fedora 42 or Amazon Linux 2023 trusts only the old one, and in Pi-hole v5 with DNSSEC and OpenWrt up to 23.05 the configuration only carries that one. If your resolver does not validate, the change does not touch it, unless it depends on another one that does validate and is not ready.

Efrain Garay 8 October 2026

Playing summary

On Sunday 11 October the DNS root changes the key it signs with. It is the second time this happens: the first was in October 2018. Almost nobody will notice: according to APNIC, most users sit behind resolvers that do not validate DNSSEC, and Cloudflare, Quad9 and AdGuard, which do validate, already trust the new key. What interested me was the rest: what I run myself and what people run at home, a Pi-hole, an OpenWrt router, an unbound in a container.

So I measured it. I checked the packages of 21 distro releases, started eleven of their resolvers from scratch with the default configuration (one inconclusive), tried 11 popular Docker images, the dnsmasq of 5 OpenWrt releases and 11 public resolvers, and left 10 resolvers running to watch the change live.

Narrated: the DNS root changes its key on 11 October 2026. A locksmith bot walks the gob.cl chain of trust with the measured times, shows which environments still carry the old key and how to check yours with two dig queries. Every figure is the measured one.Watch it in the reel viewer →

What DNSSEC is, on a real query

DNS without DNSSEC trusts whoever answers: if someone along the way changes the answer, your machine has no way to tell. DNSSEC adds signatures. Each zone signs its records with its keys, and the zone above publishes a digest of those keys (a DS record) signed with its own. That builds a chain from the root down to the name you asked for.

The one checking the chain is the validating resolver. To start, it needs to trust something without proof: the trust anchor, a copy of the key that signs the root. If the whole chain matches, the answer comes back with the AD flag (authenticated data). If anything does not match, it comes back SERVFAIL.

This is the real chain for gob.cl, asked directly to each server on 7 October:

The chain of trust for gob.cl, link by linkAsked to each authority directly on 7 October 2026. That day the root signed with key 20326.
DNSSEC chain of trust for gob.cl Architecture diagram: the resolver trusts root key 20326, which signs the root key set; root zone key 8763 signs the .cl DS, .cl key 14901 signs the gob.cl DS, and gob.cl key 6334 signs the answer. Root key 38696 replaces 20326 on 11 October 2026. Your resolver · anchor: 20326 · Architecture component Your resolver anchor: 20326 Root · KSK 20326 · signs the DNSKEY set · Architecture component Root · KSK 20326 signs the DNSKEY set Root · ZSK 8763 · signs the .cl DS · Architecture component Root · ZSK 8763 signs the .cl DS .cl · 21199 · ZSK 14901 signs DS · Architecture component .cl · 21199 ZSK 14901 signs DS gob.cl · 6334 · signs its answer · Architecture component gob.cl · 6334 signs its answer Answer with AD · validated · Architecture component Answer with AD validated Root · KSK 38696 · signs from 11 Oct · Architecture component Root · KSK 38696 signs from 11 Oct matches RRSIG DS DS RRSIG replaces it
  • your resolver and its anchor
  • KSK-2017 (20326), signs today
  • KSK-2024 (38696), signs from 11 October
  • zones below the root
  • validated path
Diagram compiled with Archify from a typed JSON, on the keys that each server returned. If your resolver only has 20326 in its anchor, the first time it renews the root key set after 11 October the first link breaks, and so does everything below it.

The first link is the only one that changes on Sunday. Everything below stays the same: .cl keeps signing with its key 21199 and gob.cl with 6334.

What changes on Sunday

Until 10 October the root signs its key set with KSK-2017, key tag 20326. From the 11th it is signed by KSK-2024, key tag 38696, which has been published in the root zone since January 2025. On 7 October the set had four keys (two zone signing keys, 8763 and 57780, because of a quarterly change in progress, plus the two KSKs) and a single signature, from 20326.

That set is cached for up to 48 hours, its TTL. That is why ICANN gives no failure time: a resolver that only trusts 20326 keeps working with its old copy and fails the next time it renews it. ICANN expects that to happen within the following 48 hours, although a lightly used resolver can take longer. According to Cloudflare, ICANN plans to revoke and remove KSK-2017 in 2027; ICANN’s document estimates the next change for 2029, and with it the move to ECDSA.

To see the mechanism I set up four unbound 1.26.1 resolvers that only differ in their anchor: one with the old key, one with the new one, one with both and one that updates itself with RFC 5011 and started on 7 October. The animation walks the six hops of the gob.cl chain with each one’s measured time (the sum of the six medians, asked directly to each authority from Chile, is 383 ms), and each resolver’s state is what the vigil measured on 7 October:

The first link, on loop and at the measured speedFour resolvers validate gob.cl, each with a different anchor. Flip the date: the root changes the key that signs its key set.

The first position is the state the vigil measured on 7 October (queries for example.com): the resolver that only has 38696 already fails. The second is what the standard predicts; the vigil keeps the four resolvers running through the change and this figure will be replaced with what it measures. The hop times are those of the gob.cl chain.

Two things the animation shows that are not obvious:

  • Losing the root also breaks unsigned names. A resolver validating in strict mode has to prove from the root that the delegation of an unsigned name is insecure, and without the root it cannot. On 7 October the unbound that only trusts 38696 answered SERVFAIL for efraingaray.com too, which is not signed.
  • RFC 5011 does not save what started late. The self-updating unbound saw 38696 on 7 October and put it on a 30-day hold (ADDPEND). On Sunday it will not trust it yet, and afterwards it cannot finish the hold on its own either: the set will be signed only by a key it does not trust yet.

Who really validates

Most do not. APNIC measures with ads which users sit behind validating resolvers: in the 30-day window to 5 October, 9.1% in Chile (plus 3.6% validating partly) and 39.1% worldwide. If your resolver does not validate, the change does not touch you, although you may depend on one further up that does.

My own machines are a good example. On fedora (Fedora 43) and on the VPS (Ubuntu 24.04), systemd-resolved runs with DNSSEC=no: they do not validate, they delegate. The Mac uses 8.8.8.8. The VPS has Hostinger’s resolver configured, which does hand out validated answers. The router at fedora’s home returned the name with broken signatures with no SERVFAIL and no AD flag.

I asked the public resolvers from Chile, with the two RFC 8509 sentinel names and one name with deliberately broken signatures (two for Yandex). What you see from here is what the anycast node serving Chile answers:

  • Cloudflare, Quad9 and AdGuard validate, and their sentinel answers like resolvers that already trust 38696.
  • Google, OpenDNS, Control D, CleanBrowsing and DNS.SB validate, but answered both sentinel questions, so this test does not say which anchors they hold.
  • Yandex DNS is the odd one. On its three addresses and in three repetitions (two of 81 queries got no answer), it sets AD on correctly signed data and lets two names with deliberately broken signatures through with NOERROR and no AD. Its sentinel answers like a resolver that trusts 20326 and not 38696, and the control question about 20326 comes out the other way round, as it should. That is consistent with validating in permissive mode: if that policy also applies when the root fails, on Sunday it could keep answering without setting AD instead of going down. The vigil will measure it.

Where DNSSEC is used

On the signing side, adoption is high at the top and low further down. I counted the whole root zone (serial 2026100702): 1,350 of 1,437 TLDs have a DS, .cl included. Among the top 1,000 of the Tranco list of 6 October (a popularity ranking that combines several sources), 109 have a DS record of their own. In a Chilean sample I picked by hand, 62 domains across six sectors, 7 are signed: gob.cl, nic.cl, santander.cl, bancointernacional.cl, falabella.com, sodimac.cl and wom.cl. None of the 8 universities or the 10 media outlets I picked.

Own DS record present, measured on 7 October 2026% · higher is better
  1. TLDs in the root zone93.9%1,350 of 1,437, .cl included
  2. Tranco top 1,00010.9%109 of 1,000 with their own DS
  3. Chilean sample11.3%7 of 62; 0 of 8 universities, 0 of 10 media

IANA root zone, serial 2026100702; Tranco list 26Y29 (6 October 2026); Chilean sample picked by hand, not random. A DS only counts if it is a DS record of the name itself.

Among TLDs, RSASHA256, algorithm 8, dominates: 1,086 publish it, against 269 publishing ECDSA P-256 (13), and 40 publish more than one. My domain is not signed either: efraingaray.com publishes no DNSKEY and .com returns a proof that there is no DS. For Sunday that does not matter: what counts is who validates.

Environment by environment

This is the measurement I was after. I separated two questions that usually get mixed: which key each package ships, and which key the resolver trusts when it starts with its default configuration.

Environment by environment: which root key each one carriesMeasured on 7 October 2026. Pick a view.
systemd-resolvedunbound-anchordns-root-dataunbound root.keydnssec-rootBINDdnsmasq
debian:10not found2010 and 20172017not foundnot found2010 and 20172010 and 2017
debian:11201720172017 and 2024not foundnot found20172017
debian:122017 and 202420172017 and 2024not foundnot found2017 and 20242017
debian:132017 and 20242017 and 20242017 and 2024not foundnot found2017 and 20242017 and 2024
ubuntu:18.042010 and 20172010 and 20172010 and 2017not foundnot found2010 and 2017not found
ubuntu:20.0420172010 and 20172017 and 2024not foundnot found20172017
ubuntu:22.04201720172017 and 2024not foundnot found2017 and 20242017 and 2024
ubuntu:24.04201720172017 and 2024not foundnot found2017 and 20242017 and 2024
ubuntu:26.042017 and 20242017 and 20242017 and 2024not foundnot found2017 and 20242017 and 2024
fedora:422017 and 20242017 and 2024not found2017not found2017 and 20242017
fedora:432017 and 20242017 and 20242017 and 20242017 and 2024not found2017 and 20242017 and 2024
fedora:442017 and 20242017 and 20242017 and 20242017 and 2024not found2017 and 20242017 and 2024
rockylinux:82010 and 20172017 and 2024not foundnot foundnot found2017 and 2024not found
rockylinux:920172017 and 2024not found2017 and 2024not found2017 and 20242017 and 2024
rockylinux:102017 and 20242017 and 2024not found2017 and 2024not found2017 and 20242017 and 2024
amazonlinux:2none2017not found2017not found2010 and 2017not found
amazonlinux:202320172017not foundnot foundnot found2017 and 2024not found
alpine:3.18not found2017not foundnot found20172017 and 20242017
alpine:3.20not found2017not foundnot found20172017 and 20242017
alpine:3.22not found2017 and 2024not foundnot found2017 and 20242017 and 20242017 and 2024
alpine:3.24not found2017 and 2024not foundnot found2017 and 20242017 and 20242017 and 2024

Keys found in each package as offered on 7 October 2026, installed in the release's official image, by the year of the key (2010 = 19036, 2017 = 20326, 2024 = 38696). "Not found": the scan did not find that component in that release. This is what the package ships, not what a running resolver trusts: that is the next view. In the 13 images where its resolved.conf could be read, the default it documents for systemd-resolved is DNSSEC=no.

Resolver and releaseVersionTrusts 38696 right after starting?
debian:11 bind99.16.50-1~deb11u6yes
ubuntu:20.04 bind99.18.30-0ubuntu0.20.04.2yes
ubuntu:24.04 bind99.18.39-0ubuntu0.24.04.7yes
debian:12 unbound1.17.1-2+deb12u4yes
ubuntu:24.04 unbound1.19.2-1ubuntu3.10yes
amazonlinux:2023 unbound1.17.1-1.amzn2023.0.15no
alpine:3.20 unbound1.20.0-r2no
ubuntu:24.04 systemd-resolved DNSSEC=yes255.4-1ubuntu8.17cannot tell
alpine:3.22 unbound1.25.2-r1yes
fedora:42 unbound1.24.2-1.fc42no

Default configuration, first start, asked with the RFC 8509 sentinel. In these tests BIND trusted every key in the root set signed by its anchor when it initialised its empty key store; unbound with RFC 5011 puts a key it has just seen on a 30-day hold, and with a fixed anchor it only trusts what that file has. systemd-resolved does not implement the sentinel.

ImageBuiltTrusts 38696?
mvance/unbound:1.17.12023-10-05no
mvance/unbound:1.20.02024-06-08no
mvance/unbound:latest2024-10-19yes
klutchell/unbound:1.17.12023-01-13no
klutchell/unbound:latest2026-09-18yes
isc/bind9:9.182026-06-17yes
isc/bind9:9.202026-09-30yes
cznic/knot-resolver:v5.7.42024-07-23yes
cznic/knot-resolver:v5.7.82026-10-06yes
pihole/pihole:2024.07.02024-07-05config: 2017 trust not measured: dnsmasq has no sentinel
pihole/pihole:latest2026-09-19config: 2017 and 2024 trust not measured: dnsmasq has no sentinel
OpenWrt: what the dnsmasq-full package ships (contents, not a running test)
OpenWrt 19.07.102.80-16.32010 and 2017
OpenWrt 21.02.72.85-92017
OpenWrt 22.03.72.86-162017
OpenWrt 23.05.62.90-22017
OpenWrt 24.10.82.93-r12017 and 2024

Images started with their default configuration (BIND forced to IPv4 and Knot non-interactive because of Docker; Pi-hole with DNSSEC turned on). Pi-hole and dnsmasq do not implement the sentinel, so for them the active trust-anchor lines were read from the generated configuration.

ResolverValidates?Trusts 38696?
Cloudflare 1.1.1.1yesyes
Google 8.8.8.8yescannot tell
Quad9 9.9.9.9yesyes
OpenDNS 208.67.222.222yescannot tell
AdGuard 94.140.14.14yesyes
Control D 76.76.2.0yescannot tell
CleanBrowsing 185.228.168.9yescannot tell
Yandex 77.88.8.8permissiveno
DNS.SB 185.222.222.222yescannot tell
Quad101 101.101.101.101no answer·
Lumen 4.2.2.2no·

Asked from Chile, one anycast node. "Cannot tell": the resolver validates and answered both sentinel questions, so this test does not say which anchors it holds. Permissive: it marks good answers with AD but let broken signatures through in this test.

What comes out of the four views:

  • A package shipping the key does not mean the resolver trusts it. What counts is the file the configuration points to. A freshly installed unbound does not trust 38696 on Amazon Linux 2023 (it starts from its built-in anchor, with only the old key), on Fedora 42 (its root.key ships only 20326) or on Alpine 3.20, where the default configuration uses a fixed anchor, never updated: the trusted-key.key from the dnssec-root package (version 20190225), which only has the old key. On Alpine 3.22 it does.
  • Old releases even ship the 2010 key. Debian 10, Ubuntu 18.04 and Amazon Linux 2 keep 19036, retired in 2019, and none ships 38696.
  • On Debian 12 and Ubuntu 24.04, unbound comes out fine thanks to a service step. Before starting, unbound copies the root.key from dns-root-data, which ships both keys even though its built-in anchor is old.
  • BIND learns at startup. Debian 11 ships BIND 9.16.50 with only 20326 in its files, and still, freshly started, rndc managed-keys status shows both keys as trusted from the start: when it initialises its empty key store it validates the DNSKEY set with the key it ships and installs the current ones. A key that appears later does wait 30 days.
  • Static anchors do not update themselves. dnsmasq does not do RFC 5011: it trusts the trust-anchor= lines in its configuration. In Pi-hole v5.18.3’s configuration with DNSSEC, the active trust-anchor lines I found only have 20326; v6.4.3’s have both. OpenWrt’s dnsmasq-full package in 21.02, 22.03 and 23.05 ships only the old key, and 19.07’s also ships the 2010 one, retired in 2019; 24.10 ships both.
  • systemd-resolved validates only if you ask it to, and then does not update. In the 13 images where I could read its resolved.conf, the default it documents is DNSSEC=no. With DNSSEC=yes it uses its built-in anchor. 38696 reached systemd’s code in commit 8113361, released in version 258. The packages of Debian 12 and 13 and Fedora 42 already carry it in older versions; those of Ubuntu 22.04 and 24.04, Rocky 9 and Amazon Linux 2023 do not.
  • Three unbound images from 2023 and June 2024 start without trusting the new key: mvance/unbound 1.17.1 and 1.20.0 and klutchell/unbound 1.17.1. Their current versions do.

There are also repair paths I did not measure after the change, which I leave with their source. According to its manual, unbound-anchor (the service that runs before unbound on Fedora, RHEL and Amazon Linux) can recover the anchor by downloading root-anchors.xml from IANA over HTTPS and verifying it, if it runs and the check passes. On Debian and Ubuntu the service copies dns-root-data again at startup, which helps if that package is up to date. A fixed anchor needs someone to change it.

The vigil: ten resolvers crossing the change

Since 7 October ten resolvers have been running on my Mac: the four unbound from the animation, mvance/unbound 1.17.1 and its current version, Pi-hole v5 and v6 with DNSSEC on, and systemd-resolved from Ubuntu 24.04 and 26.04 with DNSSEC=yes. Every five minutes a script asks them a signed name, an unsigned one and both sentinel questions, and records which key signs the root according to a.root-servers.net. The same round adds Cloudflare, Google, Quad9 and Yandex.

On 7 October all of them answered except the one that only trusts the new key. What I expect to see after Sunday is the old-key one, the late-started RFC 5011 one, mvance/unbound 1.17.1, Pi-hole v5 and Ubuntu 24.04’s systemd-resolved going down. This article will be updated with what it measures, including the time each one started failing.

How to check yours (and how to fix it)

First, ask your resolver the sentinel:

dig @YOUR_RESOLVER root-key-sentinel-is-ta-38696.dnstest.dev A
dig @YOUR_RESOLVER root-key-sentinel-not-ta-38696.dnstest.dev A

If the first answers and the second gives SERVFAIL, it already trusts 38696. If it is the other way round, it does not. If both answer, the test is inconclusive: it may not validate, may not implement the sentinel (dnsmasq, Pi-hole and systemd-resolved do not) or each question may reach a different server. For what you run yourself, check its anchors:

  • unbound: if it uses auto-trust-anchor-file (unbound-checkconf -o auto-trust-anchor-file tells you), look for 38696 in that file and check that it says VALID, not ADDPEND. If it uses a fixed anchor (trust-anchor-file or trust-anchor:), that file or line must contain 38696.
  • BIND: rndc managed-keys status must show keyid: 38696 with trusted since.
  • dnsmasq and Pi-hole v5: grep -r '^trust-anchor=' /etc/dnsmasq.d /etc/dnsmasq.conf.
  • systemd-resolved with DNSSEC=yes: if there are no *.positive files in /etc/dnssec-trust-anchors.d/, /run/dnssec-trust-anchors.d/, /usr/local/lib/dnssec-trust-anchors.d/ or /usr/lib/dnssec-trust-anchors.d/, it uses its built-in anchor.

To fix it, add the new key without removing the old one until the change. A key tag is just a 16-bit number, so compare the full DS record with the one IANA publishes. KSK-2024’s is this one:

. IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16

In dnsmasq and Pi-hole v5 it goes as trust-anchor=.,38696,8,2,683D2D0A... with the full digest, or you upgrade to Pi-hole v6. In systemd-resolved it goes in a file /etc/dnssec-trust-anchors.d/root.positive with both DS lines, 20326 and 38696: according to its manual, as soon as you define an anchor for the root it stops using the built-in one, and it does not update by itself. In unbound, update the package that ships the anchor (dns-root-data on Debian and Ubuntu, dnssec-root on Alpine) or let unbound-anchor renew it. In BIND, updating the package does not change a key store that already exists: if rndc managed-keys status does not show 38696 as trusted, follow ISC’s guide for that case.

If something goes down on Sunday, ICANN’s emergency exit is to briefly turn validation off or set a negative trust anchor for the root (RFC 7646), install KSK-2024 and validate again.

What I cannot claim

  • What happens after Sunday. Everything in this article is from 7 October. What is expected is marked as expected; the vigil will confirm or refute it.
  • The global state of public resolvers. I measured from a single place, Santiago, and I see the anycast node that serves me.
  • Which anchors the resolvers without the sentinel hold. Google, OpenDNS, Control D, CleanBrowsing, DNS.SB and Hostinger’s resolver validate, but this test does not show what they trust.
  • Installations that have been running for a while. I measured fresh starts. A BIND or an unbound with working RFC 5011, saved state and the 30-day hold completed already trusts 38696, even if its original package only shipped the old key. The risk is in losing that state (containers without a volume, reinstalls, recreated old images), in old fixed anchors and in updates that fail.
  • A freshly started Fedora 43. Its root.key has both keys in VALID state, but inside Docker its unbound answered SERVFAIL even for example.com, so that test does not count.

My take

Sunday will pass without most people noticing, and that is to the credit of those who published the new key 21 months ahead. But the people who validate DNSSEC on their own are exactly the ones who set up a Pi-hole, an OpenWrt or an unbound in a container, and that is where I found old anchors in releases that are still around. What surprised me most was how differently each piece of software behaves with the same key: in these tests BIND trusted the new key from its first start, unbound with RFC 5011 put it on a 30-day hold and dnsmasq does not update it by itself.

When to worry and when not

  • There is nothing to do on your machine if you use your ISP’s DNS, your stock router’s or a public one, or if your systemd-resolved runs with DNSSEC=no: validation, if any, happens in the resolver above.
  • Check today if you have Pi-hole v5 with DNSSEC, OpenWrt up to 23.05 with dnsmasq-full and DNSSEC, unbound or BIND in containers that get recreated, Alpine 3.20 or older with unbound, or systemd-resolved with DNSSEC=yes on Ubuntu 22.04 or 24.04.
  • Keep the emergency exit at hand if you run a resolver for other people: RFC 7646’s negative trust anchor or briefly turning validation off, then installing KSK-2024.

Measured on 7 October 2026 from Santiago, Chile. Containers on Docker 29.3.1 on an x86_64 Mac; test resolvers unbound 1.26.1-0+deb13u1 on debian:13-slim. Each distro’s packages installed that day from its repositories (Debian 10 and 11 from archive.debian.org). Tranco list 26Y29; root zone serial 2026100702; APNIC data with a 30-day window to 5 October.

Frequently asked questions

What changes on 11 October 2026?

The DNS root starts signing its key set with a new key, KSK-2024 (key tag 38696), instead of KSK-2017 (key tag 20326), which has signed since 2018. The new key has been published in the root zone since January 2025. A resolver that validates DNSSEC and only trusts the old key can no longer validate the root once it renews the key set, and from then on answers SERVFAIL, unsigned names included.

Does it affect me if I use my ISP's DNS, Cloudflare or Google?

There is nothing to do on your machine: that resolver does the validation, and if it were not ready, fixing it falls to whoever runs it. I measured from Chile that Cloudflare, Quad9 and AdGuard already trust the new key; Google, OpenDNS, Control D, CleanBrowsing and DNS.SB validate, but this test does not show which anchors they hold. According to APNIC, only 9.1% of users in Chile sit behind a validating resolver.

How do I know whether my resolver already trusts the new key?

Ask it two RFC 8509 test names: dig @your-resolver root-key-sentinel-is-ta-38696.dnstest.dev and dig @your-resolver root-key-sentinel-not-ta-38696.dnstest.dev. If the first answers and the second gives SERVFAIL, it trusts it. If it is the other way round, it does not. If both answer, the test is inconclusive: it may not validate, may not implement the test (as with dnsmasq, Pi-hole and systemd-resolved) or each question may be answered by a different server, and its anchors have to be checked by hand.

I run Pi-hole with DNSSEC on. What should I do?

If it is Pi-hole v5 (the 2024.07.0 image ships v5.18.3), the active trust-anchor lines in its configuration only have 20326, and dnsmasq does not update itself: upgrade to v6, which writes both, or add the trust-anchor line for 38696 without removing the old one. With DNSSEC off, Pi-hole does not validate and the change does not affect it directly; it depends on its upstream resolver being ready.

Why can unsigned names fail too?

Because a resolver validating in strict mode has to prove, from the root down, that the delegation of an unsigned name is insecure, and once it needs to validate the root again it cannot. I measured it: on 7 October an unbound that only trusts the new key answered SERVFAIL for efraingaray.com as well, which is not signed.

What do I do if my DNS goes down on Sunday?

ICANN's emergency advice is to briefly turn validation off or configure a negative trust anchor for the root (RFC 7646), then install KSK-2024 as an anchor and validate again. What you must not do is keep only 38696 before the change: that fails too, as I measured on 7 October.

Does my website need to do anything?

No. The change affects those who validate; those who sign or publish have nothing to do. My own domain, efraingaray.com, is not even signed: it publishes no DNSKEY and .com returns a proof that there is no DS.

Sources

Comments

No comments yet. The first one is yours.

Reviewed before publishing. The email is not stored and never appears anywhere.