to maintain a few hundred bytes in a database small enough to be served from a computer from the 90s?
to maintain a few hundred bytes in a database small enough to be served from a computer from the 90s?
Putting ~170 million .com records into a RDBMS on a 90s computer is not enough infrastructure to serve ~746 billion DNS queries a day : https://www.verisign.com/about-us/
They don't use off-the-shelf Redis/PostgreSQL/MySQL and they have more uptime reliability than Github, AWS us-east-1, Anthropic Claude, etc.
Verisign may still overcharge for what they do but nevertheless, the computing infrastructure isn't trivial.
shieet. does every damn intermediate DNS in the world have a 15-second cache TTL for .com's or something?
but still, serving 746000000000/(24*60*60)=8634259 requests/s of very light plaintext only requires a server rack or two these days. not a whole datacenter. https://www.techempower.com/benchmarks/#section=data-r23&tes...
so even with redundancy and onsite engineers around the clock, their margins are obscene.
And serving DNS for the root or a big zone is technically challenging. You want 100% uptime despite DDoS attacks, that's not simple.
> to maintain a few hundred bytes in a database small enough to be served from a computer from the 90s?
I don't like them, but they obviously have more than server operation costs. You can't really look at any business system like you did.
I only served a (custom) root.zone. It was tiny compared to today's root.zone filled with garbage TLDs and "security" theater. This file is soon to explode in size once again
Today I can serve com.zone. The computers I own have relatively modest specs
This lawsuit will settle, probably before discovery, but possibly we may learn a few things from the pleadings