AKEP: Broken DNSSEC rollover makes .al domains unreachable

Company and product

AKEP is Albania’s communications regulator and the registry operator responsible for the .al country-code top-level domain.

The namespace is used by Albanian government institutions, banks, media organizations, businesses, universities, online services, and individuals. Because .al sits at the top of Albania’s national DNS hierarchy, a registry-level configuration failure can affect every domain beneath it.

DNS Security Extensions, or DNSSEC, add cryptographic verification to normal DNS resolution. For a signed top-level domain:

• The DNS root publishes a Delegation Signer record.
• That record identifies a trusted DNSKEY for the top-level domain.
• The authoritative nameservers publish the corresponding key.
• Validating resolvers compare the two records.
• A mismatch breaks the chain of trust and causes validation to fail.

What happened

Before the incident, the root DS record matched the DNSKEY published by the .al authoritative nameservers.

At approximately 14:15 UTC, AKEP published a new DNSKEY and stopped serving the previous key. The root zone had not yet been updated and continued pointing to key ID 26319.

When validating resolvers followed the chain of trust from the root, they could not find the referenced key on the .al nameservers. They therefore rejected .al responses and returned SERVFAIL.

The failure sequence was:

• AKEP published a new DNSKEY.
• The previous key was withdrawn too early.
• The root DS record still referenced the previous key.
• No published key matched the trusted root record.
• DNSSEC validation failed.
• Users began receiving resolution errors.
• Impact increased as valid cached records expired.

At approximately 17:00 UTC, AKEP removed the new DNSKEY but did not restore the previous key. This left .al with no DNSKEY records while the root still declared the zone DNSSEC-signed, so validation continued to fail.

At approximately 19:15 UTC, AKEP removed the .al DS record from the root. Resolvers then treated .al as unsigned and stopped requiring DNSSEC validation. Availability returned, but cryptographic authentication was no longer available for the top-level domain.

The incident became a widespread outage because DNSSEC is designed to fail closed. When the chain cannot be verified, resolvers reject legitimate answers rather than risk returning forged DNS data.

Timeline

• Approximately 14:15 UTC: AKEP published a new .al DNSKEY and withdrew the previous key, identified by key ID 26319.
• Approximately 14:15 UTC: The root DS record continued referencing the withdrawn key, breaking the DNSSEC chain of trust.
• After 14:15 UTC: Validating resolvers began returning SERVFAIL as cached records expired.
• Before 17:15 UTC: Cloudflare attempted to contact AKEP and alerted the DNS community through the DNS-OARC Mattermost channel.
• Approximately 17:00 UTC: AKEP removed the new DNSKEY without restoring the previous one.
• 17:15 UTC: Cloudflare completed deployment of a Negative Trust Anchor across all 1.1.1.1 users.
• After 17:15 UTC: Cloudflare users could resolve .al domains, but responses were not DNSSEC-validated.
• Approximately 19:15 UTC: AKEP removed the .al DS record from the DNS root.
• After 19:15 UTC: General resolution recovered because .al was treated as unsigned.
• July 4, 2026: Cloudflare removed its Negative Trust Anchor.
• July 14, 2026: Cloudflare reported that .al remained unsigned.
• As of August 5, 2026: The IANA root zone again contained a DS record for .al, using key tag 46645. 

Time to Detect (TTD): Not publicly disclosed.

Time to Resolve (TTR): Approximately five hours from the broken chain at 14:15 UTC until removal of the root DS record at 19:15 UTC. Cloudflare restored resolution for 1.1.1.1 users after approximately three hours.

Who was affected?

• Users accessing .al domains through DNSSEC-validating resolvers.
• Albanian government websites and public services.
• Banks and financial institutions.
• Media organizations and businesses.
• Universities and educational services.
• Email systems, APIs, and internal applications using .al hostnames.

The failure did not depend on where a service was hosted. Any domain beneath .al could become unreachable because validation failed at the parent top-level domain.

Impact varied according to resolver behavior and cache state. Resolvers with valid cached records could continue responding temporarily, while non-validating resolvers may have continued returning answers without DNSSEC protection.

How did AKEP and Cloudflare respond?

AKEP first removed the new DNSKEY at approximately 17:00 UTC, but this did not restore the missing previous key or repair the chain of trust.

At approximately 19:15 UTC, AKEP removed the root DS record. This restored availability by making .al unsigned.

Cloudflare initially returned SERVFAIL, as required by DNSSEC. After trying to contact AKEP and alerting the DNS-OARC community, Cloudflare deployed a Negative Trust Anchor.

The NTA temporarily instructed 1.1.1.1 to treat .al as unsigned. Cloudflare also returned:

• EDE 9 — DNSKEY Missing: Identified the broken DNSSEC chain.
• EDE 33 — Negative Trust Anchor: Disclosed that validation had been bypassed.

This restored resolution while making the security tradeoff visible to clients and monitoring tools.

How did AKEP communicate?

Cloudflare’s report does not identify a public AKEP incident report, status page, or prevention plan.

Cloudflare stated that it received no response when attempting to reach the operator. AKEP’s published contact addresses were themselves hosted beneath .al, meaning the same DNS failure could also disrupt the primary communication channel.

Cloudflare alerted the DNS operations community and later published the detailed technical report used as the primary source for this analysis.

Key learnings for other teams

• Preserve key overlap: Do not withdraw the previous key until the new DNSKEY and matching parent DS record have propagated and been externally validated.
• Treat rollovers as deployments: Require peer review, automated checks, monitoring, rollback procedures, and formal approval.
• Validate the full chain: Test from the root DS record through to the authoritative DNSKEY.
• Account for DNS caching: Propagation and cache lifetimes must be considered before withdrawing an old key.
• Maintain independent emergency contacts: Registry contact channels must not rely solely on the domain being operated.
• Use NTAs carefully: Negative Trust Anchors restore availability by temporarily removing DNSSEC protection.
• Disclose validation bypasses: Extended DNS Error codes help applications understand why validation was skipped.
• Track security recovery separately: Restoring resolution does not necessarily mean DNSSEC protection has returned.

Quick summary

On July 3, 2026, AKEP’s attempted DNSSEC rollover broke the chain of trust for Albania’s .al top-level domain. The operator published a new DNSKEY and withdrew key ID 26319 before the root DS record had been updated. Validating resolvers returned SERVFAIL as cached records expired. Cloudflare completed deployment of a Negative Trust Anchor to all 1.1.1.1 users by 17:15 UTC and used EDE 9 and EDE 33 to disclose the missing key and validation bypass. At approximately 19:15 UTC, AKEP removed the root DS record, restoring resolution but leaving .al unsigned. Cloudflare reported that state on July 14; by August 5, a new .al DS record had been added to the IANA root zone.

How ilert can help

DNSSEC failures can affect websites, email systems, and APIs while the underlying hosting infrastructure remains healthy.

• Alerting on validation failures: Route SERVFAIL, missing DNSKEY, DS mismatch, and signature-error metrics to ilert's reliable and actionable alerting to surface DNSSEC failures quickly.
• Grouping related symptoms: Consolidate alerts from websites, APIs, email, and synthetic probes into one DNS-level incident.
• Escalating to specialists: Notify DNS, network, platform, and security teams through dedicated escalation policies.
• Protecting emergency communication: Use ilert’s multi-channel alerting to reach responders through SMS, voice calls, push notifications, and messaging platforms that do not depend on the affected domain.
• Communicating impact: Use ilert Status Pages to explain that DNS resolution is failing while the applications themselves remain operational.
• Supporting the review: Use resolver metrics, alert history, incident timelines, and responder actions to reconstruct the rollover failure.