Missing TLD [xn--4dbrk0ce / .ישראל]

Ah cool, so the semi-automatic system is already in place :+1:

5 Likes

@jvanasco

  1. OK, Created a PR new TLD .ישראל and SLDs for Israel by ISOC-IL by guidlbb · Pull Request #1595 · publicsuffix/list · GitHub
  2. Requested to add the TXT record to the Zone, should happen in a few hours.
  3. Our site already have guidelines and info regarding out TLDs
  4. We can be reached via the root zone database technical contact email.

Anything else i might be missing ?

Thanks.

2 Likes

Maybe this isn't a particularly common problem, but I wonder if Let's Encrypt should use a different method than the PSL for this specific purpose.

The official validity of DNS names is defined by ICANN's TLD list, in conjunction with the root zone contents. The question of whether a CA can issue a certificate at all for a requested name is most authoritatively defined by these things (in conjunction with other policy requirements from the CA/B Forum and other sources).

Let's Encrypt has been relying on the PSL for purposes including setting defaults for issuance rate limits, which (while slightly controversial because of the extra burden it's led to for the PSL administrators!) makes a lot of sense for that purpose because it catches declarations by domain operators that registrants under a particular suffix are usually different entities from one another. But that declaration is actually pretty different in kind from registrants under a particular suffix should be entitled to publicly trusted certificates at all. The PSL isn't authoritative for this, and doesn't really do much officially-related research, even though it's unlikely that nonexistent TLDs would be able to get listed there because of PSL sanity checks. (Trying to resolve a particular RR in public DNS is a part of the PSL administrators' process before adding something there, so if they couldn't do that, they wouldn't add the requested entry.)

Anyway, conceptually it seems to me that it would make more sense to say

  • ICANN TLDs list and/or root zone contents as a starting point for names under this suffix are valid and may be subjects of publicly-trusted certificates, and
  • PSL as a starting point for default rate limit calculations

just because they have different meanings. (Of course, both can then be modified for other reasons; for example, if arpa turns out to be in the ICANN list, there are still other policies that forbid issuing under it; and even if foonly.edu isn't in the PSL, it could still have a specific rate limit exemption because its IT department requested one.)

Now that does mean that—as @jvanasco's point about subdomains of TLDs illustrates—TLD operators have a practical responsibility to list something in the PSL in order to get reasonable behavior. But that's already kind of true with regard to cookies, the original focus of the PSL. If you don't tell the PSL about how registrations under your TLD work, browsers may guess wrong.

4 Likes

@schoen, I can see your points, but I'm not really seeing a way around Let's Encrypt using the ICANN section of the PSL to know that it shouldn't issue a certificate for FQDN co.uk directly. It also wouldn't surprise me if they liked the belt-and-suspenders approach of both being in a semi-official list as well as needing to resolve through the root servers of DNS, just because it's really embarrassing when a CA issues for a name that doesn't even have a real TLD.

4 Likes

I don't think this has been required for many many years. Most languages support using their public module system or vendoring versions.

With security minded projects, you often want a manual review of diffs when versions bump and to vendor the library to ensure the repository was not compromised. For "critical" projects (define as you wish), a manual review is often a good idea to avoid surprises. Unit / Functional / Integrated testing can ensure known test and edge cases pass, but they don’t address new edge cases that might be created. Reviewing dependency changes will often suggest new tests to create.

I briefly thought that too when double checking Boulder’s source. I knew it was used for the rate limits, but couldn’t find any other usage for domain validation. I was surprised everything eventually pointed to the PSL. Then I thought about the ‘.co.uk’ style suffix partitioning and my opinion changed. If a TLD operator doesn’t accurately list their domain in the PSL to safely implement cookie sandboxing, it can create a security issue for everyone across the TLD.

IMHO, my main takeaway from this is that Mozilla/volunteers shouldn’t be maintaining the PSL but IANA should. While it makes sense for the PSL to exist for registered domains, it seems like a failure of IANA to not provide the TLD data with partitioning rules itself.

Edit: Adding,

The way I look at this- considering LetsEncrypt's mission is security focused and the stated purpose of their Certificates are primarily web servers, should registrants under a particular suffix be entitled to publicly trusted certificates at all when the TLD operator has not followed modern security practices and listed their domain with PSL. I do not think so, as that can create a security issue with browsers.

6 Likes

Hi @mcpherrinm,

The pull request to the PSL was merged successfully.

Is there an option to trigger the update manually so we can have the new TLD deployed and tested before the end users can officially start purchasing these domains ?

Thanks you.

5 Likes

Glad you got this through so quickly!

5 Likes

Unfortunately there's one more hop before we can update Let's Encrypt to recognize the new TLD: we rely on GitHub - weppos/publicsuffix-go: Domain name parser for Go based on the Public Suffix List., an automatically-generated repository which cross-compiles the PSL from a text file to a Go struct. That way we don't have to be loading and parsing large text files ourselves.

So that repository needs to update first, then we can update our dependency on it. As soon as that repo updates to include your new TLD, update this thread and I'll be happy to manually run our update task.

8 Likes

Does one have to wait for a Boulder update after this step too?

4 Likes

Yes, though that's within our control so we can tell you when that happens (Thursdays, usually). Assuming weppos updates publicsuffix-go before Tuesday, when we deploy updated versions to staging, the change should be live next Thursday, or otherwise the Thursday after. It sounds like the go-live date for the new TLD is in September, so we should be fine well in advance of that.

8 Likes

Seems the "PSL update" workflow runs once daily, so that shouldn't be an issue. Looks like weppos commits those PR quite quickly too :slight_smile:

6 Likes

They use github actions to automatically pick up the changes and generate the PR (https://github.com/weppos/publicsuffix-go/blob/main/.github/workflows/psl-update.yml). The PR is usually approved that day or the next.

8 Likes

Boulder has been updated with the new public suffix list, but we've already cut this week's release tag. Support for this TLD will be available next week in the next release.

8 Likes

Unfortunately for OP this time there was a little bit longer delay between the automatic PR and the approval and merger thereof, probably resulting in the list not getting into this weeks release :slight_smile:

5 Likes

This domain should now work in LE staging and (hopefully) tomorrow in production.

6 Likes

Great, Thanks !

I'm on vacation but will forward to colleagues to check it out.
we also managed to push the update to FF and in the process of updating chromomium

4 Likes

FYI, we are doing some other maintenance this week so the deploy may happen a bit later than usual. I will post in this thread once the change is fully deployed.

8 Likes

thanks for the update, waiting for your post to do testing from our side.

3 Likes

This change is now deployed. Please let us know how your tests go!

8 Likes

I can Confirm that it's working.
Issued cert successfully.

I want to thank everyone who was involved for their effort.
Getting to know the PSL and its dependent parties / components and manual dependencies has been challenging and even surprising to a lot of people who where exposed to it via this issue.

6 Likes