Live data from Hacker News

Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

blog.cloudflare.com

171–180 of 305 posts

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#171
post #66

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.

I don't think cloudflare cares about how it looks, also I think Google is bigger.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#172

Earlier 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.

The IETF isn't the internet police. You don't have to follow its advice.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#173
post #153

Earlier 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

I think they mean the cache entry is a collection of dynamically sized fields. It would be nicer to store that as a single contiguous allocation, rather than a bunch of pointers to individually allocated dynamically sized items. At least in this case, it might.

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

#174
post #51

Frankly 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…

An approach like that would be at constant war with the borrow checker in Rust. Apparently it is possible but there is enough friction that these guys went a different route.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#175
post #42

Earlier 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…

> The company is wildly popular and any service launched is going to have a lot of traffic and a lot of attacks right away.

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

#176
post #68

This 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 do not think Cloudflare was a less-than-peers optimized product when they launched. This is one of their blog posts which describes taking one aspect even further.

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

#177
post #135

Earlier 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'.

To me it always meant needlessly complex and overspecced for what's needed. I think probably due to Java's enterprise years.

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

#178
post #150
post #140

Earlier 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.

Can you ground the discussion by mentioning what you think these cities are? Taking Columbus, OH as the most average of American cities and a 20m isochrone map from city center, there are currently 0 parcels for sale with 3+ ("several") acres under $300k. There are a few within 30m drive, one of which even has a possibly habitable structure. The rest are bare agricultural land you'd need additional investment to actually live on.

Re: Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

#179
post #160

Earlier 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.

Yes, really. The design has been decided upon ( https://hackmd.io/nNHdKkp1TTK7jat0I-ABqA ) and the implementation has been updated to match ( https://github.com/rust-lang/rust/pull/157428 ). The stabilization PR is just waiting on final approval by the relevant team members, with no remaining concerns currently listed: https://github.com/rust-lang/rust/pull/156882#issuecomment-5...
Post reply on HN