Hello there.
I have a domain with the TLD “.sr” (surinam). I previously had gotten a certificate from my Hoster, but two weeks ago it suddenly failed and according to the Hoster it is not possible to get a certificate for that TLD anymore.
How can this be and what can I do in order to secure the site again?
The .sr TLD DNS servers handle CAA queries incorrectly. It won't be possible to get a Let's Encrypt certificate until the DNS servers are fixed. (Let's Encrypt may be willing to whitelist it until September 8, though.) 
All CAs will soon be required to check CAA records as well, though some of them will probably have more lenient policies regarding bugs like this.
Maybe @cpu could investigate whether it can be put on the whitelist until September 8.
It would be really important for someone to contact the people who run the top-level domain DNS to ask them to fix the problem. The page about CAA that @mnordhoff linked to could be very helpful for this.
We're not able to whitelist whole TLDs unfortunately, just fully qualified names.
Are you sure? I dunno about the rest of the tools, but LookupCAA and ReadHostList don't seem to mind if you put "sr" or "sr." on the list.
Oops, this is my fault, I talked to @cpu about this without looking at the code and apparently had a out of date memory of what the exception list actually did. We can technically whitelist the entire TLD, which depending on the number of people who are failing requests we may consider doing.
That said I’d like to get in contact with the representatives of .sr before adding it to the whitelist. If we were to whitelist it but they choose not to fix the issue we will be in a even worse spot where we have issued certificates for domain holders that they will not be able to renew after Sept 8 when the more strict enforcement goes into effect.
@jsha Were you able to contact the .sr ccTLD people about their CAA problems after the last thread?
If this is anything like the .br Public Suffix adventure, making September 8 is optimistic... 
True, but the even worse spot is what's happening now. Delaying the inevitable is arguably no worse than having the inevitable happening already. Or... it's differently awful. 
There are 642 total certificates now, 200 of which are unexpired.
https://crt.sh/?Identity=%25.sr&iCAID=16418
https://www.google.com/transparencyreport/https/ct/?hl=en#domain=sr&incl_exp=false&incl_sub=true
It might be helpful to have someone who speaks Dutch to contact Telesur, the TLD operator.
I just wrote to the technical and administrative contacts for the .sr TLD, but the whois records for that TLD are about 7 years old, so I’m not sure whether either or both of those people are still working in their roles.
I did reach out to the domain contacts for .sr, and it sounds like Seth did as well. No response yet. If someone knows an alternate avenue, that would be great!
TeleSur itself has an active DigiCert certificate. Maybe we could ask Jeremy Rowley if DigiCert has contacts for that certificate and would be willing to ask them? I know it’s not a very usual request in the context of a CA-subscriber relationship…
Also, I just submitted a “pre-sales contact” form at register.sr which is for people who have questions about registering a .sr domain name.
Also, @Soylent, you could apparently send a customer service request to klantenservice@telesur.sr to ask them if they’re aware of this problem.
On the assumption nobody’s had a response from Telesur yet, I have also emailed their support address on this topic.
As the owner of a .sr domain, I too am affected by this! I wonder if (as a customer) I will have more success. They’ve been helpful to me in the past (in good English), but was about a billing query.
I’ll update here if I get anything back from them.
In a similar vein to asking Jeremy, it might be possible to reach out to one of the root (DNS) operators or to ICANN?
I got a reply from register.sr earlier today and they are looking for how to get their Infoblox DNS service to work with CAA. So, I’ve just now contacted Infoblox to ask for a support engineer’s help diagnosing the problem.
I got a reply from Infoblox and have forwarded some more technical information over to them.
Hurrah! I've also had a very similar reply from them:
We have contacted our vendor Infoblox for support on how to resolve this matter seeing that it will impact all SR domains.
We were also contacted by one of the forum members and he will also try to get a response from Infoblox.
We hope we can provide you and other impacted customers with a permanent solution.
I believe I am the forum member Telesur was referring to, because I’m trying to get a response from Infoblox. 
I’ve sent them a detailed set of resources prepared by @jsha and some of my own clarifications.
So, I haven't received a reply via my contact at Infoblox, but Gervase Markham from Mozilla happened to mention today that Infoblox doesn't anticipate a fix for this until "Q1 2018" (!!), which is to say sometime between January and March. This matches what another Infoblox customer reported at
I find that pretty sad because they've clearly heard from a number of customers, apparently some of them starting months ago, and @jsha has argued that the current behavior of these devices violates Internet standards because DNS servers should return NOERROR whenever they don't recognize a query type (specifically in order to allow new RR types to be introduced).
Anyway, @jsha also explained that if you can point your DNS delegation to a non-Infoblox server, even temporarily, and actively add a CAA record permitting Let's Encrypt to issue (in this exceptional case you do have to have a CAA record, which you wouldn't have to do if the parent DNS zone returned NOERROR), then you can get a certificate.
We should try to create something like @sahsanu's advice at
but with an additional explanation of how to create a CAA record to affirmatively permit issuance (again, this is only required in a case like .sr where the parent zone returns an error or times out).
By the way, I've continued to have contact with Telesur about this and they seem very apologetic about this situation and the inconvenience that it's causing for their customers.
Also, to be clear, the conversation in that bugzilla thread (and the linked Infoblox forum thread at https://community.infoblox.com/t5/Security/NIOS-support-for-CAA-records-RFC-6844/td-p/9655) is about specifically supporting CAA records, or in other words the ability to include such records in a zone. However, all we really need is for Infoblox not to time out when queried for a CAA record (or other unknown record type). I’m a bit concerned that they will “fix” the immediate problem by adding support for CAA, while keeping the fundamental problem of timing out on unknown record types.