Potentially Broken Links in Comments

[groundcat]

The following URLs, which are documented in PSL comments, appear to be broken and return either 404 or 5xx HTTP status codes (scanner code). These broken links could indicate URL changes, website structural changes, changes in administrative bodies, or potentially outdated entries that might be identified during link maintenance. While this could be an opportunity for volunteers to contribute, it is probably a low-priority task since it only affects documentation. I will begin looking into some of these next week and work on cleaning up.

404 errors:

// http://www.dns.ao/REGISTR.DOC
// bm : http://www.bermudanic.bm/dnr-text.txt
// http://www.gobin.info/domainname/bw.doc
// see also: https://www.nic.cd/domain/insertDomain_2.jsp?act=1
// cr : http://www.nic.cr/niccr_publico/showRegistroDominiosScreen.do
// namespace policies URL https://www.nic.cy/portal//sites/default/files/symfonia_gia_eggrafi.pdf
// ec : http://www.nic.ec/reg/paso1.asp
// ee : http://www.eenet.ee/EENet/dom_reeglid.html#lisa_B
// es : https://www.nic.es/site_ingles/ingles/dominios/index.html
// gg : http://www.channelisles.net/register-domains/
// see also: http://www.nic.gh/reg_now.php
// hn : http://www.nic.hn/politicas/ps02,,05.html
// hu : http://www.domain.hu/domain/English/sld.html
// id : https://pandi.id/en/domain/registration-requirements/
// je : http://www.channelisles.net/register-domains/
// jo : https://www.dns.jo/JoFamily.aspx
// ki : http://www.ki/dns/index.html
// lk : https://www.nic.lk/index.php/domain-registration/lk-domain-naming-structure
// lv : http://www.nic.lv/DNS/En/generic.php
// ml : http://www.gobin.info/domainname/ml-template.doc
// ms : http://www.nic.ms/pdf/MS_Domain_Name_Rules.pdf
// ng : http://www.nira.org.ng/index.php/join-us/register-ng-domain/189-nira-slds
// np : http://www.mos.com.np/register.html
// pe : https://www.nic.pe/InformeFinalComision.pdf
// pf : http://www.gobin.info/domainname/formulaire-pf.pdf
// ph : http://www.domains.ph/FAQ2.asp
// pn : http://www.government.pn/PnRegistry/policies.htm
// py : http://www.nic.py/pautas.html#seccion_9
// rw : https://www.ricta.org.rw/sites/default/files/resources/registry_registrar_contract_0.pdf
// sd : http://www.isoc.sd/sudanic.isoc.sd/billing_pricing.htm
// sv : http://www.svnet.org.sv/niveldos.pdf
// see also: http://www.gobin.info/domainname/sy.doc
// vi : http://www.nic.vi/newdomainform.htm
// http://www.nic.vi/Domain_Rules/body_domain_rules.html indicates some other
// http://nic.ae/english/arabicdomain/rules.jsp
// https://www.iana.org/domains/root/db/merck.html
// .KRD : http://nic.krd/data/krd/Registration%20Policy.pdf
// CentralNic : http://www.centralnic.com/names/domains
// ClickRising : https://clickrising.com/
// IONOS SE : https://www.ionos.com/,
// Oursky Limited : https://authgear.com/, https://skygear.io/
// TASK geographical domains (https://www.task.gda.pl/uslugi/dns)

5xx errors:

// gr : https://grweb.ics.forth.gr/english/1617-B-2005.html
// IPiFony Systems, Inc. : https://www.ipifony.com/
// UNIVERSAL DOMAIN REGISTRY : https://www.udr.org.yt/
// Mail.Ru Group : https://hb.cldmail.ru
// https://www.iana.org/domains/root/db/pnc.html

[mozfreddyb]

Wow, that's a lot. Nice catch.

[dnsguru]

Thats a lot of debt to cover. I have to do a quick history lesson on the 2012 round of gTLD additions before my next suggestions, because I am going to suggest replacing the IANA db link for the ICANN section entries, but it needs some elegance and curation related to gTLDs.

The gTLD IANA DB Stuff is tricky. When the TLD delegation process phases occur, as there is an indefinite period between the time when a new TLD contracts to operate their TLD and when the TLD is delegted to the root zone, and actually lights up. This is a combination of operational readiness, an intentional pacing rate, and often in the case of spec 13 .brand TLDs, their corporate bravery, among other factors. short version of this statement is that the .JSON file we pull from ICANN differs from what's actually root-listed.

Why are we doing it that way?

The logic and reasoning here was that during high-flow delegation phases, which occur after an open round when parties can apply for new TLDs.

When the 2012 round of new TLDs launched, there were up to 20 a week for a few years. Frequently, the TLD would be added to the root zone, but because for example Safari would updte its internal list at the pace of MacOS or IoS upgrades every 3-6 months, the result would be that instead of the domain typed in the location bar being recognized as a domain name, it would be treated as a search term and sent to a search engine.

There was a need to get TLDs certain to be added by the ICANN (who are the authority) into the PSL at some advanced moment in time before delegation in order to offset the propogation delays that are beyond the PSL maintainers' control.

So we used the contract signature as the way to treat it as 'on the way', which typically paced reasonably well with enough advance timing to offset the propogation delays.

The thundering herd of additions slowed in 2017-2018, so if you're just joining the PSL party, you missed that whole flood of entries coming in, but our automation process held, and thank you to @cpu for all that hard work in getting that json->PSL stuff automated, because ther were >1000 TLDs and it was a LOT.

Does this divert from following our ICP-3 mantra?

Yes, but we also describe that we follow ICP-3 AND accept I* vetted (IETF : .onion) as well as the ICANN contracted but not yet in the root scenarios.

So, I'll land the plane on the whole background here to provide a contextually relevant example:
https://www.icann.org/resources/registries/gtlds/v2/gtlds.json lists .merck for example, but the IANA DB page has not been created yet, as the TLD is not yet in the root. It will be, but that's up to the IANA folks and the TLD administrator.

Given we're going to have an open round shortly for more TLD applications to happen, it is important to have all that context about the ICANN gTLD round stuff and the json being out of synch w the IANA DB for when the next thundering herd comes.

We need to leave some room for the gTLD IANA DB URLs to be broken if sourced from the json

What about this as a suggestion on URL cleanup?

I propose the following to reduce this list:

• retest https://www.iana.org/domains/root/db/pnc.html (works for me)

• remove all the 'see also' lines

• split this into individual PR for three parts,

  • ICANN Section
    • ccTLDs (idn ccTLDs included)
    • gTLDs
  • PRIVATE Section

• For those which are ccTLDs in the ### ICANN section,

  • replace the URL with the respective IANA DB Link

I suspect this will burn down a significant amount of the list.