Poster: Mind the Gap -- Characterizing the Temporal Blind Spot Between GSB and DNS Resolution
Source: arXiv:2607.06134 · Published 2026-07-07 · By Tomer Gal, Fujiao Ji, Doowon Kim, Harel Israel Berger
TL;DR
This poster paper investigates the packet-level timing relationship between Google Safe Browsing (GSB) query closure events and parallel DNS resolution responses during browser navigation. The authors identify a consistent positive timing gap, where DNS final resolution occurs after the GSB-related query has closed. Using packet captures over two datasets—general popular domains and CNAME-intensive domains—they find that roughly 79% of samples show this timing gap, with median delays around 67 to 79 ms and maximum delays exceeding 2,400 ms. These results reveal a measurable temporal window where the browser completes safety checks before fully resolving the final DNS endpoint, raising potential security concerns under DNS manipulation threat models.
Key findings
- Positive timing gaps between GSB query close and DNS response observed in ~78% of general domain samples (78/100) and ~79.6% of CNAME domain samples (82/103).
- Median timing gap is 79.40 ms in the general dataset and 67.88 ms in the CNAME dataset.
- Maximum observed timing gaps exceed 2,300 ms in both datasets (max 2349.54 ms general, 2477.32 ms CNAME).
- Representative large timing gaps include amazonaws.com with 1034 ms difference, twitter.com with 566 ms, and office.com with 403 ms.
- Timing gaps exist despite browser-level clearing of DNS and cache state, indicating a structural temporal offset.
- CNAME-resolution domains show similar frequency of timing gaps as general domains but slightly lower mean gaps (178.79 ms vs 248.12 ms).
- These timing windows form a potential precondition for attacks exploiting desynchronized resolution and safety decisions.
- The authors do not claim a full GSB bypass but highlight the timing mismatch as a security-relevant vector.
Threat model
The adversary is a network attacker capable of influencing DNS resolution results, for example via cache poisoning, malicious DNS resolvers, or on-path attacks. The attacker cannot directly tamper with GSB decisions or browser internals but aims to exploit timing windows where DNS resolution completes after GSB checks have finished to cause mismatches between the safe browsing verdict and the final resolved endpoint.
Methodology — deep read
The study aims to quantify the timing gap (∆time) between the completion of Google Safe Browsing (GSB) checks and the arrival of the final DNS resolution response during browser navigation. The threat model considers adversaries capable of influencing DNS responses via cache poisoning, resolver manipulation, or on-path control, but not able to bypass the full browser security stack.
The authors define the timing gap metric as ∆time = Tresolution - Tquery_close, where Tquery_close is the timestamp of the TCP FIN or RST packet closing the GSB-related TLS connection (identified via TLS SNI metadata), and Tresolution is the timestamp of the final DNS response packet containing the A/AAAA record. Positive ∆time indicates DNS resolution lagging behind the GSB query close.
Data was collected from two datasets derived from the Tranco top sites list: (1) a general dataset with the top 100 popular domains, and (2) a CNAME dataset consisting of 103 domains requiring multi-step CNAME DNS resolution. Each domain's page was loaded multiple times on a macOS machine running Google Chrome Stable with cleared DNS and browser caches before navigation to minimize caching effects.
The authors used a Node.js automation framework combined with Tshark packet captures. For each navigation, they launched a fresh ephemeral Chrome instance, captured DNS and HTTPS packets, and extracted Tquery_close and Tresolution timestamps per their metric definition. The data was analyzed per sample and aggregated across datasets.
Evaluation focused on the frequency, magnitude, and distribution of positive timing gaps. Representative domain-level timing gaps were reported alongside dataset-wide median, mean, and max values. Direct statistical tests and confidence intervals are not mentioned. They also discuss variation across domains and between general and CNAME datasets.
Reproducibility details: the authors mention automated tooling, clear methodology for event extraction, and data provenance from Tranco list domains. No public code or datasets are explicitly released. The work is a packet-level measurement study without controlled adversarial injection experiments or mitigation validations.
One example: for amazonaws.com, query close was observed at 1.426 s and DNS response at 2.460 s (569 ms gap). This illustrates a long timing discrepancy that may affect the integrity of simultaneous safety and resolution checks.
Technical innovations
- Definition of a concrete packet-level metric (∆time) quantifying the timing gap between GSB query close and DNS resolution response.
- Empirical measurement of GSB-DNS timing synchronization across general and CNAME domain datasets via combined HTTPS and DNS packet captures.
- Discovery that positive timing gaps occur in ~79% of cases, revealing a consistent temporal blind spot with potential security implications.
- Characterization of timing gap magnitude variation, including outliers surpassing two seconds in delay under real-world browsing scenarios.
Datasets
- General Domains — 100 samples — Top 100 Tranco domain list
- CNAME Domains — 103 samples — Selected Tranco domains requiring CNAME resolution
Baselines vs proposed
- No explicit baselines or prior models compared; measurements characterize timing gaps within browser workflows under standardized conditions.
Limitations
- No active adversarial DNS manipulation experiments to confirm attack feasibility.
- Measurements limited to Google Chrome on macOS; applicability to other browsers and OSes untested.
- Dataset limited to top-ranked domains from Tranco, may not represent broader web diversity.
- No temporal correlation with broader network conditions or caching beyond system-level cache clearing.
- Unable to conclude full browser or GSB bypass, only identify timing preconditions.
- No evaluation of mitigation techniques or revalidation mechanisms.
Open questions / follow-ons
- Can the measured timing gaps be exploited in real-world end-to-end attacks to bypass Safe Browsing protections?
- How do timing gaps vary across different browsers, operating systems, and network configurations under realistic conditions?
- What mitigation strategies can browsers implement to bind Safe Browsing decisions to final DNS endpoints or trigger revalidation upon late DNS responses?
- How do longer or more complex CNAME chains impact the magnitude and frequency of timing gaps?
Why it matters for bot defense
This study highlights a subtle but potentially exploitable timing desynchronization in the browser's web resource loading workflow where security checks complete before the final DNS endpoint is resolved. For bot-defense and CAPTCHA practitioners focused on bot detection and risk analysis, this underscores that timing-based inconsistencies in client-side safety validation can open attack vectors involving DNS manipulation and endpoint spoofing. Understanding such timing blind spots is crucial when designing multi-step validation pipelines or CAPTCHA challenge triggering heuristics tied to the final network resource identity. While this work does not propose immediate exploit methods or defenses, it sets a foundation for analyzing timing vulnerabilities that may interfere with endpoint reputation checks or heuristic behavior-based bot analysis relying on consistent network domain resolution.
Cite
@article{arxiv2607_06134,
title={ Poster: Mind the Gap -- Characterizing the Temporal Blind Spot Between GSB and DNS Resolution },
author={ Tomer Gal and Fujiao Ji and Doowon Kim and Harel Israel Berger },
journal={arXiv preprint arXiv:2607.06134},
year={ 2026 },
url={https://arxiv.org/abs/2607.06134}
}