perf(cache): rewrite TTLs at known offsets instead of caching a second copy

[henry40408]

Follow-up to #252, and the last technique from Cloudflare's DNS cache memory write-up that applies here: store offsets, not a duplicate.

The problem

Serving a cache hit meant decrementing every TTL by however long the entry had been cached, done by parsing the message and re-encoding it. That cost ~30–50µs, so the result was cached on the entry for the rest of that integer second — a second full copy of the response, behind a Mutex, for every hot entry.

But the stored bytes and the served bytes differ by a four-byte field per record plus the two-byte transaction ID. Caching a whole response to avoid recomputing a dozen bytes is the trade this removes.

The change

src/dns/ttl.rs walks the wire format once, at insert, and records where the TTL fields are (ttl_offsets). A hit is then a copy plus a handful of writes at known offsets (apply_elapsed). No parse, no re-encode, no snapshot, no lock.

Serving also stops perturbing the response: the client gets the upstream's own bytes with adjusted TTLs, where a re-encode rewrote name compression and record order to hickory's conventions.

The sharp edge

⚠️ Two record types carry something other than a TTL in the TTL field. OPT's four bytes are the extended RCODE, the EDNS version and the DO flag (RFC 6891 §6.1.3) — decrementing them corrupts DNSSEC signalling while still parsing cleanly. TSIG's must be transmitted as 0 (RFC 8945 §4.2).

The parse-based path got this for free, because hickory keeps OPT in Message::edns and TSIG in Message::signature, outside the three record sections. A wire walk has to know. tests/ttl_test.rs (12 cases) covers both, plus compression pointers, a CNAME chain, records after a 255-byte TXT, an unknown record type with opaque RDATA, and six malformed messages that must serve unchanged rather than panic.

Numbers

10,000 entries, 106-byte average wire payload:

	#252	this
cold entry	504.6 B	498.2 B
added by serving	106.2 B	0.2 B
served entry	610.8 B	498.5 B (-18.4%)
overhead vs wire	5.76x	4.70x

Cache-hit throughput, five cache_hit_bench runs each on the same machine:

	runs (qps)	median
before	2.61M, 3.17M, 3.28M, 4.01M, 4.08M	3.28M
after	4.08M, 4.16M, 4.31M, 4.60M, 4.97M	4.31M (+31%)

This benchmark is noisy — hence five runs rather than three — but the two ranges only touch at one endpoint. The gain is the parse being gone rather than amortised.

Notes

• decrement_ttl moved from handler.rs to the new module and is now a thin wrapper over scan-then-apply, for callers patching bytes a single time. Its three existing tests moved with it.
• CacheValue::try_patched_bytes / store_patched_bytes and PatchSnapshot are gone, along with parking_lot::Mutex from cache.rs.
• The memory bench's serving phase now measures that serving retains nothing, which is what would regress if a snapshot ever came back.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 98.90110% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.92%. Comparing base (e19a18e) to head (8328a89).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
src/dns/ttl.rs	98.43%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #254      +/-   ##
==========================================
+ Coverage   90.90%   90.92%   +0.02%     
==========================================
  Files          29       30       +1     
  Lines       10738    10763      +25     
==========================================
+ Hits         9761     9786      +25     
  Misses        977      977              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.