Central authority is a poor substitute for social consensus.
If you look at a case like this, there is absolutely no question or ambiguity "which perl.com domain people really want." This issue only exists because of an artificial monopoly and an application of capitalism to an allocation problem that doesn't exist.
Domain names should be a thin wrapper around private/public keypairs. Domain keys should be pinned per application or per first use OS-wide, with configuration tools to unpin and update the mapping. Any critical access, such as update servers, should always use the full key anyways. There is no reason in principle that there shouldn't be multiple name-key assignments for perl.com, except inasmuch as it would make webdevs' and OS developers' jobs slightly harder. Hell, ping both and see which one matches the pinned https key for perl.com, and this problem would already have been solved! This whole monopoly is caused by a bad band-aid technical solution for a social problem that we can and should find a better solution for.
I'm not saying "boycott DNS." I'm saying "the fact that everyone is fine with the current state of affairs is an embarrassment."
I want an OS built from the core up around a web of trust model. I want my browser to ask my (manually introduced) peers "which of those versions of perl.com do you think is the one I want." I want a computer with no hardcoded central server queries at all. (And while we're at it, I want it connected to the internet via mesh links.) But I'll never get that, because it'll always be easier to just hardcode some central authority and go home.
How would you prevent a group from trolling or performing a hostile takeover of a small domain? How would someone acquire a domain? How do you determine consensus?
In this case, as someone who doesn't follow Perl, how would I make an informed decision on which perl.com domain I really want?
> How would you prevent a group from trolling or performing a hostile takeover of a small domain?
Several ways.
If you are accessing the domain locally, you'd normally be looking for entries that match the private key you have stored. So if you ever went to that domain, you'll get the same remote again.
If this is your first time accessing the domain, you'd ask your peers what version of the domain they have stored. Those aren't randomly assigned, but people you know IRL, similar to Freenet. You could do some degree of onion routing if you care about keeping sites you go to private from your friends. And again, you'd only do it the first time. And this is hard to attack because you can't make a person have friends in the WOT graph.
When you are following a link, the person placing the link could always just attach the full private key to the link tag.
If you are copying a URL from your browser bar, the browser could attach a random set of index-value pairs of the private key. This would be very hard to spoof, but not increase the size of the URL by much. That would cover you for posting links in forums and chat rooms.
Of course if you were searching for the domain, your first hit would almost certainly have the correct key.
Only if you are told the URL through an out-of-band source, and almost nobody you know (transitively) has gone to that domain, you are in the situation of having to figure out which key is the true key. In that case, you could fall back to certificate checks. Note that certificates as a market are a lot more competetive than the domain name market.
So there's no one-size-fits-all solution, but just like right now, most of the time you wouldn't have to think about it. And unlike right now, if it goes wrong you get a nice error instead of silently the wrong domain.
I just thought of a way to improve the privacy of the DNS lookup. Instead of asking for the domain name, ask for a prefix of the hash of the domain name chosen so you get maybe 20 domains back.
The point is - I got all of the above by thinking about the problem for maybe ten minutes. This is far from unsolvable. We as a community are just terminally lazy.
It's not an obvious problem to solve, but nobody would invest much in performing a hostile take over of a small domain.
In the case of Perl.com it looks like a hostile takeover, of a popular domain, and it didnt cost them much to take it over I guess.
Here [0] is an example of someone putting inordinate amount of effort to take down a tiny mastodon instance. If it would have been possible to take over a domain in a similar manner - it would have happened too.
> Domain names should be a thin wrapper around private/public keypairs.
This way anyone who gets access to the keys, even temporarily gets to take over the whole domain. No chance to resolve the issue with a registrar who can manually review the case and revert changes. This would include anyone working on that level of infra in your company and anyone who hacks them.
I'm not sure what would you compare the https cert to without a central authority in that case.
We tried the web or trust with PGP and it turns out key management is really hard and apart from few geeks nobody's that interested.
The certificate market is a lot better than the domain market, because it's not a monopoly. I think it makes sense to have a trusted-signature system as a backfill and bootstrap for your web of trust.
Agree that nobody cares about this though. I'm certainly not surprised that we settle for easy mediocrity.
