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

61–70 of 304 posts

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

#61

Post by fc417fc802 »

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

I'm no expert but presumably all of throughout, latency, and churn. DNS is approximately a giant KV store where the typical record has a TTL of ~5 minutes.

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

#62

Post by pbhjpbhj »

otterley wrote: post #54
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.

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) input blindly is not for me.

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

#63

Post by eviks »

win311fwg wrote: post #58
eviks wrote: post #44

Earlier quoted context omitted.

> Data structures, not algorithms, are central to programming So you agree that they should've designed the system to use the appropriate data structure from the beginning?

The existence of 1.1.1.1 speaks to a much larger design problem. If you want to talk about what should have been done, you need to step much, much further back.

I don't want to step back and go off topic

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

#64

Post by seiferteric »

ButlerianJihad wrote: post #59
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.

Actually that is not true. The IETF has expanded the definition of “TTL” and explicitly permits resolvers to serve “stale” RRs beyond their expiration time. https://www.rfc-editor.org/info/rfc8767/ As a corollary, there is obviously no floor on refetching unexpired RRs, of course, except for efficiency concerns.

That's only when the authoritative server cant be reached though

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

#65

Post by fc417fc802 »

pbhjpbhj wrote: post #45
seiferteric wrote: post #29

Earlier quoted context omitted.

You have to cache, cloudflare doesn't know all the records ahead of time, they have to do recursive lookups to the authoritative servers that own the records and that is only good for the period of the TTL of the record. There is no "global" DNS record database or something like that.

>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?

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

#66

Post by dizhn »

otterley wrote: post #54
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.

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.

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

#67

Post by edflsafoiewq »

General theme: A programming language's native in-memory object format is typically optimized for random access, uniformity, and mutability (fields at fixed offsets, etc). Serialization formats for network or disk tend to be designed explicitly to be more compact. But you can design your own in-memory representation too, with the properties you need.

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

#68

Post by lpapez »

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.

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

#69

Post by fragmede »

otterley wrote: post #56
mannyv wrote: post #23

One question the article doesn't answer is: why are they cacheing at all? If your cache is that big it isn't a cache. How much bigger is the dataset in question? There are 250 billion entries. Assuming 80/20, that implies 1.25 trillion records? What's the speed of service/response time relative to the data source? At that point it might be enough to replace your multiple caches with fewer in-RAM databases? It's an in…

The simple answer is that if you didn't cache, DNS traffic would skyrocket, and the load would pile up on the authoritative servers, which were intended to be small, and during the early days of the Internet, were frequently on bandwidth-constrained links. DNS is designed to distribute query load to the edge as much as possible, and that's enabled by caching. It just so happens that "the edge" is now becoming concent…

The problem is there is a noticable difference in behavior because the ISP cache is overloaded so queries take longer. Sure, that's not everyone's experience, but there's a reason people chose to use alternate servers.

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

#70

Post by f311a »

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.

Unfortunately, Rust is not a good choice for this kind of tricks. This is where Zig shines. In Rust, you can’t even use proper arenas, which can help a ton with allocations.

Cloudflare started to pick Zig recently, for projects, that have memory constraints.

Post reply on HN