Add .wed

[martimlobao]

• Description of Organization

• Reason for PSL Inclusion

• DNS verification via dig

• Run Syntax Checker (make test)

• Each domain listed in the PRIVATE section has and shall maintain at least two years remaining on registration.

Description of Organization

Organization Website:

Reason for PSL Inclusion

Even though .WED is listed by ICANN as having a terminated contract, there are reasons it might make sense to still include it at present:

• There are still live websites that use the .wed TLD, such as get.wed, atgron.wed, and even may27.wed. This is not the case for any other site on any other terminated TLD listed on Google Search, which makes .wed unique in that regard.
• It is still listed by ICANN as an active TLD in this other list of TLDs, as well as in the Root Zone Database where is managed by "Emergency Back-End Registry Operator Program - ICANN." Every other terminated TLD is missing from the first list and has status "not assigned" in the second list.
• Despite being listed as "contractTerminated" : true by ICANN, the record for .wed contains a null removalDate. Every other TLD which is listed as contractTerminated either has no delegationDate or has a non-null removalDate in the past.

As long as .wed continues to be managed by ICANN's EBERO, we might want to maintain it in the list of active TLDs. If the list of new gTLDs must be auto-generated, then the logic for adding TLDs should be adjusted to account for the last point above.

DNS Verification via dig

make test

See discussions in #1174 and #1175.

[dnsguru]

I propose we close and wontfix this PR. I've renamed the #1174 and then suggest we revisit this PR once we can get some feedback from ICANN about what to expect with EBERO strings.

Will leave this here for others to comment on but will close as wontfix in a week if no feedback.

@sleevi @weppos feedback?

[martimlobao]

@dnsguru Sounds like this is a wontfix then, right? Unless @sleevi or @weppos have any objections?

[dnsguru]

For now, probably. Would need to get the zone file operator to add in .wed TXT record or alternatively have specific entries with the DNS validation for the specifically affected names and have those added in the private section. First instance of a request of its kind - this is the only TLD that progressed into EBERO operations. I think close/wontfix is the fast path for now, and then we can reference this dialog later. My dissenting here is OCD... That the TLD is in the root zone / IANA list, so it should be included as a base entry, so I don't like close/wontfix from a curators' point of view.

…

On Fri, May 14, 2021 at 7:15 AM Martim Lobao ***@***.***> wrote: @dnsguru <https://github.com/dnsguru> Sounds like this is a wontfix then, right? Unless @sleevi <https://github.com/sleevi> or @weppos <https://github.com/weppos> have any objections? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1176 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACQTJKUQQB23RPVZIXR2DLTNUWBHANCNFSM4VHXMRQQ> .

[dnsguru]

My OCD was triggered after my last comment and I located .wed in https://data.iana.org/TLD/tlds-alpha-by-domain.txt and I think it merits a re-look at the automation so I opened an issue on this.

The TLD is atypical - it is the only EBERO name - so it falls outside of the norms of the processing done. The json file from ICANN says it is cancelled like .nationwide or .onyourside but unlike those it remains root-listed and present in the IANA TLDs alpha by domain file.

So I opened #1325 to review the autopull. Let's leave this PR open as a reminder, for now.

[dnsguru]

At this point, I'll close this out because there is now 'drift' and a conflict with the base PSL file which means a rebase is required.

We can revisit WED in another PR adding WED to the private section but I want to consult with ICANN first on this. Should we do this, we want to be sure to reference this PR when doing so to ensure there is a good transparent record on the matter.

[aaomidi]

Reading the BRs, this has created an interesting situation for these domains obtaining certs for themselves.

If they’re being served on the root zones, I think PSL should consider having them on here. This list ends up being a source of truth for certificate issuance and is inadvertently “blocking” https for these domains.

Weird situation.