An incident lead asks the exact date your DNS rule stopped matching - how do you establish it?

## Separate the three dates before you answer An incident lead who has been told for five months that DNS tunnelling was covered wants one number. Before you give one, split the question, because three different dates are being run together: - **The last true match.** When the rule last fired on something real. This is the easiest to look up and the most misleading: a rule that models a rare behaviour may legitimately not have fired for a year before it broke, so this date is an upper bound of the loosest kind. - **The date the input changed.** When the field the rule filters on was renamed, reshaped, moved or rerouted. This is the one you can actually measure. - **The date the rule could no longer match.** What the lead is asking for. In the rename case it equals the input-change date, but only once you have shown the rule depended on the old shape. ## The evidence, strongest first **1. Field population over time.** Count, per day, the events in the relevant log source that carry the field the rule filters on, populated and of the expected shape. A parser change produces a step: four million a day, then zero, with the new field name appearing at the same instant. This is the sharpest artefact available and it comes from data you already hold. Do the same for the value shape when the field survived - average and maximum queried-name length per day will show a truncation change just as cleanly as presence shows a rename. **2. A before-and-after record pair.** Two real events either side of the boundary, showing the old and new field names on the same resolver and the same client. This is what makes the step change legible to someone who is not a detection engineer. **3. The change record.** The parser pipeline's deploy timestamp and release note, and the rule's own version history showing it was not updated. Note the epistemics: a release note is evidence of a *deploy*, not of your rule's behaviour. It corroborates the step change; it cannot substitute for it. **4. Execution telemetry.** The scheduled search's run history - it ran, on time, scanning a healthy event count, matching zero. This closes the alternative explanation that the search simply stopped running. **5. The last canary firing.** If a canary existed, the last one it produced is a hard lower bound on the rule's health, dated to the minute. If none existed, say so plainly; that absence is part of the answer to why nobody noticed. ## Replay, and the trap inside it The obvious instinct is to re-run the rule over historical data. Be careful about what you would be measuring. If your platform stores events as parsed at ingest, historical data before the change carries the *old* shape and today's rule will match it - useful, and it confirms the rule's logic. If the store was reindexed or reparsed, everything now carries today's shape and a replay tells you about today, not about March. So establish which of those your platform does before quoting a replay result. The field-population series does not have this problem, which is why it leads. ## Bound the claim to what retention supports Suppose the parsed store keeps ninety days and the suspected break is five months old. You cannot show the step change; the oldest surviving day already carries the new field name. The honest statement is then a bound with its reasoning attached: *at the start of my retention window the field was already renamed, and the parser deploy record puts that change on the fourteenth of March; so the rule was mute no later than the fourteenth of March, and probably from that date, but the direct evidence for the exact day is gone.* Say which half is observation and which is inference. An incident lead can work with a bound; nobody can work with a confident number that turns out to be a release note read backwards. This is also the argument for keeping cheap aggregate metrics far longer than raw events. A daily count of events by log source and key field costs almost nothing to retain for years and would have closed this gap exactly. ## What the date does, and does not, license Two claims the lead will try to derive, and only one of them follows. It **does** bound the window in which this rule could not have contributed. That is a real, useful statement about your coverage during the intrusion, and it belongs in the case record with the queries used, so somebody else can re-derive it. It **does not** establish that a working rule would have caught the activity. `Would have evaluated the data` and `would have matched` are different claims, and the second depends on whether this tunnelling implementation's query shape crossed the rule's thresholds. If pre-change data survives, test it and report the result. If it does not, say so - resist trading a broken assurance for an unprovable one. It also does not establish when the intrusion began; the tunnelling has its own timeline, built from the resolver data itself, and it may predate the mute entirely, which would mean the rule ran against the traffic and did not match it. That finding is worse than the parser bug and it is the one you must not bury.