4 ms·
I don't know how suggesting tighter TTLs is indicative of "the industry eating itself" or that we can't fix email at the same time. Relax. "com" and "." can ob
by QuadrupleA 6y ago
I don't know how suggesting tighter TTLs is indicative of "the industry eating itself" or that we can't fix email at the same time. Relax.
"com" and "." can obviously be cached a long time, they'll rarely change servers. No need to walk the whole tree every time - god forbid between multiple requests made by a single webpage like you're implying. Subdomains are typically only 1 or 2 names on top of the TLD.
I'm all for being efficient with computer resources, and like others said there's a latency component here. But seriously, DNS packets are tiny, typically 50 bytes or so.
Assuming, say, 80 bytes after UDP, IP, Ethernet framing etc. (just a ballpark) that's 640/10,000,000,000 bits in 1 second of time on a 10gbps fiber, or about 1 of 1.5 million DNS packets that fiber (of many fibers) could send every second.
At that scale, I don't see why TTLs of say 1 minute wouldn't be fine. Multiply everything above by 60 seconds and that's still an effective cache of a 50 byte response in computer time. Authoritative NS records can change less often, so intermediate servers can just check direct with the authoritative servers when records go stale. Say 100 bytes roundtrip once a minute.
I'm not taking about throwing away or redesigning DNS - just that tighter TTLs than typically recommended are probably fine and would make life a little easier with propagation delays.
- carlhjerpe 6y agoCloudflares automatic TTL is 5 minutes. Web browsers will look up your records and try to connect to one of the returned ips, if that one doesn't work it'll use another one. The fact that the client does this for us means we can keep the TTL quite high (5 minutes) without 5 minutes downtime if we lose connectivity to one IP. This is also used to load balance, a single load balancer can't handle a trillion connections, so we round robin DNS for load balancing before the load balancers. There's also anycasting which is something cloudflare uses a lot. Which means you're announcing the same IP block from many locations, and with how BGP works (which is the defacto protocol for exchanging route information on the internet) the "closer" you are the more likely the route is to be chosen (AS path distance). Meaning sites behind Cloudflare is protected by thousands of servers listening to the two same addresses you see if you're behind a Cloudflare protected site and behind these thousands of servers are even more thousands of servers. This means if i were to launch a 10Gbps DoS from my server, it would hit the Cloudflare datacenter closest to me, and there's nothing i can do about it, meaning the rest of the world is unaffected. No, I'm not afiliated with CF. It's just an approachable example, i believe (but don't know) that Fastly has the same featureset (that I've mentioned above)