European Nameserver TLDs now available

Stupid question, mainly because my brain is having a Friday brain fart…

I’ve changed the NS on my registrar, do I need to update them in the deSEC zone too? The zone has the standard NS

Hi Faisal,

By the RFC letter, it would be better to, but it is not required. Some registries however insist (e.g., .it).

From a resolution perspective, it makes no difference, as the resolver first sees the parent-side NS records and resolves them into a set of IP addresses. Some resolvers would later attempt to also resolve the child-side NS, but they lead to the same set of IP addresses.

Stay secure,
Peter

1 Like

Hi Peter, I’ve been using these nameservers on my .eu domains for a couple of months now. No issues to report :slight_smile: maybe we can slowly move out of the “experimental” phase? Btw, did you get any respnse from deNIC regarding their outdated nameserver requirements?

We did get a response, and the root of the issue is a misreading of Technical requirements for authoritative name servers. We’re working on getting that addressed, see OARC 46 (Edinburgh, Scotland) (16-17 May 2026): Cross-addressed Nameservers · DNS-OARC (Indico).

Before making this official, we’d first like to resolve the DENIC issue as we’re otherwise foreseeing a lot of support requests.

We’re not planning to remove this functionality, so you can consider it “stable experimental”. :wink:

Stay secure,
Peter

1 Like

What I’m wondering here is, and please correct me if I’m wrong or misunderstanding this. If the domains of the european TLD solution, ns.desec.ch ns.desec.cz and ns.desec.li, themselves still depend on the old solution (ns1.desec.io and ns2.desec.org as their nameservers), which is currently the case, and say desec.org is somehow unavailable, leading to all queries going to anycast network 1 (ns1.desec.io), how does this help in the end? If anycast network 1 is overloaded due to the imbalance caused by the fictional unavailability of desec.org, would the domains of the european TLD solution then not also struggle to resolve, which in turn would lead to my domains using the european TLD solution also struggling to resolve?

No, that’s not actually true. Only the resolution of the European nameserver names ns.desec.{ch,cz,li} would be forced through ns1.desec.io in this case, but this process would then return all anycast addresses for the European nameserver names. So, for all queries for your domain (if it is delegated to European hostnames), both anycast networks would be used.

You’re right that his is a bottleneck. But, the service is still labeled as experimental, and it will remain so until it works across the board – which includes .de domains. To achieve that, DENIC needs to change their policy, and we can’t tell when that happens. So, for now, things will stay as they are.

You may be wondering why we’re not removing the ns1/ns2 dependency already now. The answer is that in that case, if our nameserver IP addresses ever change, we’ll have to remember to change them for the European nameservers, too. However, we’re not advertising them because they don’t work for .de, so they’re not really on our mind and we don’t want to run the risk of forgetting them during an address change.

FWIW, once .de allows this, I think there’s some chance we will even make these nameservers the default, without the ns1/ns2 dependency. Obviously, we can’t do that now unless we want to hear complaints from our .de users. :slight_smile:

Hope that makes sense!

Stay secure,
Peter

2 Likes

Thanks Peter, yes this helps! I see now, in my hypothetical scenario, the only “bottleneck” would be that with ns1.desec.io only one anycast network would be responsing to the queries of ns.desec.{ch,cz,li} but, as the result of this query contains both anycast network’s IPs, as soon as this query is successful, my domains would be served with the IPs of both anycast networks.