How should we handle the 2LDs of the .name TLD?

[wdhdev]

I have gained access to the full zone file of the .name TLD through ICANN's CZDS (https://czds.icann.org), with the intention of adding the 2LDs to the PSL.

The .name TLD has a bunch of 2LDs, which as far as I know allow registration. An example of one is harrison.name, it has no delegated NS records, however it has MX records in the root zone, which is how the .name registry operates these 2LDs. So someone cannot directly register an already created 2LD like harrison.name, however they can register at the 3rd level (e.g. william.harrison.name).

I'm not 100% sure how they determine what to configure as a 2LD or not, or whether they just delegate any domain at the 2nd level at request. (This is a possibility because there are a lot of reserved 2LDs that only have one 3rd level domain.)

Should we maybe sort this data in a way so we only add 2LDs that have say 10 or more subdomains at the 3rd level? The reason I say this is because there are around ~15,500 2LDs when using a basic search program.

[wdhdev]

After filtering out all the 2LDs that do not have any nested subdomains, I have ended up with 7,124 2LDs. Obviously that is still too many to add to the list, especially regarding a lot of them don't actually have many subdomains.

[groundcat]

The threshold of "10 or more subdomains at the 3rd level" seems a bit too low to be considered relevant of addition to the PSL. If we apply the common threshold of > 1,000, how many .name 2LDs actually have more than 1,000 nested 3LDs?

If we were to include example.name 2LDs that have more than 1,000 3LDs in the PSL, which I assume would still be a lot, I am concerned about our resource limitations. Given our current practice of monitoring the "worthiness" of existing entries, we would likely struggle to track the usage of so many domains. Since 3LDs can be created and expire, as can 2LDs, there might be too many variables to make this practical for project maintenance. Some living examples are .jp and .aero.

Based on previous efforts from @dnsguru regarding this TLD, I believe we concluded that an opt-in approach would be best for such TLDs (including .name, .post, and similar ones with large numbers of 2LDs-as-suffix). However, I doubt the registry would implement this approach.

[wdhdev]

As far as I'm aware, reserved .name 2LDs do not expire, only the 3LDs can as they are actually owned by internet users, not the registry.

For the sake of clarity, here is a compiled list of all .name 2LDs with > 100 nested subdomains:

domain.name: 1097
japan.name: 249
tokyo.name: 188
mail.name: 160
love.name: 138
family.name: 132
smith.name: 114
scenario-test.name: 102
tanaka.name: 102

domain.name, assuming my program is working correctly, is the only 2LD with above 1,000 registrations.

[dnsguru]

I hate when we jiggle this specific door handle :)

I kind of default back to letting the relevant registries make the pull requests, so that whatever happens is intentional and defined to us by the registry.

This is what has been behind my motivations to do all the education and outreach within the ICANN meetings across.

It just seems wisest, because in the case of .name, Verisign (the registry for .name) should be the ones to direct us on what path to take.

The results of third-party detection of subdomains in .name might not be able to determine if the subdomain is operated by the TLD administrator delegated for the TLD (as shown in the IANA database) vs it being operated by a separate third-party operator.

We should use care about not listing some third-party domain name within the authoritative administrator section - there is an inferrence taken of those being 'official' and affiliated with the IANA delegee.

Specifically in the case of .name, there are thousands of surnames that would be potentially identified, for which there may or may not be actual registrations present.

So the juice/squeeze ratio on this is low/low, hence it remains in status quo. And that's OK until the IANA TLD registry operator tells us otherwise by opening the PR process. I suspect their Juice/Squeeze ratio is also low/low or something would have happened in the last 15 years.

[dnsguru]

short version of previos comment is:

Do we need to do this? Softer walls exist to beat our heads against.

[dnsguru]

As far as I'm aware, reserved .name 2LDs do not expire, only the 3LDs can as they are actually owned by internet users, not the registry.

the hardest part on this - there is no means to tell the difference if these are third parties or if they are Verisign themselves.

[wdhdev]

It does seem to be Verisign themselves, as the surname.name 2LDs don't have any delegated NS records, and are resolved directly in the root zone. They also tend to have MX records pointing to the registry (nic.name).

Maybe we should add all domains with > 500 3LDs in the Private section?

[dnsguru]

Maybe we should add all domains with > 500 3LDs in the Private section?

upon those individual requests by those registrants, sure. But otherwise I really am not sure I would want an entry unless I wanted to have one by requesting it. Keep in mind, the registrant may actually not want an entry so this might actually cause them harm.

I respect the effort and get the desire to add order to what seems to not have it. It just seems like this circle cannot be squared and it is ok to accept that it just is that way.

[groundcat]

For the sake of clarity, here is a compiled list of all .name 2LDs with > 100 nested subdomains:

domain.name: 1097
japan.name: 249
tokyo.name: 188
mail.name: 160
love.name: 138
family.name: 132
smith.name: 114
scenario-test.name: 102
tanaka.name: 102

domain.name, assuming my program is working correctly, is the only 2LD with above 1,000 registrations.

Based on the data shown, I believe none of these .name domains would meet our inclusion requirements when considering the fundamental purpose of the PSL - establishing domain boundaries between different entities. While domain.name has over 1,000 third-level domain registrations, a quick search indicates that almost all of these are owned by a single entity which is a registrar (Regtons). They appear to be using domains, for example, like page.domain.name as landing pages to promote sales of their .page TLD offerings and similar purposes. This pattern of usage does not align with the PSL's core purpose of demarcating boundaries between different organizational entities.

It appears that, for instance, anyone can register a domain like somerandomname.name, and if we take a proactive approach (rather than having registries to submit), we would have no easy way to determine whether somerandomname.name is registered by the registry itself or by an individual registrant. We also cannot easily determine if including it in the PSL would align with their intentions or potentially break their sites. Therefore, in this specific case, I would prefer to let the registry operating the TLD make these decisions.

I do appreciate all the hard work that went into investigating this TLD, as it has proven to be an interesting case study :)

[wdhdev]

I'll reach out to the .name registry again and I'll see if they do want to list any of these entries on section, or if they want to keep them off the list.

[groundcat]

Looking at all this usage data, I am not entirely sure if it would even be worthwhile to request their thoughts on adding these entries to the PSL (especially in this case). I could be wrong, but I am a bit concerned that if they were to suddenly decide to add all surnames to the PSL for some reason I cannot quite imagine, it might cause the list to grow unmanageably large. So perhaps - and please let me know what you think - keeping things as they are might be the safer approach? Just sharing my initial thoughts on this, but I would be interested in hearing other perspectives.

[wdhdev]

You're probably right. It likely isn't worth requesting their thoughts, especially as none of the 2LDs in the root zone file for the name TLD actually seem to meet the PSL's requirements. I'll just close this, and add a note to the .name section in the PSL. #2307

[simon-friedberger]

Let me add this here, because it was in the older issue discussing .name:
We do not want to replace *.whatever with more specific lists of the subdomains like co.whatever, org.whatever, net.whatever, if we can avoid it.
Since we already have the wildcard, we are not introducing any further problems by using it and the wildcard is better for list size and also better for security, because it covers everything, even if it isn't manually added.