You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit a2e760a
Browse filesBrowse the repository at this point in the historyBrowse files
fix(dns): serve the real TTL instead of zeroing it, reverting the P2-5 direction
The audit treated the comment above the A/AAAA rewrite ("set TTL to 0 to prevent
downstream caching while we manage it") as the contract and made every delivery
path agree with it: the cache-hit packing path stopped re-stamping records whose
stored TTL was zero. That was the wrong direction. Returning the real TTL is the
intended design - the comment describes an older implementation and was never
updated - and the hit path, which already stamped the remaining lifetime, was the
part that matched the intent, while the first response carried the leftover zero.
Answers now carry a real TTL on every path: the upstream value on the first
response and the remaining lifetime on a cache hit, so a client no longer sees a
different answer depending on whether the entry happened to be cached. The
A/AAAA rewrite in NormalizeAndCacheDnsResp_ is gone; the entry lifetime is still
computed from the retained records before it, and freshness continues to be
tracked by the entry deadline and the stale window rather than by asking
resolvers not to cache.
Tests follow the behaviour they describe: the materialization cases assert a real
TTL in [1,60] on both miss and hit, the shared record policy asserts that a
record stored with TTL 0 is stamped with the remaining lifetime, the EDNS refresh
case asserts the remaining 30s (it packs the state 30s before the deadline), and
the corpus fixtures expect a real TTL range.
0 commit comments