Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



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


That's like refusing to use a fridge, insisting on letting your produce gradually spoil on the counter because "all harvested produce is in a state of decay anyway".

No, it's using a fridge in the understanding of the fundamental limitations of fridges.

You asked ‘why would I want to use a service that serves stale data’. The answer is you don’t want to. But if you have a distributed system your only choices are about the nature of the possible staleness, since global instantaneous consistency is known to be impossible due to fundamental features of the universe.


In that case you're (intentionally?) misinterpreting what I originally said. The person I replied to was metaphorically suggesting turning the temperature dial on the fridge way up and I metaphorically asked why I would want to eat at his house if he's going to be serving me spoiled food.

My original question could also be described as asking why I would choose to shop at a grocer where items on the shelf are routinely far past the printed expiry date. That's perhaps a more direct analogy.


Your additional explanation does help clarify your meaning.

Serving up records with TTLs in the past is so deeply weird that I didn't even consider that was what the grandparent had in mind.


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

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.

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.


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.

No, but if you didn’t, the internet wouldn’t really work all that well. It was the fact that participants, despite being independent, all agreed (either explicitly or implicitly) to adhere to the standards that it became a global network. If they hadn’t, the result would have been more of the same: independent networks that only had narrow interoperability at best. It’s a textbook example of how global cooperation can yield incredible results.

Advocating to do things against agreed-upon standards without a compelling reason and without giving due consideration to the adverse consequences is one of the hallmarks of a bad engineer. Even Microsoft played nice with Internet standards for the most part (although with some notable exceptions at the application layer that got them well-deserved criticism).


It was the fact that adhering to the standard was in the best interest of each participant. When it isn't, they don't.

It's impossible to know how often participants chose to stick to the standards anyway despite it not being in their best interest. Do you have any specific examples?

Linux routers responding ICMP from 192.0.0.8 when not having an IP address (currently being standardized). Clouds using class E address space (240.0.0.0-255.255.255.254). Routers that drop IP packets with options. The entire concept of NAT until the existing behavior was eventually standardized. Unnumbered interfaces.

I think all of those are examples of "[doing] things against agreed-upon standards [with] a compelling reason and [with] due consideration to the adverse consequences".

And the compelling reason is always profit.

"The entire concept of NAT" was for profit? "Linux routers responding ICMP from 192.0.0.8 when not having an IP address" was for profit? What?

The grocery store down the road only sells me things for profit but I hope you're not trying to imply that's somehow nefarious.


No it isn’t. Sometimes it’s security, or making the most out of limited resources.

Besides, not all profitable ventures are bad.


then they would be breaking DNS at scale.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: