Enhanced Performance and Privacy via Resolver-Less DNS

Erik Sy

REVIEW 4 major objections 6 minor 12 references

Enhanced Performance and Privacy via Resolver-Less DNS

T0 review · 4 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A proposed DNS-Record HTTP header lets web servers hand clients DNS answers, letting those clients skip a resolver round trip on later connections.

desk verdict A genuine, clearly-described proposal for a DNS-Record HTTP header with honest measurements, but the abstract overstates the censorship-resilience claim for non-TLS traffic. read the letter →

arxiv 1908.04574 v1 pith:QFYUMMEU submitted 2019-08-13 cs.NI cs.PF

Erik Sy This is my paper · ORCID

classification cs.NIcs.PF

keywords DNSresolver-lessHTTPresponseheaderDNS-Recordrecursiveresolverwebperformanceprivacycensorshipresistance

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Resolver-less DNS proposes that web servers include their own DNS answers in an HTTP response header, so a client that has already fetched a page can open later connections to the same hostnames without asking a recursive resolver. The paper's central performance claim is that the slowest 1% of users, whose round-trip time to their resolver is at least 80 ms in the presented measurement, save that much per avoided lookup; the same mechanism also sends fewer queries to the resolver, so the resolver observes less of the user's browsing activity. The paper argues that this does not weaken security: because server-supplied records cannot be cryptographically authenticated, clients must validate them through server authentication or a fallback DNS lookup before sending data over an insecure connection. If that validation is followed, resolver-less DNS offers at least the security guarantees of traditional DNS and is harder for a tampered resolver to censor.

What carries the argument

The central object is the DNS-Record HTTP response header field, which carries key-value pairs for hostname, A and AAAA addresses, and their TTLs, letting a web server push name-resolution results to the client inside the response it is already sending. The companion mechanism is the validation strategy in Figure 2: records are used to initiate connections, but application data may be sent only after server authentication succeeds or after a fallback DNS lookup produces matching results. The performance evaluation rests on a distributed-node measurement of the round-trip time between clients and their preconfigured recursive resolvers, along with fresh-record TTL and ECS-scope measurements, which together bound the saved time and the server's added lookup load.

What would settle it

Measure client-to-resolver RTTs on a broad sample of access networks and countries; if the 99th percentile falls well below 80 ms, the paper's headline minimum saving does not hold there. Separately, instrument a browser that accepts DNS-Record headers and record whether it sends plain HTTP to the address in a fake record before any fallback lookup completes; any such transmission for a non-registered hostname would refute the claim that resolver-less DNS is at least as secure as traditional DNS.

Watch

Extended reading notes

Core claim

The paper's central claim is that DNS resolution for repeat connections can be moved from the recursive resolver to the web server without weakening security. A server sends a DNS-Record header in an HTTP response; the header carries the hostname, IPv4 and IPv6 addresses, and TTLs. The client stores the record as resolver-less and, on a later connection, uses it directly, saving the client-to-resolver round trip. Because the record is unauthenticated, the client follows a two-branch validation strategy: if the connection will use server authentication, the successful authentication validates the record; otherwise the client must compare the record with a fallback DNS lookup and send data only when both agree. The paper's measurements of client-to-resolver RTTs, DNS record TTLs, and EDNS client subnet support are presented as evidence that the savings are real, the server-side cost is modest, and the design is compatible with today's DNS.

Load-bearing premise

The security and censorship-resilience claims hold only if the client's fallback DNS mechanism still returns trustworthy records and the user agent actually performs a fallback comparison before sending any application data over an insecure connection; a browser that sends plain HTTP on the strength of a server-supplied record alone would let fake-record attacks succeed.

Editorial extensions

If this is right

