When the .al top-level domain (TLD) went offline due to a broken DNSSEC key rollover, it highlighted how a single misconfiguration can disrupt access to an entire national namespace. To restore service, resolvers deployed a mechanism that intentionally bypassed DNSSEC validation, raising critical questions about trust, transparency, and resilience in modern DNS infrastructure.
In response, the 1.1.1.1 resolver now returns Extended DNS Error (EDE) 33 whenever DNSSEC validation is deliberately skipped. This gives operators, developers, and security teams clear visibility into when a resolver is no longer fully validating DNS responses—an important step toward more transparent and trustworthy DNS operations.
Key Takeaways
- A failed DNSSEC key rollover for .al temporarily broke name resolution for domains under that TLD, impacting users and businesses that rely on it.
- Resolvers restored service using a Negative Trust Anchor (NTA), which effectively told them to ignore DNSSEC failures for .al.
- 1.1.1.1 now returns Extended DNS Error 33 whenever DNSSEC validation is bypassed, making this behavior visible to clients and monitoring systems.
- Businesses and developers can use EDE signals to detect partial trust scenarios, adjust security policies, and improve incident response.
What Happened: A DNSSEC Rollover Gone Wrong
DNSSEC (Domain Name System Security Extensions) is designed to add cryptographic integrity to DNS responses. It ensures that the DNS answers you receive have not been tampered with in transit. To maintain security over time, DNSSEC keys are periodically changed—a process known as a key rollover.
In the case of the .al TLD, the DNS operator performed a DNSSEC key rollover that did not complete correctly. As a result, resolvers that strictly validate DNSSEC signatures could no longer verify responses for domains under .al. From the resolver’s perspective, the zone effectively became invalid.
Impact on Businesses and End Users
For organizations operating domains under .al, this misconfiguration meant that:
- Websites became unreachable for users behind validating resolvers.
- Email delivery and other DNS-dependent services were disrupted.
- Customers experienced outages that appeared similar to network or hosting failures, even though the root cause was at the DNS layer.
Because the issue occurred at the TLD level, the blast radius was large: every .al domain relying on DNSSEC-validating resolvers was at risk of downtime.
How Resolution Was Restored: Negative Trust Anchors
To quickly restore access while the TLD operator addressed the underlying DNSSEC issues, some resolvers, including 1.1.1.1, deployed a Negative Trust Anchor (NTA) for .al.
A Negative Trust Anchor is a configuration that instructs a validating resolver to temporarily stop enforcing DNSSEC validation for a specific zone, even if signatures appear invalid or missing. In effect, the resolver treats the zone as if it were not DNSSEC-signed at all.
Why NTAs Are Both Useful and Risky
NTAs are a powerful operational tool because they allow:
- Rapid restoration of DNS resolution when a signed zone is misconfigured.
- Minimization of downtime for businesses and users reliant on the affected domain.
However, they also introduce trade-offs:
- Reduced security: DNSSEC validation is intentionally disabled for the affected zone.
- Lack of visibility: Historically, clients had no direct way to know that DNSSEC was being bypassed.
- Extended risk window: If an NTA remains in place longer than necessary, it can leave a zone unprotected for an extended period.
By deploying a Negative Trust Anchor, resolvers choose availability over strict authenticity, but until now clients had to simply trust that decision without explicit evidence.
Making DNSSEC Bypass Visible: Extended DNS Error 33
To address the visibility problem, the 1.1.1.1 resolver now sends a specific signal when it bypasses DNSSEC validation due to a Negative Trust Anchor or similar configuration. This signal is known as Extended DNS Error (EDE) 33.
EDE codes are an extension to the DNS protocol that allow resolvers to attach more detailed error information to their responses. Instead of a simple “SERVFAIL” or success code, EDE gives clients insight into why a particular decision was made.
What EDE 33 Means
EDE 33 indicates that DNSSEC validation has been intentionally not performed for the response. In practical terms:
- The DNS answer is still returned so services can continue to function.
- The resolver is explicitly telling you that the usual DNSSEC guarantees are not in place.
- Security-sensitive systems can treat this response as lower trust or trigger specific alerts.
For businesses and developers, this distinction is critical. Instead of silently losing DNSSEC protections, you now have a machine-readable indication that the resolver is operating under an exception.
Why This Matters for Site Owners and Developers
Even if your organization does not directly manage a TLD, incidents like the .al outage affect your risk profile. Many businesses rely on DNSSEC for integrity assurance, and a resolver’s decision to bypass validation can influence how secure your users’ experience really is.
Stronger Monitoring and Incident Response
With EDE 33 in place, you can:
- Enhance DNS monitoring by tracking when DNS responses for your domains are returned with validation bypassed.
- Correlate outages and anomalies when users report issues that may be linked to DNSSEC or resolver behavior.
- Integrate EDE-aware logging into your observability stack, helping your team detect when dependent zones are operating outside normal security parameters.
For example, a security team could configure alerts whenever responses for key domains (such as login portals or API endpoints) are received with EDE 33. This would prompt further investigation into whether a misconfiguration, TLD issue, or intentional override is in play.
Better Risk Management for Critical Services
Organizations that run high-value or regulated services often rely on DNSSEC as part of their threat model. When a resolver bypasses validation:
- Security models that assumed end-to-end DNS integrity may no longer hold.
- Compliance or audit requirements around DNSSEC usage may be impacted.
- Failover and redundancy strategies may need to account for both availability and assurance.
By exposing EDE 33, 1.1.1.1 helps those organizations make more informed decisions, such as routing sensitive traffic through resolvers that continue to validate correctly, or temporarily restricting access to certain systems until DNS integrity is restored.
Practical Steps for Businesses and Developers
1. Audit Your DNSSEC Dependencies
Identify which of your domains and third-party providers rely on DNSSEC. This includes:
- Your primary domains and subdomains.
- DNS-based services such as email authentication (SPF, DKIM, DMARC) or service discovery.
- Critical partners whose domains are essential to your workflows or APIs.
Understanding where DNSSEC fits into your architecture will help you evaluate the impact of any future DNSSEC-related outages or bypass events.
2. Enable and Use EDE-Aware Tooling
Where possible, use DNS libraries, resolvers, or monitoring systems that can:
- Parse Extended DNS Errors, including EDE 33.
- Log these events with sufficient detail for troubleshooting.
- Trigger alerts when validation is bypassed for key zones.
For internal applications, developers can build logic that reacts to EDE codes—for instance, by marking a response as lower trust or falling back to stricter network policies when EDE 33 is observed.
3. Work with Your DNS and Hosting Providers
If you use managed DNS or web hosting providers, ask how they handle:
- DNSSEC key rollovers and automated validation checks.
- Communication and incident response in the event of a DNSSEC failure.
- Support for EDE reporting and visibility into resolver-side behavior.
Providers that implement robust DNSSEC practices and transparent reporting can significantly reduce the risk and impact of incidents like the .al outage.
Conclusion
The .al DNSSEC rollover incident is a clear example of how fragile the DNS ecosystem can be when cryptographic validation is misconfigured at scale. While Negative Trust Anchors provide a practical way to restore availability, they also temporarily undermine the security guarantees DNSSEC is meant to provide.
By returning EDE 33 when validation is bypassed, 1.1.1.1 introduces a crucial layer of transparency. Businesses, developers, and security teams now have actionable insight into when DNSSEC protections are not fully in effect, enabling more informed decisions about risk, monitoring, and mitigation.
For organizations that depend on reliable and secure DNS—and that is virtually every business with an online presence—understanding and leveraging these signals is increasingly important for maintaining both uptime and trust.
Need Professional Help?
Our team specializes in delivering enterprise-grade solutions for businesses of all sizes.