handshake-org / hs-names Goto Github PK

It is problematic to allow TLDs that are entirely numeric, as IPv4 addresses and DNS use the period as delimiters and this will confuse applications.

This refers to any digit between “0” and “9” (Unicode code points U+0030 to U+0039)

Specifically problematic are the .0 and then .1 through .255, but purely numeric TLDs of any size are also problematic when used as the entire host component of a URL, as many BSD networking stacks still convert Quad A record IP addresses from pure numeric entries.

Example: HNS TLD = .8, one could give a hostname 8.8.8 and put it in the .8 TLD, which would make that host 8.8.8.8 in the DNS, which could cause a lot of mayhem within HNS resolvers that might fall back to DNS.Google for lookups.

Example: HNS TLD = .1, one could establish a host 127.0.0 and put it in the .1 TLD, which would confuse certain software attempting to connect to 127.0.0.1, which is typically "localhost"

Other examples in the .0 and .1-.255 range are hopefully self-explanatory

The example of a purely numeric string outside of that range is largely with the use of the TLD itself as a resolution point...

See This Article which articulates the dotted quad binary to integer computation

Having hundreds of countries competing for the name of gov, gouv, gob, etc. is a bit ridiculous (the most popular government website gets to be the government?). I think we should just ignore all of those in the build. cc @hschoenburg

tl;dr: the following two character strings are the only ones that should be allowed in HNS to avoid later problems (case insensitive):

• aa
• oo
• zz
• q[m-z]
• x[a-z]

These are generally available without assignment by ISO-3166/MA

If one reviews the Alpha-2 table that is present on wikipedia, only the user-assigned strings technically qualify as 'available' outside of the ISO-3166/MA

tl;dr: The .WEB and .SPA allocations were missed in the bootstrap development and were caught by the Alexa 100k approach, but were assigned to the wrong parties.

.WEB ended up with Verisign, but Handshake.org's assigned it as claimable by 1&1 IONOS
.SPA ended up assigning it to the Malaysian Government

From #6

Names that are already reserved:

Names that are already owned on HNS by auction winners:

idn, music, xn--jlq480n2rg (.AMAZON in Chinese)

The only remaining names that could be soft-forked to prevent future auctions are:

Originally posted by @pinheadmz in #6 (comment)

As evidenced in the bootstrap process, there were some friendly amendments made to address the delta between the root zone snapshot and the changes that had occurred after it was taken.

As evidenced in #6, there were some additions that the bootstrap process missed, but in addition to the zones being added to the ICANN root, there are zones also being removed when applicants opt to cancel them.

From time to time, ICANN updates the following file:
https://www.icann.org/resources/registries/gtlds/v2/gtlds.json with adds/changes/removes. The most recent update releases two IDN TLDs from Richemont, and .aigo

The Public Suffix picks up the deltas and auto-PSs them https://github.com/publicsuffix/list/pull/1059

These changes happen from time to time, and this leaves the option of releasing these in the handshake namespace.

Would it be possible to add the nostr protocol to the list of projects working on their own TLD

We have some work in progress in this front:

• dnstr
• NOMEN
• NOMEN explorer

Nostr is a global network of relays used for discovery and realtime updates. We would like to build out our own SLD using our existing infrastructure.

PR: #13

I have peripherally followed this project over the past few years, and was in Montreal at the ICANN meeting and I had the chance to hear Boyma present Handshake. I have heard the marketing pitch repeatedly, and there's some potential here in HNS / Handshake, where @chjj should be applauded.

This project is gaining some traction, which is good, and folks are spending HNS to get into auctions on names. It sounded like the fork point on legacy root and evergreening existing stuff had been handled well, but I noticed some stuff got overlooked in that process.

This hs-names project seems to have some promise - in the spirit of helping it forward I did some research and caught some TLD related stuff that needs IMMEDIATE attention.

tl;dr: Revise the TLD list

This project missed a lot of sources for blocking things like upcoming ICANN TLDs when gathering the evergreen list of TLDs to be set aside and need to address this immediately.

1. Go here:
   https://gtldresult.icann.org/applicationstatus/viewstatus

2. In the grey box "CURRENT APPLICATION STATUS", you will want the following statuses from the drop-down: "Applicant Support", "In Contracting", "In PDT" and "On-hold"

This will reveal the following TLDs:

• .AMAZON - Blocked by alexa approach, good
  • .アマゾン ("Amazon" in Japanese) Punycode: xn--cckwcxetd This has auction slated for January 2021
  • .亚马逊 ("Amazon" in Chinese) Punycode: xn--jlq480n2rg Auction available
• .HOTEL This has an auction slated for December 2020
• .IDN This one closed April 22, 2020
• .KIDS This has an auction slated for July 2020
• .MUSIC There is a TLD in reveal phase that conflicts
• .SPA - Blocked by alexa approach, good
• .WEB - Blocked by alexa approach, good
• .WEBS - Blocked by alexa approach, good

3. Add the missing ones. I didn't look to see if any of them have been auctioned or assigned, other than noticing the auction for .MUSIC - and a quick look revealed that .MUSIC and .WEB were not present in the TLD list here.

4. Address the conflict proactively. Your call on addressing HNS TLDs that collide with these if they have already been auctioned.

I hope you can turn those chips back into potatoes.

The first occurrence of a TLD collision with HNS with one that is delegated by ICANN accelerates the conversations within ICANN and the security professionals and industry on the Name Collision (NCAP) aspect of the HNS project.

I do not get any mild sense that the answers have revealed themselves yet within the HNS community for some of the important and uncomfortable questions that should be expected from NCAP over the intersection.

It seems there was an assumption made that by evergreening the existing list of TLDs plus the Alexa list that this would be done and dusted enough to buy 24-36 months time until a (maybe) new TLD round and ICANN would monitor HNS and remain laissez faire on this.

Optimistically, if some solution to all this could reveal itself before a new round, and it might, the time frame gets accelerated on that attention, and those solutions to the conflicts have not revealed themselves.