High-latency users gain the most: for the 1% with the longest resolver RTTs, each avoided lookup saves at least 80 ms, and savings are larger whenever the resolver would have had to perform iterative queries.
The recursive resolver sees fewer queries, weakening its ability to reconstruct browsing sessions or link them across time.
DNS-based censorship becomes harder because a client can obtain correct records directly from the server over an authenticated connection, bypassing a tampered resolver.
Deployment is incremental: no change to the DNS protocol, middleboxes, or client kernels is needed, only support for one header in servers and user agents.
Server-side cost stays modest because most popular hostnames use TTLs of five minutes or longer, so cached DNS-Record headers require infrequent refreshes.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The 80 ms figure is a lower bound measured only on client-to-resolver RTT, so on networks with frequent resolver cache misses or in regions with slower access links the real per-lookup saving is likely larger; a replication across more countries and mobile networks would show how much.
The case analysis implies a testable deployment condition: if a browser ships resolver-less DNS without the fallback check on plain-HTTP traffic, the security guarantee degrades to exactly the paper's cases 1 and 3, so the feature should be disabled unless the enforcement path is verified.
A natural extension, not explored in the paper, is to let the server push records for multiple third-party origins used by the page, turning the header into a resource-hint plus resolution mechanism that could be combined with HTTP/3's always-authenticated transport.
The whitelist idea suggests an economic consequence: large content providers could become their own resolvers for their traffic, shifting name-resolution trust from ISPs to the providers themselves, which would change where the residual privacy leak sits.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Short version: this is a real proposal, not a repackaging. The DNS-Record HTTP header idea, where servers push A/AAAA records and TTLs to clients, is distinct from the Oblivious DNS, DNS Anonymity Service, and prefetching work it cites. The measurements are presented in good faith: the 80 ms headline is explicitly a lower bound for the 99th percentile RTT, the TTL survey is reproducible, and the ECS finding (almost 90% globally scoped) is useful. The privacy argument is modest but sound for HTTPS traffic, since fewer queries reach the resolver.

The soft spots are real and concentrated in the security and censorship claims. The abstract says the proposal “even improves the user’s resilience against censorship through tampered DNS resolvers” without the qualification that appears in Section 5.1: the censorship benefit only holds for connections using server authentication. For plain HTTP, the Figure 2 validation strategy requires a fallback DNS lookup, and when the resolver-less and fallback records differ, the client uses the fallback record. If the fallback resolver is tampered, the censored answer wins. So the resilience claim is true only on the TLS branch. That is a mismatch between the abstract and the body, and it should be fixed before the paper is cited for that claim.

The security comparison also rests on a load-bearing assumption, stated in Section 5.1: that the fallback DNS mechanism “still provides trustworthy DNS records” and that clients actually implement the full validation strategy. This is a deployment-behavior premise, not a consequence of the design. The paper is honest about it, but the abstract’s “at least the same security properties” overreaches what the case analysis supports.

Minor issues: there is no prototype or implementation, so feasibility is argued from measurements rather than demonstrated. The paper also omits Alt-Svc and DNS-over-HTTPS, the two most relevant adjacent mechanisms; a serious comparison with them is needed. The 20-hostnames-per-website workload assumption comes from the author’s own earlier work and is plausible but not independently checked.

Bottom line: the core idea is coherent and worth testing. The measurements are honest and the limitations in Section 5.1 show clear thinking. The paper needs a revised abstract, a direct statement that the censorship benefit is limited to server-authenticated connections, and ideally a prototype or simulation of the validation logic. It deserves a serious referee and, after revision, could make a solid short-paper or workshop contribution.

Referee Report

4 major / 6 minor

Summary. The paper proposes a new HTTP response header field, DNS-Record, through which a web server can provide the client with A/AAAA records and TTLs for hostnames relevant to the page. Clients cache these records and use them to open subsequent connections without contacting a recursive resolver, subject to a validation strategy (Figure 2) that requires server authentication or a fallback DNS comparison before application data is sent over insecure connections. To estimate benefits, the authors measure RTTs between 650 RIPE Atlas nodes in Germany and their preconfigured resolvers, retrieve TTL and ECS-scope data for Alexa Top 10K sites, and conclude that clients save at least 80 ms per lookup for the slowest 1% of users, reduce resolver-visible queries, and retain or improve DNS security/censorship resilience. The paper does not implement a prototype; the evaluation is based on external measurements and design reasoning.

Significance. If the central claims survive scrutiny, the contribution is useful: it is a deployable, HTTP-level mechanism for reducing DNS latency and resolver exposure, with a simple server-side integration story via CDNs. The measurement parts are transparently reported (dates, sample sizes, tools) and the 80 ms figure is presented as a lower bound, which is methodologically honest. The TTL and ECS measurements provide useful evidence about feasibility. However, the paper currently overstates both performance and security benefits: under its own validation rules, insecure connections still require a fallback lookup, and the censorship-resilience benefit holds only for server-authenticated connections. These issues are fixable by qualifying the abstract and conclusions and by adding an explicit threat model, so the underlying idea remains viable.

