3 ms·

I've been thinking of adding this exact feature to my DNS framework that I've been working on (if github was resolving): https://github.com/bluejekyll/trust-dns

• bhauer 10y ago
  Sounds promising. I'll want to take a look when GitHub is resolvable again. :)
• Kalium 10y ago
  To be perfectly honest, a "feature" like this has no business being in a safe and secure DNS server. You should fail-safe, rather than serving stale data of unknown safety. Serving data you cannot verify is a dangerous failure state.
  • bluejekyll 10y ago
    Perhaps. In this case the web was down. I definitely understand the point, stale data with TTLs which have expired, especially on RRSIG records is dangerous. But I have to wonder about situations like this where DNS has been taken down, what the better good is. If the records can be proven to have been cached as authentic data at some point within some period of time. In this case hours, is it for the better good that stale authentic records are acceptable to serve back? In this case a stale period of some number of hours would have been good. I'm not so sure which is better in this case.
    • Kalium 10y ago
      Would you believe me if I said that the DNS protocol itself has an answer for this? The answer is in the basic design of what a TTL is. It's preferable to serve nothing than to serve known bad data. Stale data is a form of bad data. As another user put it, we have these standards for good reason.