European Nameserver TLDs now available

1

Hi all,

We have just set up the following nameservers:

  • ns.desec.ch
  • ns.desec.cz
  • ns.desec.li

Technical Details

Each of these nameserver hostnames points to the IP addresses of both anycast networks; there is no distinction between ns1 and ns2. (When you resolve the above names, you will see that you get the IP addresses of both ns1.desec.io and ns2.desec.org).

This provides some extra resilience so that both anycast networks continue to receive queries even when one of the nameserver hostnames does not resolve for any reason. For technical background, see the explanation of a similar feature by Cloudflare.

Note that some registries will not let you use such nameservers in a delegation, because they insist that nameserver hostnames must point to distinct IP addresses. Known cases are .de and .no; if you find any others, please let us know!

Why these TLDs

We are aware that our name is also available under other European TLDs. We have picked .ch, .cz, and .li because these registries are at the forefront of advancing secure DNS.

In particular, they have led the pack of European ccTLDs for implementation of automated DS provisioning, and we’d like to acknowledge their engagement by using those names in public.

We’d also like to acknowledge .sk, another European ccTLDs that uses DS automation. Unfortunately, that suffix is not supported by our registrar.

Note that .li and .ch are both run by SWITCH. Depending on what redundancy you want, make sure to pick an organizationally diverse set of hostnames.

We will be happy to include other European ccTLDs in our set of nameservers, and we promise to do so once the associated registry supports DS automation! :slight_smile:

Status

Service under the above hostnames is currently experimental.

We expect that it will work at least as reliably as the existing service, so you can feel confident using it. However, we’d like to collect some user feedback before removing the experimental label – so, please let us know about your experience!

(Once the experimental label is removed, we’ll also make the classic ns1 and ns2 subdomains available with the new TLDs.)

Stay secure,
Peter

6 Likes
2

Awesome improvement, great work, thanks a lot!

3

Thanks Peter! Yeah I can confirm that these experimental nameservers are not accepted by DENIC. Unfortunately, I only use .de Domains :smiley: Looking forward to you deploying the classic ns1and ns2setup on these domains. Concerning the setup, I need to manually change NS records in my zone, correct? Other changes required (SOA)?

4

I also see that the new domains themselves still depend on ns1.desec.io and ns2.desec.org as nameservers. Wouldn’t it make sense for them to use glue records to get rid of this dependency?

5

Surprisingly, Denic accepts the io and org nameservers, but when you add one of the new names as a third, without removing either of the old ones, suddenly those same ip addresses are no longer diverse enough.

Anyway, if you’re OK with glue records, you can create names for the Desec nameservers under your own domain and use those names in the parent registry, thus making you independent of all other TLD registries.

(If you do this, monitor the IP-address records of the official nameserver names, as they may change.)

2 Likes
6

It looks like something is not properly aligned for the ch. zone. I’ve tried to update two domains I have control over (flavus.ch registered at Infomaniak and onschool.ch registered at DNSimple) to update their Delegation (pointing the NS records in the ch. zone to both ns.desec.ch and ns.desec.cz (I’ve tried with and without the trailing .)), but it fails in both cases:

  • Infomaniak’s manager spits an “unknown error”, but their support says:

    It looks like the server is not declared at Switch; you need to check this with desec.

  • DNSimple’s manager says either

    • The registrar could not complete this operation: Invalid attribute value; nameserver “ns.desec.ch” does not exist

    • The registrar could not complete this operation: Invalid attribute value [domain:hostobj => ns.desec.ch: The host:name does not exist]

7

Hi eric,

Yes, you should update your NS records. No other changes are needed.

Stay secure,
Peter

2 Likes
8

Hi eric,

Yes, we’ll change that when the experimental phase ends, and make them only depend on themselves.

The current dependency is not harmful, however, as resolver would look up the hostnames ns1.desec.io and ns2.desec.org, and validate their IP addresses with DNSSEC. So, it is a structurally unnecessary dependency, but (nearly) irrelevant in terms of security.

Note that glue would not really help, as glue records are not signed.

Stay secure,
Peter

2 Likes
9

Hi OdyX,

Interesting. That’s what the experimental phase is for :slight_smile: We’ll reach out to .ch and figure out what’s going on.

Thanks for reporting this!

Stay secure,
Peter

2 Likes
10

Not sure if this will help: I receive the following EPP response when I try to add ns.desec.ch, ns.desec.li and ns.desec.cz as name servers to a .ch-Domain. The DNS zone was created at deSEC and the NS entries were adjusted to the same entries.

EPP Response 
<?xml version="1.0" encoding="UTF-8"?>
<epp
	xmlns="urn:ietf:params:xml:ns:epp-1.0">
	<response>
		<result code="2308">
			<msg>Data management policy violation</msg>
			<extValue>
				<value>
					<domain:hostObj
						xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">ns.desec.li
					</domain:hostObj>
				</value>
				<reason>The host:name does not exist</reason>
			</extValue>
		</result>
	</response>
</epp>

I looked in the EPP manual, but couldn’t figure out what the problem might be.

1 Like
11

Hi,

We’ve worked with the registry, and the nameserver hostnames are now lodged in their systems and thinks should™ work. Can you try again?

Stay secure,
Peter

1 Like
12

I can confirm that both onschool.ch, liip.ai (via DNSimple) and flavus.ch (via Infomaniak) have gotten correct NS records.

The only minor issue is that creating domains in desec.io always creates NS records pointing to the “traditional” NS records, even via opentofu/terraform. To update the NS records programmatically, one needs to delete them separately first, then push. (The alternative is to consider the NS records “not handled by the as-code infrastructure”, and just update them manually in the desec.io web interface). I wish the desec API allowed specifying the NS records (or disable their automated creation).

13

That’s an interesting proposal. Feel free to open a feature and/or pull request for this on GitHub!

Stay secure,
Peter

2 Likes