TL;DR

  • A ten-tab browser restore puts 61 DNS queries on the wire in 145 ms, one hostname every 16 ms, and every hostname is asked for twice - an address record and an HTTPS record, 0.094 ms apart.
  • Scored one way that burst reads as irregular and human (CV 1.048); scored another way, the same 145 milliseconds reads as evenly paced and automated (CV 0.223). The only difference is whether the paired queries count as one event or two.
  • Against 74,882 real queries from 226 client addresses, a tab restore is more regular than the most machine-like moment 164 of 167 clients produced in 76 minutes.
  • Three corrections to our own account. This resolver counts every query, so a tab restore does not trip its timing check; the false positive we had explained as a tab restore was a sustained stream, not a burst; and the third, added on 27 August, withdraws the claim that the case was left unexplained - the durable enforcement record identifies the regularity feature that fired.

The claim that did not survive a capture

A design note explaining why a real user lost DNS resolution said that restoring ten tabs fires a tight cluster of lookups with near-identical gaps, so a timing check scores it as automated. It was written from reasoning rather than from a packet capture. Measured over ten runs per arm with headless Chrome and tcpdump, it is wrong at the granularity this resolver counts: a tab restore is one of the most irregular streams on the wire, because each hostname draws two queries that leave in the same microsecond and then nothing for 16 ms.

The counting choice nobody writes down

Collapse each address-plus-HTTPS pair into a single lookup and the metronome underneath appears: CV 0.223, against 1.048 for the identical traffic counted per query. A factor of 4.7 in apparent regularity, decided by an implementation detail. Disabling the browser's HTTPS-record lookups reproduces the low figure from the other direction, which means a browser that asks for HTTPS records looks 4.7 times more human than one that does not, and no user chose either setting.

Three hypotheses that failed

Encrypting the transport was expected to smooth the pacing; DoH and plaintext measured the same to three decimal places. A DoH connection lead-in of 886 ms in one pilot run collapsed to a 22 ms median over ten runs. And more tabs were expected to look more robotic: 25 tabs scored 0.351 against 0.223 for ten, because a longer list gives the browser room to queue and reorder.

What it cost us to check

The measurement forced a reread of the incident it was meant to explain, and the durable record disagreed with the story: 70 requests in five seconds and 80 more a minute later is a sustained stream, not a five-second burst. The explanation was wrong about the mechanism and wrong about the event, so the false positive is unexplained again. Every figure in the guide is a median over ten runs with its range printed beside it.

Correction, 27 August 2026

The paragraph above ends by saying that false positive is unexplained again. That was true when it was written and it is not true now. Read back from this resolver's own durable enforcement record two days later, the trigger was the same timing-regularity check the article is about, firing on the traffic shape the article had ruled out. Six evaluations landed inside one second; five scored a neutral 0.5 on an empty evidence set and the sixth scored 0.82 on a single feature, a coefficient of variation over the client's recent request intervals. That one uncorroborated signal denied the client the relief its earned history would have bought, and two bans followed 69 seconds apart at 70 and 80 requests. The rate ceiling was never crossed. A sustained, evenly paced stream is exactly what a scale-free regularity measure flags; the article had assumed only a tight burst could trip one. The correction is stated in full on the guide, alongside the sentence it corrects.