Nameserver on just one TLD: Bad Idea

The DENIC DNSSEC incident as a warning sign

DNS is often regarded as ‘invisible infrastructure’ – until it fails. This is precisely what was demonstrated by the incident in which DNSSEC issues temporarily led to significant connectivity problems. Many domains under .de were affected or at least potentially at risk. It was particularly problematic for operators who also ran their authoritative nameservers exclusively under .de.

This is because such situations create a classic single point of failure:

• The domain itself is not under .de
• The nameservers are called, for example, ns1.example.de and ns2.example.de
• The resolution of these nameservers, in turn, depends on the functionality of the .de zone

If the TLD infrastructure or its DNSSEC chain fails, it may not even be possible to resolve the nameserver name itself even when generally the domain wouldn't be affected.

Consequently, it is not just the .de domains that fail, but all of the company’s domains.

The problem is structural – not technical in the strict sense.

The hidden risk: dependence on a single registry

Although many companies distribute their nameservers geographically or across different providers, they overlook a crucial aspect:

dependence on the same TLD registry.

For example, anyone using the following nameservers:

• ns1.provider.de
• ns2.provider.de

still has a shared dependency despite having two servers:

• the same TLD (.de)
• the same registry (DENIC)
• the same DNSSEC trust chain
• the same registry operator

If problems arise there, the redundancy of the individual nameservers is of little help.

Why different TLDs are significantly more robust

A setup becomes significantly more resilient if the nameservers are operated under different TLDs, for example:

• ns1.provider.de
• ns2.provider.net

This distributes critical dependencies across different infrastructures:

An error in a registry does not automatically affect all authoritative name servers simultaneously.

Two TLDs are not always enough – if they come from the same operator

A common misconception is:

“We use .com and .net, so we’re covered.”

That is only partly true.

This is because .com and .net, for example, are both operated by Verisign. Consequently, a shared operational dependency still exists:

• same registry infrastructure
• similar operational processes
• potentially shared sources of error
• same organisational responsibility

A serious error or a DNSSEC issue at the operator could therefore still affect both TLDs simultaneously.

The same applies to other TLD groups under joint administration.

True resilience means: Different registries

A robust nameserver design therefore takes into account not only different TLDs, but also different registry operators.

For example:

This distributes risks across multiple levels.

DNSSEC makes the chain more vulnerable

With DNSSEC, security increases – but so does the complexity of the chain of trust.

If a TLD is affected by faulty signatures, key rollover issues or validation errors, resolvers may reject the entire resolution.

The problem then affects not only the actual domain, but potentially also the nameserver names themselves.

This is precisely why diversification across different TLDs and registries is becoming increasingly important.

Best practices for resilient DNS infrastructures

Operate nameservers under different TLDs

Not just:

• ns1.example.de
• ns2.example.de

but, for example:

• ns1.example.de
• ns2.example.net

Choose different registry operators

Ideally, use a combination of different operators:

• DENIC (.de)
• Verisign (.com, .net)
• PIR (.org)
• EURid (.eu)
• etc.

Use different DNS providers

It becomes even more robust with:

• different authoritative DNS providers
• separate networks