If .my websites will not load on a Malaysian connection, there are two possible causes, and only one has anything to do with your network. At 14:00 UTC on 11 October 2026, the key that signs the DNS root zone changed. It is the root KSK rollover, only the second in the system’s history. Any validating resolver that had not learned the new key started failing names that worked fine the day before.
That part is documented by ICANN. The Malaysian side is murkier: over 11 to 13 October, users reported lookups that slowed, timed out or returned nothing. We could not confirm a network-wide outage on any provider, including Maxis, and we will not pretend otherwise.
Malaysia has its own history of DNS interference: the regulator’s 2024 redirection order. To a non-technical user it looks the same. A site that will not load. Telling the two apart is the point of this article.
Last updated: 14 October 2026. This article reports a documented technical event, the official timeline behind it, and the Malaysian user reports that followed. It states plainly what we could and could not confirm.
What happened on 11 October: the root KSK rollover
A root KSK rollover is a scheduled change to the key that anchors DNSSEC, and it happened on 11 October 2026. When a resolver has not trusted the new key, lookups fail. That is why some Maxis DNS and broader .my reports point at an outage rather than at the domain itself.
DNS turns a domain name into the address a device connects to. DNSSEC lets a resolver verify that the answer is authentic. That chain of trust begins at the top, with a key called the root Key Signing Key, or KSK, which signs the root zone. Replacing it is routine security work, but it is done slowly, because a resolver that is not ready cannot validate anything. A .my name resolves through the same chain, starting at the root; our guide to how .my domain nameservers work covers the specifics.
ICANN published the new key, KSK-2024, into the root zone on 11 January 2025, about 21 months before it would be needed, so operators had time to adopt it. On 11 October 2026 at 14:00 UTC, KSK-2024 took over signing the root zone.
| Key | KSK-2017 (outgoing) | KSK-2024 (new) |
|---|---|---|
| Key tag | 20326 | 38696 |
| Generated | 27 October 2016 | 26 April 2024 |
| In the root zone | Signing since 11 October 2018 | Published 11 January 2025 |
| Signs the root zone | Until 11 October 2026 | From 11 October 2026 |
| Next step | Revoked 11 January 2027, removed 22 March 2027 | Active |
Timeline from IANA’s trust-anchor record. Source: IANA, Trust Anchors and Rollovers, iana.org/dnssec/files.
The same page tells resolver operators to verify that KSK-2024, key tag 38696, is present in their trust-anchor configuration, and not to assume the automatic update worked.
Is it you, or is it your provider?
A resolver caches the root’s set of keys rather than re-fetching them on every query. The root DNSKEY record set carries a 48-hour time-to-live. A resolver that cached the old set just before the switch kept working until that cache expired, and only then failed if it did not already trust the new key. That is why the failure window is not a moment but a spread of roughly two days, Sunday into Tuesday. As ICANN’s guidance says, the timing of any individual failure cannot be predicted.
That is how a Monday-morning mess happens: one business, some staff online and some not, and a call-centre spike in “site is down” tickets for sites that are demonstrably up. Nobody connects it to a key change that happened quietly over the weekend. The cause and the symptom are two days apart, and nothing in the symptom points back. It is the same kind of platform change that lands without warning.
One detail settles the question of blame. A validating resolver without the current root key fails for every name, including unsigned ones, because the proof that a zone is unsigned is itself signed by the chain above it. Akamai’s guidance is blunt: such a resolver “will fail to resolve both signed and unsigned domains, leading to widespread SERVFAIL errors.” If everything fails but the same sites open on mobile data, the resolver is the suspect, not the sites.
How to check your DNS in 2 minutes
Here’s the fastest way to tell. Query a name you use daily, then query it again with validation switched off; +cd sets the checking-disabled bit for that one query.
dig @127.0.0.1 example.com A +noall +comments +answer
dig @127.0.0.1 example.com A +cd +noall +comments +answerReplace 127.0.0.1 with the resolver you are testing, and match the status: lines against this.
| What you see | What it means | Where to look |
|---|---|---|
SERVFAIL on every name, but answers return with +cd | The data is reachable; validation is failing everywhere at once | The root trust anchor, and the fixes below |
| Some names fail, others resolve | The root key is unlikely to be the cause | The failing domains’ own zones |
SERVFAIL even with +cd | You skipped validation and it still failed | The network path: upstream reachability, port 53, tunnels |
Triage logic from resolver-repair guidance built on Akamai’s and ICANN’s operator notes. Source: SSD Nodes, DNSSEC fails after KSK-2024 rollover.
The first row is the signature of a missing root anchor: everything fails at once, and everything returns the moment validation is waived. The second check confirms it. RFC 8509 defines sentinel names that a validating resolver answers based on its own trust-anchor state; dnstest.dev publishes the labels for KSK-2024.
dig root-key-sentinel-is-ta-38696.dnstest.dev A +noall +comments +answer
dig root-key-sentinel-not-ta-38696.dnstest.dev A +noall +comments +answer| is-ta-38696 | not-ta-38696 | Verdict |
|---|---|---|
| NOERROR | SERVFAIL | Trusts KSK-2024, the healthy pattern |
| SERVFAIL | NOERROR | Does not trust KSK-2024, this is the fault |
| Answers | Answers | Inconclusive; may not validate or support sentinels |
| SERVFAIL | SERVFAIL | A resolver that never learned the key cannot validate dnstest.dev either |
Sentinel interpretation per Cloudflare’s RFC 8509 documentation and SSD Nodes’ resolver guide. Source: Cloudflare, RFC 8509 root key trust anchor sentinel support, 24 September 2026.
A deliberate SERVFAIL is a pass, not a failure, and it is the most misread result. The not-ta-38696 query asks whether the key is not trusted; on a healthy resolver that is false, so SERVFAIL is correct. Two things can muddy the result: test the path your device actually uses, since a query to 1.1.1.1 says nothing about your office resolver or a container; and wait up to five minutes after a fix, because SERVFAIL can be cached.
How to fix SERVFAIL: BIND, Unbound, Pi-hole, OpenWrt and Windows
Every resolver wants the same thing: the current root anchor, from IANA itself, and a way to keep it. A key pasted from a forum post or a blog, including this one, is not a source. BIND keeps it in bind.keys; Unbound in root.key, which unbound-anchor refreshes from IANA and verifies; Knot in root.keys; systemd-resolved ships with it built in.
Start by updating the resolver package. Current BIND, Unbound, Knot and PowerDNS Recursor builds ship KSK-2024, so a restart often ends it. If you cannot upgrade, load the anchor by hand from IANA and reload. Then re-run the sentinel test; do not assume the fix took.
PowerDNS Recursor is the one to single out: its documentation says it does not support RFC 5011 automatic rollover and does not save a changed root anchor to disk, so a newer package is the normal route to KSK-2024. For home setups, a Pi-hole or AdGuard Home in front of Unbound is a forwarder, and a forwarder with a different trust state than its upstream can return mixed results. Test the Unbound instance directly, on its own port. Then test the Pi-hole address your clients actually use. On OpenWrt, update the firmware or point the forwarder at a public resolver that already trusts the new key, then re-test from a client behind it.
On Windows the anchor is usually handled upstream; what users notice is a stale negative cache, cleared with ipconfig /flushdns. That helps with cached failures, not a genuinely missing anchor.
Where to get the anchor: IANA publishes the root trust anchors as a signed file at iana.org/dnssec/files. Retrieve from there, or let your resolver’s own tool fetch and verify it. Never copy a key by hand from a secondary source.
For businesses: mail servers, VPNs and shadow resolvers
The rollover is an operator problem, so the businesses that felt it ran their own resolution. Find every resolver you own; the one you forgot is the one that fails.
- Self-hosted recursive resolvers: Unbound, BIND, Knot, PowerDNS Recursor, systemd-resolved with validation on.
- Mail servers and edge devices: appliances that do their own lookups sit outside the resolver your IT team remembers.
- Shadow resolvers: the one baked into a golden image, a container base layer, a VPN concentrator or a branch router. The most common source of a partial outage, set up once and never revisited.
What matters more than any fix: test from every network that depends on a resolver, whether office, branch, VPN path or container, because readiness belongs to the resolver, not the hostname. Keep a heartbeat too. A scheduled sentinel check catches the next rollover before your users do.
When will it be fixed — and what changes next
There is no single date, and anyone who gives you one is guessing. It depends on the resolver in front of you. If you use your provider’s DNS or a public resolver, the fix is theirs, and you will know it has been made when the checks come back clean. Most people need to change nothing.
If it has not cleared, narrow it down first: does it fail on mobile data as well as wi-fi? For every site or only some? Does an encrypted-DNS setting solve it? Only the last points at the rollover. As a workaround, encrypted DNS (DNS over HTTPS or DNS over TLS) carries the lookup inside ordinary encrypted traffic, at the cost of a slightly slower first lookup. Or simply point the device at a public resolver that already trusts the new key: both 8.8.8.8 and 1.1.1.1 returned the healthy sentinel result in our test on 14 October 2026. The dates that do matter are in the final section.
It’s not MCMC’s DNS redirect: two events everyone keeps mixing up
Malaysia has a second, separate reason a lookup may not return the answer you expect, and it dates from 2024. In September 2024, the Malaysian Communications and Multimedia Commission directed internet service providers to redirect traffic aimed at third-party public DNS services such as Google’s 8.8.8.8 and Cloudflare’s 1.1.1.1 back through the provider’s own resolvers. The compliance deadline for business, government and enterprise users was 30 September 2024.
When a blocked domain is queried, the redirect returns a holding address instead of the real one; on Maxis, historically a CNAME naming mcmc-redirect.maxis.com.my. The Commission’s statement of 7 September 2024 said 24,277 sites had been blocked between 2018 and 1 August 2024. By category: gambling 39 per cent, pornography 31 per cent, copyright infringement 14 per cent, other 12 per cent, prostitution 2 per cent, and illegal investment or scams 2 per cent. It said legitimate sites were unaffected, and Maxis said the change did not affect users on a private or encrypted DNS service. We traced how Malaysian blocks and appeals work separately.
Set side by side, they stop looking alike.
| Question | Root KSK rollover | MCMC DNS redirection |
|---|---|---|
| Layer | DNS technical, global; ICANN and IANA | Malaysian policy, the regulator |
| Began | 11 October 2026, 14:00 UTC | 2024, deadline 30 September 2024 |
| What changes | Which key signs the root zone | Which server answers a public-DNS query |
| Who must act | Operators of validating resolvers | Internet service providers |
| Symptom | Every name may fail: SERVFAIL, signed or not | Selected sites hit a holding page; others are fine |
| Fixes it | Update the root trust anchor | Encrypted DNS, or an un-redirected path |
The two mechanisms, side by side. The rollover is an ICANN/IANA technical event; the redirection is a 2024 Malaysian regulatory measure. They share a symptom and nothing else. Sources: ICANN and IANA for the rollover; MCMC statement of 7 September 2024, reported by Bernama, for the redirection.
You can see why people merge them: a user types an address, gets no page, and concludes “DNS is broken.” But the rollover breaks everything through a resolver that is not ready, and is fixed by updating a key. The redirection breaks selected destinations, is applied by the provider, and is worked around with encryption. We cover that policy separately in MCMC’s DNS redirection policy and the online-safety tactics behind it; if your problem is specific sites rather than everything, read that, not this.
What we could not confirm about Maxis — and what ICANN did confirm
What is established: the rollover happened, at a documented time, with a documented key tag; the 48-hour window and the SERVFAIL consequence are ICANN’s own description; the 2024 redirection is on the record, with a deadline, a landing hostname and the Commission’s figures.
What we could not confirm: reports over 11 to 13 October of a broad DNS outage on Maxis broadband. We searched Malaysian media over that window (The Star, Bernama, The Edge, SoyaCincau and Lowyat) and found no first-party confirmation from Maxis, the Commission, or the press; the claim traces to user reports on outage trackers, Reddit and Facebook. We also could not test Maxis’s resolvers directly, because queries to them did not return from our vantage point, so we cannot say whether they held the new key. Some Malaysian users reported failures; we could not verify a provider-wide cause.
A few more claims we could not verify: reported latency increases, and certain domains such as .xyz and vercel.app being disproportionately blocked. Neither fits the rollover’s shape; a missing root anchor fails every name equally. Selective blocking looks far more like the redirection regime above than a key change. We report them as user reports, not findings.
ICANN had not reported a widespread disruption at the time of writing; its status update says none have been observed, and it continues to monitor. That is the only global, first-party position so far.
Is Maxis DNS down right now?
We could not confirm a network-wide Maxis DNS outage. Some users reported slow or failed lookups from 11 to 13 October 2026, but no first-party confirmation exists from Maxis, the Commission, or the press. A resolver missing the new root key fails every name; anything narrower is usually not the rollover.
Why can’t I open .my websites?
The most likely technical cause is a resolver that has not learned the new root key, KSK-2024. A validating resolver without it returns SERVFAIL for every name, including .my. If only specific sites fail, the cause is likelier local blocking than the rollover.
What is a KSK rollover?
A KSK rollover is a scheduled change to the root Key Signing Key, the key that anchors DNSSEC at the top of the DNS. KSK-2024 (key tag 38696) replaced KSK-2017 (key tag 20326) on 11 October 2026. It is the second such rollover in the system’s history.
How do I check if my resolver trusts KSK-2024?
Query the RFC 8509 sentinel: dig root-key-sentinel-is-ta-38696.dnstest.dev A and the not-ta-38696 equivalent. NOERROR on the first with SERVFAIL on the second means the resolver trusts KSK-2024. Both answering, or both failing, is inconclusive.
How do I fix SERVFAIL?
Update the resolver package first; current BIND, Unbound, Knot and PowerDNS Recursor builds ship KSK-2024. If you cannot upgrade, load the trust anchor from IANA by hand and reload. Then re-run the sentinel test to confirm. Never copy a key from a blog or forum post.
What is MCMC’s DNS redirect, and is it the same thing?
No. MCMC’s DNS redirect is a 2024 Malaysian policy that sent public-DNS queries back through provider resolvers. The 2026 root KSK rollover is a separate global ICANN/IANA technical change to the key signing the root zone. They share a symptom, a site that will not load, and nothing else.
What to watch next: 11 January and 22 March 2027
The rollover is not finished. KSK-2017 is scheduled to be revoked on 11 January 2027 and removed from the root zone on 22 March 2027, two dates resolver operators should already have noted. Revocation is the step where a resolver holding only the old anchor stops being able to rely on it at all.
Then there is the round after this one. The next rollover is expected to change not just the key material but the algorithm, from RSA to ECDSA. That is the reason to treat readiness as a standing process rather than a one-off: build the sentinel check into monitoring now, and the next change is a non-event instead of an incident.
And watch the local record. If Maxis or MyNIC publishes a statement about the 11–13 October window, it will settle the question we could not. Until something first-party appears, the responsible position is the one we have taken: the rollover is fact, the Malaysian outage reports are user reports, and the redirection is a different thing entirely.
Sources
- ICANN, Root Zone KSK Rollover — Status Update (KSK-2024 began signing 14:00 UTC, 11 October 2026; key tag 38696) — icann.org/resources/pages/ksk-rollover-en
- IANA, Trust Anchors and Rollovers (KSK-2024 published 11 January 2025; rollover 11 October 2026; KSK-2017 revocation 11 January 2027; removal 22 March 2027; key tags 20326 and 38696) — iana.org/dnssec/files
- ICANN, press release ICANN Publishes Guidance to Help Prepare for the October 2026 Root KSK Rollover, 11 August 2026 — icann.org/resources/press-material/release-2026-08-11-en
- ICANN, press release ICANN Announces Next Major Internet Security Update, 20 May 2026 — icann.org/resources/press-material/release-2026-05-20-en
- ICANN, guide What to Expect During the Root KSK Rollover, 27 July 2026 (48-hour DNSKEY TTL; SERVFAIL consequence) — icann.org — ksk-rollover-expect-27jul26-en.pdf
- Cloudflare, RFC 8509 root key trust anchor sentinel support, 24 September 2026 — developers.cloudflare.com
- dnstest.dev, KSK-2024 sentinel names — dnstest.dev/ksk-2024
- SSD Nodes, DNSSEC fails after KSK-2024 rollover (key 38696) (the
+cdtriage; Pi-hole forwarder caveat; five-minute SERVFAIL cache) — ssdnodes.com - MCMC, media statement MCMC Addresses Misinformation on DNS Redirection and Internet Access Restrictions, 7 September 2024 (24,277 sites; category breakdown) — mcmc.gov.my
- The Star, MCMC orders DNS redirection for businesses, govts, enterprises by Sept 30, according to Maxis FAQ, 5 September 2024 (deadline; mcmc-redirect hostname; encrypted-DNS exemption) — thestar.com.my
- Bernama, DNS redirection reporting, 6 September 2024 — Bernama, 6 September 2024
- Own measurement, 14 October 2026: RFC 8509 sentinel queries returned NOERROR on 8.8.8.8 and 1.1.1.1; the .my apex resolved via public resolvers (NOERROR); direct queries to Maxis resolvers did not return from our vantage point. Read-only diagnostic; changes nothing.
BD Media is the editorial desk of Big Domain. This article describes a documented technical event, the official timeline behind it, and the user reports published elsewhere. It is not legal or regulatory advice. Where we could not verify a claim, we have said so. Readers running a resolver should confirm its state with the RFC 8509 test rather than taking any article’s word, including ours.
