Earlier quoted context omitted.
In DNS, the owner of each record has full control over its TTL. Intermediary DNS servers are required to honor them and are not permitted to replace TTLs with their own.
DNS servers do in fact do that but it would not be a good look for the world's largest DNS provider.
Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
171–180 of 305 posts
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#172Earlier quoted context omitted.
You are obliged to pass on the TTL, you're not obliged to cache according to it. At least in my country (UK) I know of no law relating to DNS caching. Why throwaway perfectly good data every few minutes that is only modified every couple of years, just so someone can move their domain quickly when they eventually wish to? It is my contention that a [caching] DNS service can do far better. Trusting user (domain owner)…
It's not some sort of public law with public enforcement, but it is in the RFCs that govern the protocol. I should be a bit clearer here; the TTL is an upper bound on how long it can be cached. Caches are free to consult more frequently but not less frequently. That said, out of respect for upstream cache operators and authoritative servers, most DNS caches honor TTLs as best they can.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#173Earlier quoted context omitted.
I wish more programming languages implemented record types as seen in databases, where dynamically sized fields are packed into a contiguous area of memory. The CloudFlare manually implemented a clumsy version of this. Wouldn’t it be nice for the compiler to manage this for you in the same way that your database engine does when it saves a “row”?
> dynamically sized fields are packed into a contiguous area of memory Are you able to explain this? Do you mean an N sized array where each entry is either a value or a pointer to a value where the 'pointed-to' values are after the end of the array? I'm trying to underatnd how you'd do this without having to parse M-1 elements to get the Mth entry if you did a [{size0, value0}, ....., {sizeN, valueN}] arrangement
In a row oriented database, you get a contiguous spot for the whole row even when there are multiple variable width fields.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#174Frankly weird that they were resorting to high level containers for this in the first place. Also, this line struck me as odd > Big Pineapple uses jemalloc, an allocator designed for multithreaded, allocation-heavy workloads. jemalloc multithreaded performance is actually poor(ish) compared to other modern allocators, which makes it a weird choice. But even weirder is why they're even using an allocator in the first…
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#175Earlier quoted context omitted.
This one also looks pretty obvious "in foresight" (using the same tools that existed back then. Maybe owner dedupe might be less obvious and require a bit of knowledge and probing into actual data, but for rw vs ro you are fine knowing nothing?) and you forgot the napkin math re. how much your precious "time to market" would have been delayed by. It's also not nothing, otherwise it would never be optimized away now,…
Imagine you're an engineer at cloudflare, an 8 year old (at the time of launch of 1.1.1.1) company. The company is wildly popular and any service launched is going to have a lot of traffic and a lot of attacks right away. Any problems with it are going to embarass the company a lot. You're tasked with making a DNS caching recursive resolver that can operate at a large scale and will be run on thousands of servers eac…
Doesn't this also inform you that your cache will be very large, so you shouldn't use growable structures with slack space when cache entries won't grow; slop space reduces the size of your cache. And also that the query volume will be high so the cached data should require as little work as possible before returning data; spending time marshalling response data on every cache hit increases response time and decreases capacity.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#176This is the right way to deliver software. Produce working product first, validate the idea, stabilize the business, start generating profit, and then you can start optimizing your costs. In fact optimization is by far the easiest part of the process because there are many system programming experts on this HN thread who consider these optimizations to be trivial.
I think Cloudflare became big only because they were so much more optimized than others that they offered some services for free that others were not offering. If running costs are high, you only burn (VC) cash and then you exit.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#177Earlier quoted context omitted.
Quite. I was a VMware fanboi (25+ years, man and boy) I still look after a few VMware estates and a lot of Proxmox ones (that used to run VMware). Hilariously, VMware is described as "enterprise class", which I can only conclude means MVP and a bit wanky. Today I repaired a Proxmox HA + Ceph node using boring old normal Linux skills and as it turns out I have 30 years of those. Part way through a remote v8 to 9 upgra…
When I was first getting into software dev, I thought 'enterprise' meant 'industrial grade', 'powerful', 'high-performing'. Then I actually met some enterprise software, and realised that it means 'expensive', 'bespoke', 'one-off', and usually 'janky'.
Why solve the problem directly when you can abstract everything away into FactoryFactoryImplementationInterfaceFactorys, and have something that is both a memory-hog and completely unassailable to any normal programmer seeking to understand it or make changes?
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#178Earlier quoted context omitted.
My house is a ~700 sqft. condominium, gov. subsidized for lower income individuals, and even my mortgage is more than 300k… maybe I’m just basing my info off of coastal city prices, but is it possible to buy a reasonably nice home located in a reasonably nice amerikkkan city… for $300k in 2026?
That would buy you thousands of square feet and often several acres within 20 minute drive to a lot of US city downtown areas.
Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
#179Earlier quoted context omitted.
> In Rust, you can’t even use proper arenas You definitely can and this is done a lot. What you might mean is that you can't use standard library's collections with them (this is getting stabilized soon!) and have to use third-party, but that is a different thing than "can't use arenas". > Rust is not a good choice for this kind of tricks. Rust can do those tricks, but it's true that it is hard than in C or Zig. That…
Stabilized soon, really? They did not stabilize it after 10 years and were thinking about different approach. I thought it’s dead.