Potentially Outdated Entries in ICANN (IANA/ICP-3) Section #2265
Comments
.au
However just to be sure I have emailed auDA, requesting them to validate all their entries on the PSL, as well as to confirm whether specific domains should remain excluded (e.g. nsw.gov.au). (I emailed them just before you opened this issue.) .ci
A few weeks ago I confirmed all the .ci entries with the .ci registry, they shouldn't be affected: #2198 (comment) @groundcat I believe some of these TLDs you have mentioned are simply reserved for future use and do not exist yet. I would imagine this is the case for most of the |
|
@dnsguru Would be really interested to hear your take on this. I think we should make a wider decision here before we move on in the individual country codes. Personally, I can see the advantage of a slim list that doesn't contain second level entities like But before agreeing to anything, I would also like to learn more why these reserved second levels made it to the list in the first place. Maybe you have some background here? |
|
My question is similar, how did you congregate all these nested TLDs in the first place? |
|
@groundcat I've sent an email to the |
|
@groundcat #2268 opened for .tm |
|
@groundcat I've sent emails to |
|
@groundcat Received a response from the |
|
@wdhdev @groundcat Please do ask the registrars to publish the list on their site instead of just telling us. It makes sense anyway since their customers may want to know. |
|
@simon-friedberger May I get your email address to forward these emails to? You don't have one listed on your GitHub profile. |
|
Of course! At mozilla.com I am just simon or sfriedberger! |
There are a lot of entries that got initally set up by Joe and/or others from wikipedia entries or other 3p sources at genesis, or in other cases were accurate at the time they were added. In the 14 years hence some ccTLDs move operators, change policies, or have different personnel / plans and have left their entries alone. The approach was to inform about the list and let ccTLDs have agency to review and update their entries. I think we had a missed opportunity on this audit... I really wish that the current sweep had been called to my attention as a planned initiative, as I was in ISTANBUL for the ICANN meeting and could have addressed the ccTLD tech day audience about the effort. Still, many ccTLD do not participate in ICANN. |
Just a precision nit... TLDs are "Registries" not "registrars" Very common confusion publicly, but it is important to project that the PSL volunteers are sophisticated and know the difference when speaking w TLDs |
Add [email protected] to those forwards please |
|
@groundcat Emails sent to .jp and .us registries respectively. |
These two have some intricate subspaces defined, which we have historically left in place so that we did not break any civic/edu etc legacy entries. Wtihin the US namespace, RFC 1386 and later RFC 1480 defined them, and what later manifested was a diverse subdelegation structure for the various subdelegations - many of which still exist to this day, but are very difficult to track down the admins of. The .US TLD is operated differently since those RFCs and subsequent manifistation, but the descending subspace(s) remain so as to not break legacy email/web other sites and services that may depend upon their predictable status quo. I interacted with JPRS about 10 years ago and they reviewed and were satisfied with their entries, as they similarly have a large number of prefectures that have subdelegated spaces and some intricate entries in the PSL to match. These two particular namespaces are something I would recommend not fiddling with unless we receive some direction to do so from the respectivel registries. -J |
|
Yeah, I'm aware of their complex structure. I have just contacted them to see if there is anything worth adding or removing, I won't touch those entries unless the registries request it. |
|
I have noticed that the community has been working on fixing outdated domains in the ICANN (IANA/ICP-3) section. It might be helpful to take a more systematic approach to review all potentially outdated entries in this section. That said, validating these domains and reaching out to the TLD registries will likely require additional volunteer support.
Below is a list of ICANN section entries currently returning NXDOMAIN errors. This could suggest that the suffix has been decommissioned, but being on this list does not automatically mean a domain should be removed. Domains should only be removed after their status is directly confirmed by the respective TLD operator.
The goal of this list is to encourage volunteers to help verify whether these domains are still active—whether they are available for registration as second-level domains (SLDs), not available for registration but still in use, or reserved for internal networking or other specific purposes. Only after direct confirmation with the relevant registry should any domains be removed.
ICANN (IANA/ICP-3) Section Domains Returning NXDOMAIN Error
Click me to expand the list
Possibly Affected TLDs
ISOC AM <[email protected]>: "Regarding the updated list, we confirm that no changes have occurred.".BOcomments and fix alphabetical sorting #2276presse.ciandmd.ci, other ccTLD stubs not associated w respective registry #2198 (comment).COSection #2269.CWSection comments #2281.DMSection #2277.GESection #2283.MGSection #2274.PLcomments and fix alphabetical sorting #2270.RESection #2271.SGSection #2273.tmsection + add confirmation comment #2268.ttsection #2272Possible Approach
What I usually do is start from the IANA page at https://www.iana.org/domains/root/db since it is the authoritative source. From there, I note down the administrative and technical contact emails listed. That said, I have noticed these addresses might not always be closely monitored by the operators, probably because they are public and more likely to get spammed.
To work around this, I check the registry's website directly, using the URL provided on the IANA page. I avoid relying on third-party sources like Google or Wikipedia to find the registry’s site, as those might lead to non-authoritative or outdated information. On the registry's website, I look for their contact form or email address and send my inquiry there, hoping for a response.
It is also worth noting that having decommissioned domains do not necessarily mean only removals are needed. There is a good chance that TLD operators are introducing new suffixes or replacing old ones with updated versions. When contacting registries, it might be a good idea to ask for a comprehensive list of all suffixes they currently manage. So, we can aim to remove outdated entries and add any new ones in one go, if applicable.
Of course, if anyone has a more effective or efficient way to handle this, I would love to hear about it!
If trusted community volunteers, like @wdhdev, could be granted triage permissions (as mentioned in #2231), it would be really helpful. This way, we could update the list above as we progress, which would make the process much more efficient.
The text was updated successfully, but these errors were encountered: