indolering

For a definition of "efficient" that isn't shared by anyone else. This isn't a new rationale either, but a well known trade-off involved with JIT compilation and garbage collection. It's the reason Chrome "hogs" memory and Firefox is perceived as slow: they make different resource usage tradeoffs.

It will be interesting to see if the current memory crunch will impact this calculus going forward.

Montenegro (.me) seems to be aligned with the EU. But I would have expected there to see a legal ruling in France before Montenegro would do this sort of thing.

I wouldn't be surprised if GoDaddy caved to request. They are known for giving up domains to anyone with a badge and a fax machine!

That's not how I remember it: it was an experiment that was useful at the time but didn't work out. It was useful internally to sandbox Flash player, but the limitations of the LLVM based approach were soon evident to everyone involved.

I really wish I had messed with Windows Phone when it was a thing. They were the only ones not to just ship a clone of an existing interface ASAP. But it was closed source and offered no advantages for carriers or device makers compared to Android.

WebOS needed WASM and a lot more to be successful. I think WASM/WASI is to the point that the next major platform build out can use it.

The floating point "standard" was basically codifying multiple different vendor implementations of the same idea. Hence the mess that floating point is not consistent across implementations.

The answer is unequivocally yes: RISC-V is designed to be customizable and a vendor can put whatever they like into a given CPU. That being said, profiles and platform specs are designed to limit fragmentation. The modular design and core essential ISA also makes fat binaries much more straight-forward to implement than other ISAs.

I think it's a joke: you REALLY don't want to own your own servers.

I'm not unaware of this and I agree that WebPKI has greatly reduced global risk. New DNS tech takes a lot longer to implement but that doesn't mean we should kill DNSSEC support like the trolls insist upon!

Why would Let's Encrypt not also be interested in safeguarding DNS, SSH, BGP, and all the others? Those middle boxes will have to get replaced someday and we could push for regulation requiring that their replacements support DNSSEC. These long-term societal investments are worth making and it would enable decentralized DNS.

I'm also concerned that none of this will happen if haters won't stop screaming, "DNSSEC doesn't do anything but ackchyually harms security!".

(@tptacek: please stay out of this comment thread)

> The same reasons not to deploy DNSSEC that face large organizations apply to you: any mistake managing your DNSSEC configuration will take your domain off the Internet (in fact, you'll probably have a harder time recovering than large orgs, who can get Google and Cloudflare on the phone).

Set your TTL to five minutes and/or hand over DNS management to a service provider.

> Meanwhile, you get none of the theoretical upside, which in 2026 comes down to making it harder for an on-path attacker to MITM other readers of your site by tricking a CA into misissuing a DCV certificate for you --- an attack that has already gotten significantly harder over the last year due to multiperspective. The reason you don't get this upside is that nobody is going to run this attack on you.

Didn't save Cloudflare from a bad TLS certificate being issued. I still think that reducing the number of bad actors from 300 to the root servers and your registrar is a meaningful reduction in attack surface.

> DNSSEC attempts to address just a subset of these; most especially MITM attacks, for which there are a huge variety of vectors, only one of which is contemplated by DNSSEC.

How would authenticating DNS records cryptographically not address cache poisoning, MITM, and DNS spoofing in relation to DNS lookups? Also, DNSSEC doesn't have to solve all problems to make it worth doing.

> Finally, I have to tediously remind you: when you're counting signed domains, it's important to keep in mind that not all zones are equally meaningful. Especially in Europe, plenty of one-off unused domains are signed, because registrars enable it automatically. The figure of merit is how many important zones are signed. Use whichever metric you like, and run in through a bash loop around `dig ds +short`. You'll find it's a low single-digit percentage.

Yet you complain about DNSSEC being to hard to deploy and not getting enough deployment. Wouldn't it be nice if they could leverage that automatic signing to also generate TLS, SSH, and other certificates?

It can be used alongside WebPKI. And as someone who is worried about other protocols, it sure would be nice if I could setup DNSSEC for my domain and have clients pick up on that automatically.

More rhetorical dunking instead of engaging with the substantive technical issues. I'm done.

But it also applies to every other part of the stack, including WebPKI. Would you accept this as a valid argument against using HTTPS everywhere?

DNSSEC also solves a bunch of real world threat models that do cause massive security issues. I think we should put that effort into DNS as well.

That's fair! My primary gripe was about the need for non-profits to step in to begin with. Sorry if I didn't communicate that well.

However, I'm don't feel sorry for registrars or TLDs. Verisign selling HTTPS certs while running the root TLDs is a conflict of interest and I believe the perverse incentives are a big part of the reason why DNSSEC and DANE are stalled out. TLDs are a monopoly business and ICANN is quasi-commercial entity that should never have been a for-profit business.

I certainly think it is fair to ask them to pay for all this.