Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 305 posts

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

#71

Post by otterley »

pbhjpbhj wrote: post #62
otterley wrote: post #54

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.

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

#73

Post by cakoose »

irdc wrote: post #4

This is why system programming still matters. Looks like they're missing the obvious optimisation of putting the record data right after the CacheEntry members instead of allocating memory separately though. But that might just be me as a C-programmer talking and not be all that easy in Rust.

> putting the record data right after the CacheEntry members

I assumed they couldn't do that because they're using it with some kind of generic HashMap. In that situation, can "V" be dynamically sized?

A dynamically sized "V" would mean you can't have an array of them, which might preclude some hash map implementations.

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

#74

Post by irdc »

listeria wrote: post #38
irdc wrote: post #4

This is why system programming still matters. Looks like they're missing the obvious optimisation of putting the record data right after the CacheEntry members instead of allocating memory separately though. But that might just be me as a C-programmer talking and not be all that easy in Rust.

Depends on how the CacheEntry is stored, it's probably stored in a slice of &[CacheEntry] which precludes storing the record data alongside it as the size of each entry must be fixed.

This is where hand-rolled intrusive data structures, as are traditional in C, really shine.

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

#75

Post by esterna »

cakoose wrote: post #73
irdc wrote: post #4

This is why system programming still matters. Looks like they're missing the obvious optimisation of putting the record data right after the CacheEntry members instead of allocating memory separately though. But that might just be me as a C-programmer talking and not be all that easy in Rust.

> putting the record data right after the CacheEntry members I assumed they couldn't do that because they're using it with some kind of generic HashMap . In that situation, can "V" be dynamically sized? A dynamically sized "V" would mean you can't have an array of them, which might preclude some hash map implementations.

> All type parameters have an implicit bound of Sized. The special syntax ?Sized can be used to remove this bound if it’s not appropriate.

, which HashMap does not do, i.e. the keys and values have to have a statically known size.

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

#76

Post by vanviegen »

lpapez wrote: 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.

Or optimize a bit earlier and prevent having to scale out to a bazillion systems.

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

#77

Post by robotresearcher »

auspiv wrote: post #36
bastawhiz wrote: post #24

Earlier quoted context omitted.

Maybe I'm misunderstanding, but this powers 1.1.1.1, it doesn't front an internal dataset. A cache miss hits a nameserver. Which is to say, the dataset is "every DNS record in the world"

I think the question is probably more along the lines of - why not do a database with 100 TB of storage/records instead of a cache? tomato / tomato.. especially with smart caching in front of database. 100TB of flash is a good bit cheaper than 100TB of memory

This is smart, task-specific caching in front of database.

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

#78

Post by robotresearcher »

fc417fc802 wrote: post #65
pbhjpbhj wrote: post #45

Earlier quoted context omitted.

>that is only good for the period of the TTL of the record. Not really, TTLs are often short, but IPs might not change for years. You can probably generate your own TTL, at scale, and avoid many DNS requests.

Why would anyone want to use a DNS resolver that tampered with records on a large scale? The TTL is intentionally set by the originator of the record. Or alternatively, if you don't tamper why would I want to use a service that serves stale data?

Every distributed system serves stale data.

You can define away ‘stale’ by picking a consistency model, but look inside the consistency machinery and you will see fresher data you aren’t allowed to have yet.

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

#79

Post by [deleted] »

cakoose wrote: post #73
irdc wrote: post #4

This is why system programming still matters. Looks like they're missing the obvious optimisation of putting the record data right after the CacheEntry members instead of allocating memory separately though. But that might just be me as a C-programmer talking and not be all that easy in Rust.

> putting the record data right after the CacheEntry members I assumed they couldn't do that because they're using it with some kind of generic HashMap . In that situation, can "V" be dynamically sized? A dynamically sized "V" would mean you can't have an array of them, which might preclude some hash map implementations.

[deleted]

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

#80

Post by asgraham »

FpUser wrote: post #33
vinkelhake wrote: post #30

These seem like some fairly standard approaches for reducing memory usage. I can't help to think that the approach of joining several distinct list into a single one in some way undercuts Rust's safety guarantees. If you previous had three distinct Vec objects, then Rust would guarantee that you can't index out of bounds. If you now put all those objects into a single Vec and rely on offsets, then you now open the do…

Tools exist to serve us, not the other way around.

Sure, and usually one of the ways Rust serves us is with safety guarantees.

Which isn’t to say this optimization is a bad idea, just to say it’s sort of a straw man to imply coding in Rust to take advantage of safety guarantees is “serving Rust”

Post reply on HN