Verify the DNS trust path before a healthy public service appears unreachable
On October 11, 2026, the DNS root is scheduled to begin using KSK-2024 to sign its DNSKEY record set. DNSSEC-validating recursive resolvers that do not trust the new key may return failures for otherwise healthy domains. In this guide, we explain the rollover, show how RFC 8509 trust anchor sentinel queries work, and provide a practical resolver-testing workflow. We also show how to distinguish a resolver-specific DNSSEC failure from a stopped Localtonet tunnel, an unreachable local target, or an application problem.
📋 What's in this guide
Why the 2026 root KSK rollover matters
The Domain Name System translates hostnames into the records that applications need, including IP addresses and service-routing information. DNSSEC adds cryptographic signatures that allow a validating recursive resolver to check whether signed DNS data is authentic and has remained unchanged.
DNSSEC validation depends on a chain of trust. For a signed name below .com, for example, a validating resolver may follow that chain from the DNS root to .com and then to the authoritative zone for the requested domain. The root is different from an ordinary child zone because it has no parent that can publish a Delegation Signer record for it. A validating resolver therefore needs a preconfigured or securely learned root trust anchor.
The root key-signing key, or KSK, is central to that starting point. KSK-2024, identified by key tag 38696, is scheduled to replace KSK-2017, identified by key tag 20326, as the key that signs the root DNSKEY record set. The signing change is scheduled for October 11, 2026.
A validating resolver that trusts KSK-2024 should be able to continue validating the root DNSKEY set after the switch. A validating resolver that does not trust the new key may be unable to build a valid DNSSEC chain. From an application or browser, the visible symptom can be a generic DNS failure even though the destination website, API, tunnel, or server is functioning normally.
The operational action falls primarily on administrators of DNSSEC-validating recursive resolvers. Application operators should still test the resolvers used by their users, offices, devices, monitoring systems, and production networks so that a resolver failure is not mistaken for an application outage.
DNSSEC trust anchors are not ordinary DNS records
A DNSSEC trust anchor is local security state used by a validating resolver. It is not an A, AAAA, CNAME, MX, or TXT record that a domain owner adds to make a service resolve. Confusing these layers can lead to ineffective troubleshooting, such as changing a hostname's address record when the actual problem is that the recursive resolver cannot validate the DNSSEC chain.
| Item | Purpose | Where it belongs | Relevance to the rollover |
|---|---|---|---|
| A or AAAA record | Maps a hostname to an IPv4 or IPv6 address | Authoritative DNS zone | Does not establish the resolver's root trust anchor |
| CNAME record | Aliases one hostname to another hostname | Authoritative DNS zone | Can be part of the lookup path, but does not update KSK trust |
| MX record | Identifies mail exchangers for a domain | Authoritative DNS zone | Its validated lookup can fail if the resolver's DNSSEC trust path fails |
| TXT record | Publishes text-based policy or verification data | Authoritative DNS zone | Cannot be used to install a root trust anchor in recursive resolvers |
| DS record | Links a parent zone to a child zone's DNSSEC key | Parent authoritative zone | Builds the chain of trust below the root |
| DNSKEY record | Publishes public DNSSEC keys for a zone | The signed zone | The root DNSKEY set contains the root KSK and ZSK material |
| Root trust anchor | Provides the resolver's trusted starting point | Validating recursive resolver state or software | Must recognize KSK-2024 for the planned signing change |
The roles of the KSK and ZSK
The root zone uses signing keys with distinct roles. The zone-signing key, or ZSK, signs root-zone records, including DS records for top-level domains. The key-signing key signs the root's DNSKEY record set. A validating resolver starts with its trusted KSK information, verifies the DNSKEY set, obtains the ZSK from that verified set, and then verifies the root-zone records needed to continue down the hierarchy.
This distinction explains why a root KSK rollover is operationally important even though most application hostnames do not change. The rollover changes the trusted key used at the beginning of validation, not the ordinary address records returned for an application.
How RFC 5011 automatic updates help
RFC 5011 defines a process through which a validating resolver can learn a new trust anchor. The root publishes the replacement KSK alongside the existing key in the signed DNSKEY set. A resolver that already trusts the existing key can authenticate the set containing the candidate replacement.
The resolver does not immediately accept the new key merely because it appears once. It waits at least 30 days, continues checking the signed DNSKEY records during that period, and must successfully verify the records containing the new key again before accepting it as a trust anchor. KSK-2024 has been present in the root DNSKEY set since January 11, 2025, giving continuously operating and correctly configured RFC 5011 resolvers time to learn it.
Resolver upgrades, migrations, rebuilt systems, restored snapshots, damaged state, or incorrect trust-anchor configuration can interfere with learned trust-anchor state. Administrators should inspect and test the actual resolver instances that will serve clients rather than assuming that publication of KSK-2024 automatically made every deployment ready.
How RFC 8509 trust anchor sentinels work
RFC 8509 defines the root key trust anchor sentinel. It provides a way to ask a supporting recursive resolver whether it trusts a root key with a specified key tag. The mechanism uses specially constructed DNS names beneath a DNSSEC-signed domain rather than introducing a new DNS record type.
For KSK-2024, the relevant key tag is 38696. Two labels ask complementary questions:
root-key-sentinel-is-ta-38696asks whether key tag 38696 is a trust anchor.root-key-sentinel-not-ta-38696asks whether key tag 38696 is not a trust anchor.
Both names can have otherwise valid, DNSSEC-signed address data. A DNSSEC-validating resolver with sentinel support first validates the underlying answer. It then decides whether to return the answer or deliberately replace it with SERVFAIL, based on its local trust-anchor state and the sentinel label.
| Resolver state | is-ta-38696 |
not-ta-38696 |
Interpretation |
|---|---|---|---|
| Validating, sentinel-aware, and trusts KSK-2024 | Valid response | SERVFAIL |
Expected ready pattern |
| Validating, sentinel-aware, and does not trust KSK-2024 | SERVFAIL |
Valid response | Resolver administrator should investigate |
| Does not implement the sentinel behavior | May return the ordinary response | May return the ordinary response | Test is inconclusive for trust-anchor state |
| DNSSEC validation is disabled | May return the ordinary response | May return the ordinary response | Test does not demonstrate DNSSEC readiness |
| Underlying DNS or network failure | Failure or timeout | Failure or timeout | Resolve connectivity and DNS availability before interpreting the sentinel |
When a validating, sentinel-aware resolver trusts KSK-2024, SERVFAIL for the not-ta-38696 query is expected. Do not evaluate either query in isolation. The useful signal is the paired result from both names through the same resolver path.
Test the resolver your client actually uses
A correct test must reach the resolver path used by the application or user you are diagnosing. A result from a public resolver does not establish the readiness of an office resolver, an ISP resolver, a home router's forwarder, a container-specific resolver, or a corporate DNS service.
The commands below use dig and the DNSSEC-signed dnstest.dev sentinel names. Running dig without an @server argument normally sends the query through the resolver configured for that environment. Confirm the server shown in the output because local forwarding, VPN clients, encrypted DNS, containers, and split DNS can change the effective path.
Identify the real resolver path
Run the test from the affected device, network, container, or execution environment. Check which DNS server appears in the command output. A browser using its own encrypted DNS setting may use a different resolver than a terminal on the same machine, so test the application path separately when necessary.
Query the positive KSK-2024 sentinel
Ask whether key tag 38696 is trusted. On a validating resolver with RFC 8509 support that trusts KSK-2024, this query should return a valid answer rather than SERVFAIL.
Query the negative KSK-2024 sentinel
Ask the complementary question through the same resolver. On a validating, sentinel-aware resolver that trusts KSK-2024, this query should deliberately produce SERVFAIL.
Evaluate the pair, not one response
A valid positive answer combined with SERVFAIL for the negative sentinel is the expected trusted pattern. The reverse pattern indicates that the resolver does not recognize KSK-2024 as a trust anchor. Two ordinary answers are inconclusive because the resolver may not support sentinels or may not validate DNSSEC.
Repeat from every operationally important network
Test offices, remote sites, production servers, monitoring locations, VPN paths, and representative client networks independently. Resolver readiness is not a property of the hostname alone. Different networks can produce different outcomes for the same name.
Run the paired sentinel queries
dig root-key-sentinel-is-ta-38696.dnstest.dev A
dig root-key-sentinel-not-ta-38696.dnstest.dev A
Inspect the header status in each response. The significant statuses for the sentinel comparison are normally NOERROR with an answer and SERVFAIL. A timeout is different from SERVFAIL: it may indicate unavailable DNS service, packet loss, filtering, or another network problem rather than a deliberate sentinel decision.
Test a specific resolver when comparing paths
If you are authorized to query a specific recursive resolver directly, dig accepts the resolver after the @ character. The following documented example tests the sentinel behavior through 1.1.1.1:
dig @1.1.1.1 root-key-sentinel-is-ta-38696.dnstest.dev A
dig @1.1.1.1 root-key-sentinel-not-ta-38696.dnstest.dev AA direct query is useful as a comparison, but it does not replace testing the configured resolver. If the configured resolver fails while a directly queried public resolver succeeds, the difference points toward the configured recursive path. It does not, by itself, prove the exact configuration mistake or authorize changing resolver settings on a managed network.
Corporate and managed resolvers may provide split-horizon names, access policy, malware controls, internal service discovery, or auditing. Use an alternate resolver as a controlled diagnostic comparison only when policy permits it. Report a stale trust anchor to the resolver administrator instead of treating a local DNS override as the permanent repair.
Interpret the test without drawing the wrong conclusion
Expected ready pattern
If the positive is-ta-38696 name returns a valid answer and the negative not-ta-38696 name returns SERVFAIL, the resolver is demonstrating the expected RFC 8509 behavior for a resolver that trusts KSK-2024. Record the resolver address, test location, time, and result so that the test can be repeated after software or infrastructure changes.
Reverse pattern
If the positive name returns SERVFAIL while the negative name returns a valid answer, a validating, sentinel-aware resolver is reporting that key tag 38696 is not trusted. The resolver administrator should inspect its trust-anchor configuration and state, then follow the resolver software vendor's supported update or recovery procedure.
Do not copy trust-anchor files or manually edit managed state based on a generic command from another resolver implementation. Resolver products differ in how they package built-in anchors, maintain RFC 5011 state, recover from an invalid state, and reload configuration.
Both names return ordinary answers
Two ordinary answers do not prove that KSK-2024 is trusted. The resolver may not implement RFC 8509, or DNSSEC validation may be disabled. Check the software's documentation, current configuration, logs, and trust-anchor status using its supported administrative tools. If you do not operate the resolver, provide the paired query results to its administrator.
Both queries fail
If both names return SERVFAIL, time out, or fail inconsistently, first establish that the signed test domain can be resolved through the selected DNS path. Possible causes include a broader DNSSEC validation problem, a forwarding resolver failure, unavailable upstream service, blocked DNS transport, or loss of network connectivity. The sentinel interpretation assumes that the resolver can reach and validate the underlying signed DNS records.
The command line and browser disagree
Modern clients do not always share a single resolver. A browser may use DNS over HTTPS while operating-system tools use a local stub resolver. A VPN may intercept system DNS but not browser DNS, or the reverse. Containers may inherit a bridge-specific resolver. Cached responses can also obscure a recent change.
Identify each path instead of assuming that one terminal query represents every application. For browser-specific testing, use a readiness test that runs through the browser's actual resolution path, then compare it with command-line results from the same device.
Diagnose public Localtonet hostname failures in the right order
With Localtonet, the client application establishes an outbound connection to our relay infrastructure. A running tunnel provides a public URL or a public host and port, depending on the tunnel type. The tunnel is available only while the selected client or device is connected and the tunnel is running.
DNS resolution occurs before an application can connect to a hostname. As a result, a public tunnel can be correctly configured and running while a user behind a failing recursive resolver cannot resolve its hostname. Our platform does not control the trust-anchor state of the user's ISP, office, device, browser, or private recursive resolver.
The reverse is also true: successful DNS resolution proves only that the client obtained an answer. It does not establish that the tunnel is running, that the Localtonet device is connected, that the local target is reachable, or that the application is responding correctly.
A disciplined isolation workflow
Verify the service locally
From the Localtonet client device, confirm that the application responds at the exact local IP address and port configured as the tunnel target. This separates an application startup, bind-address, or local reachability problem from public DNS.
Confirm the selected Localtonet device is connected
Check the device associated with the tunnel. The Localtonet client must be running and connected because it establishes the outbound connection used by the tunnel.
Confirm the tunnel is running
A created tunnel is not automatically active. Verify that it has been started. If it is stopped, start it before investigating the hostname as though it represented a live endpoint.
Resolve the public hostname on the affected network
Query the exact public hostname from the device and network where access fails. Record the resolver used, status code, returned records, and whether the response differs from a working network.
Run the paired KSK-2024 sentinel test
If resolution fails only on particular networks, test those networks for RFC 8509 behavior. A reverse sentinel pattern can identify a resolver that does not trust KSK-2024.
Compare with another authorized network or resolver path
Test the same public hostname from a network known to work. If the tunnel succeeds there while the affected resolver returns DNS failure, focus on the failing DNS path instead of repeatedly changing the local application or tunnel.
For example, suppose the application works locally, the selected device is connected, the tunnel is running, and users on one mobile network can reach the public hostname. Users behind one office resolver receive a DNS error, and that resolver produces the reverse KSK-2024 sentinel pattern. Those observations strongly direct the investigation toward the office recursive resolver.
By contrast, if the hostname resolves consistently on every tested network but the connection is refused or the application returns an error, the root KSK trust anchor is unlikely to be the immediate cause. Continue with tunnel state, protocol, local target, listener, and application diagnostics.
Do not paste Localtonet authentication tokens, private endpoints, credentials, or sensitive configuration into public DNS-testing sites, tickets, or screenshots. A device token identifies the client that runs a tunnel and should be handled as a secret. Public reachability also does not replace application authentication, least-privilege permissions, or appropriate access restrictions.
Troubleshooting common DNSSEC rollover symptoms
The hostname fails only on one Wi-Fi or office network
This is a strong reason to compare recursive resolvers. Record the resolver used on the failing network, run the two sentinel queries, and repeat the hostname lookup from a working network. If the service is available elsewhere and the failing network reports that KSK-2024 is not trusted, escalate the resolver state to the network administrator.
Every hostname seems to fail, not just the tunnel hostname
A root trust-anchor problem can have broad consequences because the root is the start of DNSSEC validation across top-level domains. Test several unrelated signed names, check the sentinel pair, and inspect resolver logs. Also rule out basic connectivity, upstream DNS availability, and forwarding failures because broad DNS outages can produce similar user-facing symptoms.
The lookup returns SERVFAIL
SERVFAIL is not specific to stale trust anchors. It can represent DNSSEC validation failure, upstream failure, lame delegation, inaccessible authoritative servers, or another resolver-side error. Context matters. For an ordinary application hostname, compare results across resolvers and inspect validation logs. For the RFC 8509 negative sentinel, remember that SERVFAIL can be the expected successful result.
The lookup succeeds but the public endpoint still does not open
Move beyond DNS. Check that the Localtonet device is connected, that the tunnel is running, and that the local target is reachable from the client device. Confirm that the service listens on the address and port configured for the tunnel. Then inspect application authentication, protocol expectations, and service logs.
The resolver was upgraded recently
Verify trust-anchor state after the upgrade rather than assuming it was preserved. A package upgrade, migration, container replacement, image rebuild, or filesystem restoration can alter persistent RFC 5011 state. Use the resolver vendor's documented inspection and recovery process.
A monitoring system reports failure while users can connect
Monitoring agents may use a different resolver from user devices. Run the sentinel and hostname queries from the monitor's actual execution environment. This is especially important for hosted monitoring, containers, separate network namespaces, and servers with static DNS configuration.
Changing DNS records did not help
If the failing resolver cannot establish DNSSEC trust from the root, editing A, AAAA, CNAME, or TXT records does not repair its root trust anchor. Repeated DNS changes can add propagation and caching variables to the incident. Preserve the known-good application configuration while the resolver administrator repairs validation state.
Prepare DNS operations before October 11, 2026
Resolver readiness should be treated as an operational check, not a one-time desktop experiment. Inventory the recursive resolvers that support offices, production systems, remote access, monitoring, CI/CD environments, and customer-facing applications. Include forwarders and local stubs where they affect the path, but identify which component actually performs DNSSEC validation.
For each validating resolver, record its software and version, update mechanism, trust-anchor management method, persistent state location according to vendor documentation, and the person or team responsible for remediation. Test after upgrades, migrations, image rebuilds, failover events, and disaster-recovery exercises.
If the resolver reports that KSK-2024 is not trusted, follow its software vendor's current instructions. The correct repair may involve a software update, a built-in trust-anchor package, recovery of RFC 5011 state, or a product-specific trust-anchor procedure. There is no universal command that is safe for every implementation, so this guide does not invent one.
| Operational check | What to record | When to repeat it |
|---|---|---|
| Sentinel readiness | Resolver address, paired result, location, and time | Before the rollover and after resolver changes |
| DNSSEC validation status | Whether validation is enabled and where it occurs | After configuration or forwarding changes |
| Trust-anchor state | Vendor-supported status showing KSK-2024 or key tag 38696 | After upgrades, migrations, restores, and rebuilds |
| Application hostname resolution | Response status and records from representative networks | During readiness tests and incidents |
| Localtonet tunnel state | Connected device, running tunnel, and verified local target | Whenever DNS works but public access fails |
Save the successful sentinel pattern, the expected DNS response for important public hostnames, and the resolver addresses used at each site. During an incident, this baseline helps identify whether the change occurred in DNS resolution, tunnel state, local service availability, or application behavior.
Frequently asked questions
What is KSK-2024?
KSK-2024 is the new DNS root key-signing key identified by key tag 38696. It is scheduled to replace KSK-2017, key tag 20326, as the signer of the root DNSKEY record set on October 11, 2026.
Do I need to change my domain's A, CNAME, MX, or TXT records?
Normally, no. The root rollover concerns trust-anchor state in DNSSEC-validating recursive resolvers. Ordinary DNS records do not install the new root trust anchor. Domain operators should avoid changing otherwise correct records merely because a particular resolver has stale trust state.
What RFC 8509 result means that my resolver trusts KSK-2024?
For a DNSSEC-validating resolver with sentinel support, the expected trusted pattern is a valid response for the is-ta-38696 query and SERVFAIL for the not-ta-38696 query. Both results must come through the same resolver path.
If both sentinel names resolve, is my resolver ready?
That result is inconclusive. The resolver may not implement RFC 8509, or it may not perform DNSSEC validation. Check the resolver's documented capabilities and inspect its trust-anchor state through vendor-supported administrative tools.
Why can SERVFAIL be a good result in this test?
RFC 8509 uses deliberate SERVFAIL responses to signal trust-anchor state. When KSK-2024 is trusted, a sentinel-aware validating resolver deliberately rejects the not-ta-38696 query. For an ordinary application hostname, however, SERVFAIL remains an error that requires investigation.
Can a Localtonet tunnel be healthy while its public hostname fails on one network?
Yes. The selected Localtonet device can be connected, the tunnel can be running, and the local target can be healthy while a user's recursive resolver fails to return a usable DNS answer. Compare resolution and sentinel results across affected and working networks before changing the tunnel.
Does a successful DNS lookup prove that the Localtonet tunnel works?
No. It proves only that DNS returned an answer. The Localtonet client device must also be connected, the tunnel must be running, and the configured local target must be reachable and responsive.
Can Localtonet update my recursive resolver's root trust anchor?
No. Trust-anchor maintenance belongs to the recursive resolver used by the client network or application. Resolver administrators should follow their software vendor's supported instructions. Our role is to provide the public tunnel URL or host and port while the selected Localtonet client is connected and the tunnel is running.
Expose your service with Localtonet, then verify every layer
Run your service locally, connect the device to our platform, start the appropriate tunnel, and use the assigned public URL or host and port. If access differs by network, test DNS and KSK-2024 readiness before changing a healthy application or tunnel.
Get Started Free →