major comments (4)

[3.2.2 / Figure 2; 4.1.2] The headline performance claim that resolver-less DNS 'allows user agents to save the DNS lookup time' is not supported for insecure connections. The right branch of Figure 2 requires a fallback DNS lookup before any application data can be sent unless the server authenticates during the connection, and on a mismatch the client must use the fallback record; the text also instructs the user agent to start that fallback lookup 'as early as possible' on this branch. Consequently, for plain HTTP the lookup is at best parallelized rather than eliminated, and the measured 99th-percentile RTT of 80 ms is a saving only for connections that can be validated by TLS authentication or by the proposed whitelist. Since the paper itself cites data that roughly 20% of HTTP requests are not HTTPS, this is a substantial portion of traffic, and the abstract should be qualified accordingly.
[5.1 and Abstract] The claim that resolver-less DNS 'even improves the user's resilience against censorship through tampered DNS resolvers' is made without qualification in the abstract and in design goal 9, but the body of Section 5.1 restricts it to 'connections ... established using server authentication.' Under a tampered resolver, the fallback DNS mechanism is untrustworthy by the paper's own definition, and for insecure connections the validation strategy directs the client to use the fallback record (right branch of Figure 2), so the tampered answer wins. The censorship-resilience claim should be restated as applying only to connections with server authentication, or the design must be changed so that insecure traffic can use resolver-less records without trusting the fallback.
[5.1, four-case analysis] The security argument assumes that 'the fallback DNS mechanism still provides trustworthy DNS records' and that the client performs the full Figure 2 validation before sending insecure data. This assumption is load-bearing: for insecure traffic the only protection is that the client compares the server-supplied record with the resolver's answer, and if the resolver is malicious both answers may be controlled by adversaries who can also influence the server-side header. The paper does not provide a threat model for this setting, nor does it analyze the whitelist mechanism (Section 3.2.2), where a whitelisted provider or a compromised provider within the whitelist can supply arbitrary records without fallback validation. Without this analysis, the conclusion that resolver-less DNS 'achieves at least the same security properties' as traditional DNS is not established.
[Section 4 (overall)] The performance evaluation is an indirect approximation and does not include a prototype or end-to-end measurement of the DNS-Record mechanism. The paper measures RTTs to resolvers, TTL distributions, and ECS scopes, but does not measure actual page-load time or server-side lookup overhead with the proposed header; Section 4.2 infers 'small number of additional DNS lookups per minute per website' from per-record TTL distributions without modeling the number of hostnames per page, cache behavior, or the frequency with which the server must refresh records. The 80 ms figure is a lower bound on the time that could be saved, not a measured end-to-end saving. The paper should either add a prototype or clearly reposition the contribution as an analytical feasibility study rather than an empirical demonstration of the performance claim.

minor comments (6)

[3.2.2] There is a typo in 'it's identity' that should read 'its identity'.
[6] The related-work section refers to 'Oblivous DNS'; the correct spelling is 'Oblivious DNS'.
[4.3.1] The ECS measurement uses a single announced client subnet from one hosting provider; the conclusion that 'almost 90% of the DNS records are valid on a global scope' should be accompanied by an explicit statement that this may not generalize to other vantage points.
[4.2.2] The assumption that a website requires a fresh cache of about 20 hostnames per website is cited to [24], but the paper does not explain how this number is derived or how it maps to the set of hostnames for which the server would actually provide DNS-Record headers.
[References] References [25] and [26] appear to be the same arXiv paper (1907.01291) listed twice; one entry should be removed.
[Figure 2] The branch labels in Figure 2 are difficult to parse, particularly the difference between 'Other URL' and the left branch condition; a more precise description of the conditions would improve reproducibility.

Circularity Check

0 steps flagged · score 2.0 of 10

No load-bearing circularity: performance claims rest on independent external measurements; one minor self-cited workload parameter is not load-bearing.

full rationale

