I already had all but one of the settings you mentioned disabled, along with most of the others. I'll report back in a day or two.

(Which in general would be a good practise anyway, because many services do use domain validation processes similar to what you propose)

An attacker should not gain the ability to persistently issue certificates because they have one-time access to DNS. A non-technical user may not notice that the record has been added.

> Also, why not support file based auth in .well-known/acme-challenge/... for domain wide certs? Which attack vector does that prevent?

Control over a subdomain (or even control over the root-level domain) does not and should not allow certificate issuance for arbitrary subdomains. Consider the case where the root level domain is hosted with a marketing agency that may not follow security best practices. If their web server is compromised, the attacker should not be able to issue certificates for the secure internal web applications hosted on subdomains.

And I'm sympathetic to the concerns that automating this type of thing is hard - many of the simpler DNS tools - which otherwise more than cover the needs for 90% of users - do not support API control or have other compromises with doing so.

That said, I do think LE's requirements here are reasonable given how dangerous wildcard certs can be.

In summary, it estimates the cost at $3.5 billion using commodity hardware, and I'd expect a purpose-built system could bring that cost down by an order of magnitude.

I wouldn't be so sure - quantum computers aren't nearly as effective for symmetric algorithms as they are for pre-quantum asymmetric algorithms.

Meanwhile, other implementations will not consider the disk bootable in BIOS mode if the partition in the pMBR is not marked bootable.

It's busy-work that provides no business benefit, but-for our supplier's problems.

> specific outbound IP addresses that they can then whitelist

And then we have an on-going burden of making sure the list is kept up to date. Too risky, IMO.

My startup pays Docker for their registry hosting services, for our private registry. However, some of our production machines are not set up to authenticate towards our account, because they are only running public containers.

Because of this change, we now need to either make sure that every machine is authenticated, or take the risk of a production outage in case we do too many pulls at once.

If we had instead simply mirrored everything into a registry at a big cloud provider, we would never have paid docker a cent for the privilege of having unplanned work foisted upon us.

For an example of a site that almost gets it right, see https://www.finnair.com/ . You are first prompted to set location, and then language. I say "almost" because although they will allow you to select English in any market, they won't allow you to select any offered language in any market.

In comparison, https://www.flysas.com/ you get one dropdown which sets market, currency, and language in one go.