Support for Handshake names

Hi. I’m trying to host a zone for a Handshake name on deSEC. From what I can tell, it is possible to add second-level domains (my.whatevername.), but not the name itself (whatevername.).

It’s great that deSEC does not limit to domains with an ICANN tld like other services and hopefully will be able to host records for just the name too.

Adding 2 domains (say apple.whatevername. and orange.whatevername.) is possible right now as the NS required to be added in the registry is the same (ns1.desec.io and ns2.desec.org). The problem is when setting up DS records. 2 different domains on deSEC ask different DS records to be added.

So if deSEC allows adding the name itself (whatevername. in the example), then a common DS record would work for all “sub” domains.

To be clear, deSEC does not have to interact with Handshake at all, only allow the name to be added, not just SLDs.

What is Handshake?

Handshake is a UTXO-based blockchain protocol that manages the registration, renewal, and transfer of DNS top-level domains (TLDs). Our naming protocol differs from its predecessors in that it has no concept of namespacing or subdomains at the consensus layer. Its purpose is not to replace DNS, but to replace the root zone file and the root servers.

Official website: https://handshake.org/ Documentation: https://hsd-dev.org/

[nils-wisiol]

Without knowing the details of Handshake, I’m assuming it would be sufficient to add the DS records for name, instead of adding all DS records for the second-level domains. Once the DS records for name are added, authenticity of DNS information of x.name can be proved by going through the DNSSEC signature chain.

If that’s a misunderstanding or somehow not supported by Handshake, then you’d have to wait for the above-mentioned features of deSEC or resort to a different choice.

Let me know if you have further questions or comments!

[rithvikvibhu]

If someone owns a domain name and claims the corresponding zone at deSEC, we will verify the identity and assign the zone to that person.

This is manual and not automated, right? Because anyone can add zones without verifying it right now. In fact, I added one handshake sld (and gonna try the DS inheritance @nils-wisiol suggested in https://github.com/desec-io/desec-stack/issues/479#issuecomment-731100122).

If ICANN later assign the same TLD to some registry, then we will have to a) either reject that, keeping the Handshake TLD operational, or b) accept that, breaking the Handshake TLD.

That is true. ICANN has completed the first phase of the new gTLD program and is currently “reviewing and carrying out a policy development process”. As no new gTLDs will be assigned for a while, Handshake hopes to gain traction during this time.

As a DNS hosting service, it is understandable to stick with the ICANN root as that’s what most resolvers look for right now.

This conflict is intrinsically different from the non-Handshake scenario. I see no way out of collisions between the DNS root and an “alternative root”. To not break things, it seems to me that we therefore should stay away from assigning TLDs which may later lead to a conflict that cannot be resolved in a non-breaking manner.

As @peterthomassen mentioned for non-handshake names, “If someone owns a domain name and claims the corresponding zone at deSEC, we will verify the identity and assign the zone to that person.”

Why not let non-ICANN slds(/tlds) stay as they are right now? If in the future, a new TLD is released by ICANN, all zones (whether a root name or an sld) of that tld hosted on deSEC can have a grace period to verify (with a TXT record). The release schedule by ICANN will provide ample time to inform zone holders and will only happen when new TLDs are released (which is not happening right now).

Basically, yes to verification with ICANN root, but only when the TLDs are released.

I see 2 ways to do this:

1. ICANN releases a TLD .name. User A already has a handshake sld bob.name and is hosting with deSEC. a. deSEC has a grace period for when all .name and *.name zones need to be verified by setting a TXT record in the ICANN root. b. User A may want to purchase bob.name from ICANN as they already have the same name on handshake. They do so within the grace period and verify it with deSEC. The zone continues to stay with deSEC. c. If User A does not verify within the period, the zone is removed. deSEC wants the whole zone cleared to make way for regular domains.

2. ICANN releases a TLD .name. User A already has a handshake sld bob.name and is hosting with deSEC. a. deSEC warns User A to either get verified within the grace period or risk losing the zone anytime a new user wants the zone. b. If User B wants to host their ICANN domain bob.name, they can do so (by verifying it). User A’s zone will be deleted as they had not verified it in the grace period. c. If no user wants to host ICANN’s bob.name (if bob is a rare word, etc.), User A continues to host bob.name with the constant risk of the zone being deleted.

If the owner of the handshake sld bob.name wants to purchase bob.name from ICANN once .name is released, they can do so and continue with the same service (after verifying the ICANN domain).

Names that are not TLDs can continue to be hosted. I mention this because most handshake names are very unlikely to make it as a tld (that’s a lot of them, check out https://namebase.io/domains/ to get an idea), they can continue to host on deSEC without any conflict.