The central performance claim is derived from independent measurements, not from fitted inputs or from the proposal's own definition. Section 4.1 measures RTTs from 650 RIPE Atlas nodes to their pre-configured resolvers and directly uses the measured 99th percentile (80 ms) as the savings floor for the slowest 1% of users; this is an external benchmark, not a parameter fitted to the paper's conclusion. The TTL analysis in Section 4.2 and the ECS analysis in Section 4.3 similarly rely on independent measurements of Alexa Top 10K sites and Google Public DNS responses. The only self-cited input is the roughly 20 hostnames-per-website workload assumption taken from the author's prior work [24]; it is an empirical, externally falsifiable measurement used only for the server-side DNS overhead estimate in Section 4.2, not for the user-side latency saving, so it does not make the central claim circular. The security discussion in Section 5.1 is explicitly conditional: for insecure connections the validation strategy forces a fallback DNS lookup, and the paper states that attacks are prevented only 'if the fallback DNS mechanism still provides trustworthy DNS records.' That is a stated deployment assumption rather than a hidden reuse of the security conclusion. The abstract's unqualified censorship-resilience claim is broader than the paper's own Section 5.1 qualifier that the improvement applies 'when these connections are established using server authentication'; this is an internal-consistency or correctness concern, not a circular derivation. No equation, fitted parameter, or self-citation chain reduces the paper's predictions to its inputs.

Assumptions & free parameters 0 free parameters · 7 assumptions · 2 invented entities

The central claim rests on measured quantities plus conventions about how clients and servers behave. Measurements (resolver RTT from 650 German RIPE Atlas nodes, TTLs from Alexa Top 10K, ECS scopes from Google Public DNS) enter as empirical inputs, not fitted parameters. The design-specific behavioral premises are the client validation strategy, trustworthy fallback DNS, server-side header merging, and the roughly 20 hostnames per page workload assumption.

assumptions (7)

domain assumption The client-to-resolver RTT is a lower bound for DNS lookup time (resolver processing and iterative queries on cache misses are extra).
Section 4.1 states the RTT 'presents only a lower boundary for the DNS lookup time as we neglect the time required by the resolver to process the query'; Section 2.2.1 cites 25% of DNS transactions taking 10 ms to 1 s.
domain assumption The 650 German RIPE Atlas nodes, measured on 13 June 2019 with five pings each, represent typical clients including the high-latency tail.
Section 4.1.1 limits the sample to Germany and aims at 'a realistic representation of typical Internet accesses in countries similar to Germany'; the headline 80 ms figure is the 99th percentile of this sample.
domain assumption Web servers will resolve, merge, and cache DNS-Record headers as specified, including dynamic TTL recomputation.
Section 3.2.3 describes this server behavior, but no implementation or prototype is presented.
domain assumption User agents implement the Figure 2 validation strategy and the recommended context restrictions.
Section 3.2.2 presents these as behaviors and recommendations; the security case analysis in Section 5.1 depends on them.
domain assumption The fallback DNS mechanism remains trustworthy for the security argument.
Section 5.1 states: 'This approach prevents attacks derived from case 1 or 3, if the fallback DNS mechanism still provides trustworthy DNS records.'
domain assumption The average website involves about 20 connections to different hostnames.
Section 4.2 adopts this workload from the author's own prior work [24]; it sizes the server-side cache and lookup-frequency estimate.
domain assumption TLS server authentication is an adequate stand-in for DNS record authenticity.
Sections 3.2.2 and 5.1 base the validation strategy on the server authenticating its identity rather than on validating the record itself.

invented entities (2)

DNS-Record HTTP response header field
purpose: Carries A/AAAA records with TTLs from web server to client so the client can skip the recursive-resolver lookup for subsequent connections.
Section 3.2.1 defines the header and its key-value pairs; no implementation, deployment, or interoperability validation exists in the paper.
Trusted-publisher whitelist (example: Google and Cloudflare)
purpose: Allows clients to skip fallback validation for whitelisted servers, preserving the privacy gain.
Sections 3.2.2 and 5.2 sketch a whitelist keyed to certificate-authority identity; the mechanism is a recommendation with no specification or evaluation.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Enhanced Performance and Privacy via Resolver-Less DNS." pith.science (2026). https://pith.science/paper/QFYUMMEU

