Found by rolling the resolver out to the real cluster.
BlockList objects have no path, deliberately, so the first rollout downloaded
the list at every start. The cluster DNS that the download needs is this very
resolver, which was not up yet, so the first compile failed after 14 seconds,
held the DNS listeners closed for that long, and left the pod with no ad
blocking at all. Three changes:
* Lists from cluster objects get a copy under the runtime's own data directory
(data/lists/<name>), chosen by the runtime from the object's name, never by the
object.
* The copy is used as the answer only while it is younger than the list's
refresh interval, and otherwise the list is downloaded again, with the old copy
as the fallback if that fails. Before, any copy on disk was treated as current
for ever, so a list with a path was frozen at its first download. A source now
ages from its file, an operator's "refresh now" forces a download, and a
failed download keeps the stale copy.
* Startup loads only what is on disk (RefreshOffline), opens the listeners, and
fetches stale or missing lists in the background. The resolver answers at once
and the network is never on its critical path.
An address override answered as a redirect and so counted as a policy action:
with the access log logging redirects, every lookup of an internal name wrote a
line. Overrides from the managed source are local answers now; a redirect a list
imposes is still logged.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
matsandClaude Sonnet 5.5
0fdc828a10