mirror of
https://github.com/isc-projects/bind9.git
synced 2026-05-28 04:34:54 -04:00
2a5e0232ed
When introducing change 5149, "rndc dumpdb" started to print a line above a stale RRset, indicating how long the data will be retained. At that time, I thought it should also be possible to load a cache from file. But if a TTL has a value of 0 (because it is stale), stale entries wouldn't be loaded from file. So, I added the 'max-stale-ttl' to TTL values, and adjusted the $DATE accordingly. Since we actually don't have a "load cache from file" feature, this is premature and is causing confusion at operators. This commit changes the 'max-stale-ttl' adjustments. A check in the serve-stale system test is added for a non-stale RRset (longttl.example) to make sure the TTL in cache is sensible. Also, the comment above stale RRsets could have nonsensical values. A possible reason why this may happen is when the RRset was marked a stale but the 'max-stale-ttl' has passed (and is actually an RRset awaiting cleanup). This would lead to the "will be retained" value to be negative (but since it is stored in an uint32_t, you would get a nonsensical value (e.g. 4294362497). To mitigate against this, we now also check if the header is not ancient. In addition we check if the stale_ttl would be negative, and if so we set it to 0. Most likely this will not happen because the header would already have been marked ancient, but there is a possible race condition where the 'rdh_ttl + serve_stale_ttl' has passed, but the header has not been checked for staleness. |
||
|---|---|---|
| .. | ||
| notes-9.17.0.rst | ||
| notes-9.17.1.rst | ||
| notes-9.17.2.rst | ||
| notes-9.17.3.rst | ||
| notes-9.17.4.rst | ||
| notes-9.17.5.rst | ||
| notes-9.17.6.rst | ||
| notes-9.17.7.rst | ||
| notes-9.17.8.rst | ||
| notes-9.17.9.rst | ||
| notes-9.17.10.rst | ||
| notes-9.17.11.rst | ||
| notes-current.rst | ||