@misc{pith2026190804574,
  author       = {Pith},
  title        = {Pith review of: Enhanced Performance and Privacy via Resolver-Less DNS},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QFYUMMEU}},
  note         = {Machine review of arXiv:1908.04574}
}

read the original abstract

The domain name resolution into IP addresses can significantly delay connection establishments on the web. Moreover, the common use of recursive DNS resolvers presents a privacy risk as they can closely monitor the user's browsing activities. In this paper, we present a novel HTTP response header allowing web server to provide their clients with relevant DNS records. Our results indicate, that this resolver-less DNS mechanism allows user agents to save the DNS lookup time for subsequent connection establishments. We find, that this proposal saves at least 80ms per DNS lookup for the one percent of users having the longest round-trip times towards their recursive resolver. Furthermore, our proposal decreases the number of DNS lookups and thus improves the privacy posture of the user towards the used recursive resolver. Comparing the security guarantees of the traditional DNS to our proposal, we find that resolver-less DNS achieves at least the same security properties. In detail, it even improves the user's resilience against censorship through tampered DNS resolvers.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

12 extracted references · 10 canonical work pages

[3]

8 Dominik Herrmann, Christian Banse, and Hannes Federrath

https://www.w3.org/TR/2019/WD-resource-hints-20190307/. 8 Dominik Herrmann, Christian Banse, and Hannes Federrath. Behavior-based tracking: Ex- ploiting characteristic patterns in DNS traﬃc.Computers & Security , 39:17–33,

work page 2019
[7]

21 Paul Schmitt, Anne Edmundson, Allison Mankin, and Nick Feamster

URL:https://atlas.ripe.net/. 21 Paul Schmitt, Anne Edmundson, Allison Mankin, and Nick Feamster. Oblivious DNS: practical privacy for DNS queries.Proceedings on Privacy Enhancing Technologies, 2019(2):228–244,

work page 2019
[10]

Enhanced Performance for the encrypted Web through TLS Resumption across Hostnames

URL: http://arxiv.org/abs/1902.02531, arXiv:1902.02531. 25 Erik Sy, Tobias Mueller, Moritz Moennich, and Hannes Federrath. Accelerating QUIC’s Connection Establishment on High-Latency Access Networks. arXiv e-prints , Jul

work page Pith review arXiv 1902
[12]

Accelerating QUIC's Connection Establishment on High-Latency Access Networks

URL: http://arxiv.org/abs/1907.01291, arXiv:1907.01291. 27 Matteo Varvello, Jeremy Blackburn, David Naylor, and Konstantina Papagiannaki. EYEORG: A Platform For Crowdsourcing Web Quality Of Experience Measurements. CoNEXT ’16, pages 399–412, New York, NY, USA,

work page Pith review arXiv 1907
[13]

ACM.doi:10.1145/2999572.2999590

work page arXiv
[2006]

17 Mark Nottingham

URL: https://rfc-editor.org/rfc/rfc4786.txt, doi:10.17487/RFC4786. 17 Mark Nottingham. Web Linking. RFC 8288, October

work page doi:10.17487/rfc4786
[2009]

23 Erik Sy, Christian Burkert, Hannes Federrath, and Mathias Fischer

URL:http://radar.oreilly.com/2009/ 07/velocity-making-your-site-fast.html/. 23 Erik Sy, Christian Burkert, Hannes Federrath, and Mathias Fischer. Tracking Users Across the Web via TLS Session Resumption. InProceedings of the 34th Annual Computer Security Applications Conference, ACSAC ’18, pages 289–299, New York, NY, USA,

work page 2009
[2013]

Comparing the Effects of DNS, DoT, and DoH on Web Performance

9 Austin Hounsel, Kevin Borgolte, Paul Schmitt, Jordan Holland, and Nick Feamster. Ana- lyzing the costs (and beneﬁts) of DNS, DoT, and DoH for the modern web.arXiv preprint arXiv:1907.08089,

work page Pith review arXiv 1907

Show all 12 references

[2016]

txt, doi:10.17487/RFC7871

URL:https://rfc-editor.org/rfc/rfc7871. txt, doi:10.17487/RFC7871. 6 Hannes Federrath, Karl-Peter Fuchs, Dominik Herrmann, and Christopher Piosecny. Privacy- preserving DNS: analysis of broadcast, range queries and mix-based protection methods. In European Symposium on Researc...

