← simple version · every parameter exposed
Measures how long a hostname takes to resolve, using only JavaScript — by deliberately blocking Chrome’s host-resolver job queue so the lookup under test runs alone between two markers.
kDefaultMaxSystemTasks). We start nfill = 63 requests to
hold<ms>-….<zone>, names whose authoritative server answers only
after hold ms. After ~2.6 s all 63 jobs occupy slots and the queue is
saturated, with exactly one slot left.
https://t0-<id>.invalid:0/ — port 0 is rejected in
HttpStreamFactory::Job::DoStart() before a resolver job exists, so it
costs no slot and no DNS query but still gives us a timestamp.
m1..m3-<id>.<zone>:<dead-port> are queued with
priority: 'low'. They cannot run until the target’s job finishes and frees
its slot, so m1 settles a fixed instrument cost after the target’s answer.
d1 = m1−m0 is target + one marker,
d2 = m2−m1 and d3 = m3−m2 are one marker.
Hence dns = d1 − (d2+d3)/2: the marker’s cost and Chrome’s
completion pipeline cancel out of the answer.
Expected accuracy (validated against tcpdump on Chrome 156 / Linux):
σ ≈ 2 ms single shot, ≈ 1 ms for the median of several reps.
Repeating the same hostname is only meaningful with a fresh name (Chrome’s host
cache lasts ~60 s), which is what the {id} placeholder is for.
{id} random token, {i} filler index, {k} marker number,
{zone}, {hold}, {mport}.
The filler name must make your authoritative server delay its answer by hold ms;
the marker name must resolve successfully (so Chrome does not retry it) to an address
where mport is closed (so the connection fails immediately).
One URL per line. {id} is replaced with a random token, which both
guarantees a cold host-cache entry and lets you repeat a measurement immediately
(e.g. https://d0-{id}.l.hamshukim.homes/). Without {id} a name
can only be measured once per ~60 s; repeats are then spaced out automatically.
| target | rep | dns ms | d1 | marker | d2 | d3 | fillers | verdict |
|---|