.de domains temporarily unavailable: What website operators can learn from the DNS disruption

What had happened?

Normally, accessing a website occurs in several background steps. When a user enters a domain, the computer or router queries a DNS resolver. This resolver determines which IP address belongs to the domain. Only then can the browser load the actual website from the web server.

During the .de disruption, this name resolution was specifically affected. DNS servers received error messages when resolving many .de domains. Importantly: the problem could initially not be easily bypassed for users by switching to another DNS provider such as Google DNS or Cloudflare 1.1.1.1. Essentially, all DNS resolvers that actively used DNSSEC validation were impacted.

The incident is classified by DENIC as follows: from around 22:00 on 5 May 2026, faulty DNSSEC signatures for the .de zone were published. Validating resolvers had to discard these responses and respond with SERVFAIL. As a result, affected domains could no longer be resolved correctly from many users’ perspectives.

Why this is so relevant for website operators

For website operators, the incident is especially important because it shows: a website can go down even if the own server is running smoothly.

Many initially think of common causes such as:

• Server failure at the web hosting provider
• Faulty website or incorrect CMS update
• SSL certificate expired
• Incorrect DNS zone configuration with the provider
• Issue with the user’s own internet connection

However, the .de incident highlights another level: the overarching domain infrastructure can also be affected. In this case, the problem was not within the individual DNS zone of a single domain, but at the level of the .de top-level domain.

This makes troubleshooting significantly more difficult. Because from the user’s perspective, everything looks the same: the website is unreachable. Whether behind this is a failure of the own web hosting, a DNS issue with the provider, a registry problem, or a local resolver issue, is hardly recognisable to laypersons.

DNSSEC: Security feature with a significant impact

DNSSEC is intended to cryptographically secure DNS responses. Put simply, a DNS resolver checks whether the response truly belongs to the respective zone and has not been manipulated en route. DNSSEC does not serve to encrypt data but to ensure integrity. The DNS response remains visible, but its authenticity can be verified through digital signatures. It was precisely this signature verification that caused issues during the .de outage: if the signatures were invalid, validating resolvers were not permitted to accept the responses.

However, this does not mean that DNSSEC has fundamentally failed. Rather, the incident highlights that security mechanisms within the DNS must be operated very carefully. If an error occurs high up in the DNS hierarchy, it can impact a very large number of domains simultaneously.

Tip: Earlier this year, we discussed the operation of critical infrastructure with Tom Keller from DENIC at domain pulse 26 in St. Gallen.

Why some websites were still accessible

It is also interesting that the outage was not equally visible everywhere. Some users could still access certain .de domains, while others could not.

One reason for this lies in DNS caching. DNS resolvers store responses for a certain period. If a domain was queried shortly before the outage, the IP address might still be in the cache. In such cases, the website could still be reachable.

Additionally, the principle of “Serve Stale” can come into play. Under certain conditions, resolvers can continue to serve expired but previously valid DNS responses if a fresh query fails. This helped to partially mitigate the impact of the outage. Without such mechanisms, the failure would have been more noticeable to many users.

Why switching DNS providers does not always help

For many DNS issues, using a different resolver, such as Google DNS, Cloudflare, or Quad9, can be beneficial. However, in this incident, that was only partially possible.

The reason: if the faulty signature originates from the .de zone itself, different DNS providers essentially receive the same flawed data. Resolvers with active DNSSEC validation must reject these responses.

Cloudflare later implemented a temporary countermeasure. The provider treated .de as if it were not DNSSEC-signed for a period. According to Cloudflare, this effectively acted as a Negative Trust Anchor. As a result, 1.1.1.1 was able to resolve .de domains again, but deliberately without DNSSEC validation for the affected zone. Cloudflare describes this decision as a trade-off between accessibility and security verification.

What does this mean for customers of web hosting providers?

For regular hosting customers, the most important realisation is: not every unavailability is automatically a fault of the web hosting provider.

A web hosting provider can technically do everything correctly in such a scenario:

• The web server is running.
• The website files are accessible.
• The SSL certificate is valid.
• The provider’s nameservers are functioning.
• The domain zone is correctly configured.

Nevertheless, the website may be inaccessible to many users if the resolution fails at a higher-level DNS stage.

For support teams of hosting providers, this is also challenging. Customers only see the outage and understandably contact their provider. The host must then quickly determine whether the problem lies within their own responsibility or if an external infrastructure is affected.

What website operators can learn from this

The incident demonstrates how important a fundamental understanding of the technical chain behind a website is. A domain is not just a name, but part of a multi-layered infrastructure.

To ensure a website’s accessibility, the following are among the key components:

• Domain registration
• Nameserver
• DNS zone
• DNSSEC configuration
• Registry infrastructure of the top-level domain
• DNS resolver of the users
• Web server
• SSL certificate
• Application or CMS

If one of these layers fails, the website can become unreachable. Therefore, it is important for operators not to simply consider outages as a “hosting problem”, but to narrow down the cause more precisely.

Monitoring should check more than just the web server

Traditional uptime monitoring usually checks whether a website is accessible via HTTP or HTTPS. This is important but not always sufficient.

The .de incident in particular shows that DNS aspects are also relevant. Therefore, monitoring solutions that do not only check the web server but also keep an eye on other technical layers are advisable:

• Website accessibility
• DNS resolution of the domain
• SSL certificates and expiry dates
• Nameserver responses
• HTTP status codes
• Loading times
• External status updates from key infrastructure providers

Even more important is the correct interpretation of warning messages. If many .de domains are affected simultaneously, the cause is probably not with a single web hosting provider. Good monitoring helps to differentiate more quickly between local problems, hosting issues, and broader DNS disruptions.

On a personal note: Let hosttest Plus inform you at any time and free of charge about outages — via email, SMS or call. 

Emails can also be affected

DNS is not only required for websites. Email services also depend on DNS records. If a domain cannot be resolved correctly, mail servers, MX records or other domain-related services can also be impacted.

This is especially critical for companies. An inaccessible website is already problematic. If emails cannot be reliably delivered in addition, it affects customer communication, orders, support requests and internal processes.

Why status pages and transparent communication are important

In the event of a widespread infrastructure issue, quick communication is crucial. website operators need to know whether they need to take action themselves or if they should wait for a central authority to resolve the problem.

Heise documented the incident very early with specific technical details and, among other things, pointed to faulty DNSSEC signatures. Cloudflare later provided a technical post-mortem with insights into resolver behaviour, caching, SERVFAIL responses and temporary countermeasures. Such assessments are important for operators, agencies and hosting providers because they help to evaluate the situation accurately.

For web hosting providers, this results in a clear task: During major external disruptions, customers should be informed as quickly as possible, even if the cause is not directly with the host. This reduces support inquiries and builds trust.

Conclusion: The .de outage was more than just a technical glitch

The temporary inaccessibility of many .de domains was not a typical hosting failure. It was an example of how dependent websites are on central DNS structures.

The most important lesson for domain and hosting users: a website is not just about the webspace alone. Domain, DNS, DNSSEC, resolver and registry infrastructure are equally critical for accessibility.

Web hosting customers should therefore not only focus on storage space, price and support, but also on how professionally a provider handles DNS, monitoring, status updates and technical communication. Because in an emergency, it’s not just about having control over your own infrastructure. What matters is how quickly the provider detects, assesses and informs about external disruptions.