doi
[2017]

18 Jianping Pan, Y Thomas Hou, and Bo Li

URL:https://rfc-editor.org/ rfc/rfc8288.txt, doi:10.17487/RFC8288. 18 Jianping Pan, Y Thomas Hou, and Bo Li. An overview of DNS-based server selections in content distribution networks.Computer Networks, 43(6):695–711,

doi
[2018]

URL: http://doi.acm.org/10.1145/3274694.3274708, doi:10.1145/3274694.3274708

ACM. URL: http://doi.acm.org/10.1145/3274694.3274708, doi:10.1145/3274694.3274708. 24 Erik Sy, Moritz Moennich, Tobias Mueller, Hannes Federrath, and Mathias Fischer. Enhanced Performance for the encrypted Web through TLS Resumption across Hostnames.CoRR, abs/1902.02531,
[2019]

wiley.com/doi/pdf/10.1002/poi3.195, doi:10.1002/poi3.195

URL: https: //onlinelibrary.wiley.com/doi/abs/10.1002/poi3.195, arXiv:https://onlinelibrary. wiley.com/doi/pdf/10.1002/poi3.195, doi:10.1002/poi3.195. 3 Thomas Callahan, Mark Allman, and Michael Rabinovich. On modern DNS behavior and properties. ACM SIGCOMM Computer Communicat...

doi

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [3]

8 Dominik Herrmann, Christian Banse, and Hannes Federrath

https://www.w3.org/TR/2019/WD-resource-hints-20190307/. 8 Dominik Herrmann, Christian Banse, and Hannes Federrath. Behavior-based tracking: Ex- ploiting characteristic patterns in DNS traﬃc.Computers & Security , 39:17–33,

work page 2019

[2] [7]

21 Paul Schmitt, Anne Edmundson, Allison Mankin, and Nick Feamster

URL:https://atlas.ripe.net/. 21 Paul Schmitt, Anne Edmundson, Allison Mankin, and Nick Feamster. Oblivious DNS: practical privacy for DNS queries.Proceedings on Privacy Enhancing Technologies, 2019(2):228–244,

work page 2019

[3] [10]

Enhanced Performance for the encrypted Web through TLS Resumption across Hostnames

URL: http://arxiv.org/abs/1902.02531, arXiv:1902.02531. 25 Erik Sy, Tobias Mueller, Moritz Moennich, and Hannes Federrath. Accelerating QUIC’s Connection Establishment on High-Latency Access Networks. arXiv e-prints , Jul

work page Pith review arXiv 1902

[4] [12]

Accelerating QUIC's Connection Establishment on High-Latency Access Networks

URL: http://arxiv.org/abs/1907.01291, arXiv:1907.01291. 27 Matteo Varvello, Jeremy Blackburn, David Naylor, and Konstantina Papagiannaki. EYEORG: A Platform For Crowdsourcing Web Quality Of Experience Measurements. CoNEXT ’16, pages 399–412, New York, NY, USA,

work page Pith review arXiv 1907

[5] [13]

ACM.doi:10.1145/2999572.2999590

work page arXiv

[6] [2006]

17 Mark Nottingham

URL: https://rfc-editor.org/rfc/rfc4786.txt, doi:10.17487/RFC4786. 17 Mark Nottingham. Web Linking. RFC 8288, October

work page doi:10.17487/rfc4786

[7] [2009]

23 Erik Sy, Christian Burkert, Hannes Federrath, and Mathias Fischer

URL:http://radar.oreilly.com/2009/ 07/velocity-making-your-site-fast.html/. 23 Erik Sy, Christian Burkert, Hannes Federrath, and Mathias Fischer. Tracking Users Across the Web via TLS Session Resumption. InProceedings of the 34th Annual Computer Security Applications Conference, ACSAC ’18, pages 289–299, New York, NY, USA,

work page 2009

[8] [2013]

Comparing the Effects of DNS, DoT, and DoH on Web Performance

9 Austin Hounsel, Kevin Borgolte, Paul Schmitt, Jordan Holland, and Nick Feamster. Ana- lyzing the costs (and beneﬁts) of DNS, DoT, and DoH for the modern web.arXiv preprint arXiv:1907.08089,

work page Pith review arXiv 1907