Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- IANA's planned rollover date is October 11, 2026, and the new key tag is 38696. This is a scheduled signing transition, not proof the internet has already switched keys.
- Check DNSSEC-validating recursive resolvers and their trust anchors. Ordinary DNS records and HTTPS certificates do not need reconfiguration because of this rollover.
- On a sentinel-capable validating resolver that trusts the new key, is-ta should return a valid answer and not-ta should return SERVFAIL. Interpret the two together.
- An inconclusive result does not establish a missing key. Identify the resolver being tested, then follow its vendor's or provider's guidance to inspect trust anchors.
Which key changes on October 11?
IANA's current plan is for KSK-2024 to replace KSK-2017 in signing the root zone's public-key set on October 11, 2026. The new key's identifying key tag is 38696. At the time of review it remained listed as pre-published, and the schedule gave no exact switch time.
DNSSEC uses digital signatures to validate DNS records. A trust anchor is a root public key or fingerprint already trusted by the resolver, providing the starting point for validation. The new key entered the root zone on January 11, 2025, allowing automatic updates time to accept it. Prior publication does not prove every resolver has stored and trusts it.
Are you a website owner or a resolver operator?
People who only maintain websites and domains usually need no DNS-record changes for this root-key rollover. If you operate a DNSSEC-validating recursive resolver, check that its trust anchors are updated. A recursive resolver looks up domain addresses for devices; a missing new trust anchor may prevent root validation after the switch.
In its October 6 explanation, Cloudflare says its authoritative DNS service, 1.1.1.1, and Gateway DNS already trust KSK-2024, so their users need no action for this rollover. That statement does not establish readiness for internal company resolvers, router forwarding chains, or other DNS providers.
First identify the DNS path your test uses
Record the resolver you intend to check. With secure DNS enabled, a browser test may use the browser's configured provider; a VPN may also change the DNS path. The test sees the resolver used by that browser request, which may differ from the operating system's settings or the resolver your business server uses.
For example, suppose employee browsers use 1.1.1.1 while backend applications use an internal resolver. A browser readiness result supports only the first path. Application owners should still check the backend resolver and forwarding chain. This hypothetical explains the scope; it is not a measurement of any network.
Why can a SERVFAIL result mean the resolver is ready?
RFC 8509 defines sentinel queries: special names that ask whether a resolver trusts a particular root key. This is optional, so first confirm that the resolver supports sentinel queries and validates DNSSEC. Cloudflare's checker also uses correctly signed, incorrectly signed, and current-root-key queries as controls.
For a sentinel-capable validating resolver, is-ta-38696 asks whether the new key is trusted and should return a valid answer if it is. not-ta-38696 asks the opposite and should return SERVFAIL when the key is trusted. That resolution failure is deliberately triggered by the protocol and does not alone indicate broken DNS.
What should you check after an inconclusive result?
First check the control queries and whether sentinel support has been confirmed. If these are unconfirmed, the result is inconclusive, not proof that 38696 is missing. The RFC also warns that multiple resolvers, or switching to another resolver after SERVFAIL, can make observations inconsistent.
Then inspect trust anchors and automatic-update status using the resolver vendor's instructions. If the key is actually missing, use the vendor's or provider's update method. IANA notes that distribution and update timing vary by software. Disabling DNSSEC validation does not complete rollover preparation.
How can you keep a result that others can recheck?
Record the resolver address or service name, check time, path, sentinel support, and trust-anchor conclusion together. After updating through official guidance, repeat the check through the same business path. One browser result cannot cover every device, forwarding node, or later operating state.
The useful action now is to confirm readiness. Follow IANA's schedule, key status, and later announcements for the actual signing transition. Preserve the check records so that any subsequent resolution errors can be compared with the preparation completed at the time.
Sources
Frequently Asked Questions
Do website HTTPS certificates need to be reissued?
Usually not. This is a key rollover in the DNSSEC root trust chain, not replacement of website TLS certificates. If access fails, diagnose DNS resolution and the HTTPS handshake separately; nearby timing alone does not establish that the rollover caused it.
Does this rollover introduce post-quantum algorithms?
No. Cloudflare says both KSK-2017 and KSK-2024 use RSA/SHA-256. The key pair changes, while the signing algorithm remains the same. Other post-quantum DNSSEC developments cannot be attributed to this rollover.
Which test commands should I copy?
Cloudflare's official article provides complete dig examples for 1.1.1.1 and the checker. Confirm your target first: copying a command that specifies 1.1.1.1 tests that service, not your internal DNS. The official checker is also listed in the sources.