LEARN. PRACTICE. GROW.Observe the policy actually running
The runner’s second process receives data with a thirty-second TTL but applies a two-second cache-max-ttl. The next observation, after that cap, obtains the updated value through a new fixture request. The third process performs the opposite experiment: the fixture publishes a one-second TTL and cache-min-ttl is four. After one and a half seconds, the earlier address is still served without a new request. These are deliberate lab settings, not production recommendations. Compare the configuration files saved in configurations with maximumTTL and minimumTTL results. Explain why querying authority alone would be insufficient to predict each instance’s answer. In fictional case Farol, the team planned endpoint retirement from published TTL without knowing the managed resolver’s minimum. That decision must be revised before disconnecting the endpoint.
Separate mechanisms to avoid incorrect conclusions
The runner keeps prefetch and serve-expired disabled. This makes the observed sequence simpler but limits conclusions about other environments. An experiment with early refresh or expired data would need its own hypotheses and instrumentation. It also uses iterator without validator: checks do not demonstrate DNSSEC. The fund.test zone has a transparent local exception and a stub directed to the fixture; the remaining namespace has local refuse policy. The objective is therefore to measure cache with controlled data without depending on public delegations. Do not copy this configuration to a shared resolver. When adapting the lab, change one variable at a time and retain the earlier configuration as reference. If no requests reach the fixture, first check whether a local answer or a query to the wrong port diverted the path. An empty counter can usefully expose an incorrect hypothesis.
Run a change review using evidence
The guide below proposes forty minutes of work. During the first ten, identify fictional participants: application owner, DNS, production, and project manager. Distinguish who publishes, who manages cache, and who confirms the consumer. In the next ten minutes, read Farol’s results and decide necessary overlap without turning a lab number into a real SLA. Then assess Cais and Ria: a late-created name may require observing a negative answer; newly published AAAA requires tracking its type and the IPv6 path. During the final ten minutes, prepare RUN handover with measurable criteria, dependencies, and a decision point. The guide has not been performed with participants; it is an activity for the learner. Deliver a short plan that can be challenged with data instead of a command list lacking business context.
Define what supports acceptance or deferral
An acceptance proposal should state the expected name and type, relevant origins, observed resolver, and business operation to execute. Add checks for old connections when the application reuses them, the ability to retain the previous endpoint, and the owner authorized to approve retirement. Selective removal may be an option where permitted, but needs an expected effect, scope, and subsequent validation. A global flush is not automatically safer and may create unnecessary load. In case Duna, the local report is accepted as cache evidence; DNSSEC and application retain separate actions. Summary: treat TTL, local policy, and consumption as inputs to the change plan. Connect results to observability, incident management, and handover criteria. Decision quality depends on recognizing both what was measured and what remains unproven.
40-MINUTE GUIDE
0–10: identify owners, name, type, resolver, and origin.
10–20: compare positive, negative, nodata, maximumTTL, and minimumTTL in JSON.
20–30: decide for Cais, Ria, and Farol; record alternative and residual risk.
30–40: define acceptance, rollback, overlap, and Duna’s pending actions.
DELIVERABLES
One row per consumer: expected publication | observed answer | time | policy | application evidence | owner.
One proceed/defer decision with rationale, deadline, and missing evidence.
RUN THE PREVIOUS LESSON’S CODE
python3 dns-cache.py --unbound /path/unbound --checkconf /path/unbound-checkconf --dig /path/dig --output dns-cache-evidence.json
Prerequisites: Unbound 1.26.1, matching checkconf, Python 3, and dig; account without personal.digrc.
Recorded runtime was Python 3.13.1 with dig 9.10.6. Does not change system DNS.Farol published TTL 30, but the instance has a 300-second minimum. The team retains overlap and reviews retirement with DNS and consumers.
Common pitfalls
Applying experimental configuration to production, ignoring effective policy, confusing cache with DNSSEC, and assuming a DNS answer completes service validation.
Related topics: Rollback planning · Production handover
Acceptance needs the consumer’s real path and explicit criteria. A local test proves only the behaviors it actually exercised.
Reference: Unbound configuration manual · DNS RFC 1034/1035 with RFC 2181, 2308, 3596, 4033, 7766 and 8767; dig BIND 9.20