Pith. sign in

REVIEW 2 major objections 7 minor 128 references

Collusion Resistant DNS With Private Information Retrieval

T0 review · 2 major / 7 minor · reviewed 2026-08-06 · deepseek-v4-flash

Pith's one-line read PDNS lets DNS resolvers answer queries without learning the domain.

desk verdict A genuine PIR-based DNS prototype that solves cache population, but the privacy parity with DoHoT is overstated and the collapse of the ANS premise makes 'collusion resistant' conditional, not absolute. read the letter →

arxiv 2507.20806 v1 pith:TKZKP2XS submitted 2025-07-28 cs.NI cs.CR

classification cs.NIcs.CR
keywords DNSprivacyPrivateInformationRetrievalcollusionresistanceObliviousDoHrecursiveresolverhomomorphicencryptionEDNScaching
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

The paper tries to establish that DNS privacy can be made collusion-resistant without removing recursive resolvers, by having resolvers answer queries blindly through single-server Private Information Retrieval. The proposed PDNS lets a recursive resolver compute PIR answers over its cache so it never learns which domain was queried, removing the non-collusion assumption that ODoH needs between proxy and resolver. To keep caches populated, a client that hits a cache miss performs the iterative lookup itself, and the final authoritative name server privately refills the resolver's cache via a new EDNS extension. The price is that a user's IP and domain are visible to the final authoritative server on cache misses, which the paper argues is acceptable because those servers already see the user's subsequent traffic and because caching limits misses to a small fraction of queries. If the argument holds, PDNS gives users today a practical, financially viable alternative to Tor-based DNS that is about twice as fast.

What carries the argument

The load-bearing mechanism is single-server stateless PIR, specifically the Spiral scheme, which lets a user fetch one slot of a pre-encoded database without revealing the index. PDNS wraps Spiral in a DNS workflow: a public hash maps each domain to one of $2^{15}$ slots of 16 KB in a 512 MB cache, the resolver encodes the whole cache once, and each query is answered homomorphically. On a cache miss, a new EDNS(0) option called EDNS-PR carries the resolver's IP address to the final authoritative name server, which then refills the resolver's cache with a randomly delayed response to blunt timing correlation. DNS records are reshaped for the scheme by replacing the domain name with a 16-byte hash and the TTL with an expiration timestamp, so expired entries can be resolved in a single direct hop to the authoritative server.

What would settle it

Inspect real PDNS cache-miss traces and check whether, for each miss, the authoritative server for the domain would independently observe HTTP(S) traffic from the same user IP to that domain within the record's TTL; if a large fraction of misses are never followed by such traffic, PDNS's parity-with-Tor privacy argument collapses.

Watch

Extended reading notes

Core claim

PDNS claims that a recursive resolver can resolve DNS queries while staying blind to the queried domain, using single-server stateless PIR (Spiral) over a fixed-size hash-table cache. On a cache hit, the user hashes the domain to an index, encrypts it, and the resolver homomorphically returns the whole matching slot, so the resolver learns neither the index nor the slot content. On a cache miss, the client performs the iterative lookup itself and the final authoritative name server sends the fresh record back to the resolver through an EDNS-PR extension, populating the cache without exposing the client's IP to the resolver. The paper argues this shifts privacy exposure from one central resolver (or resolver-proxy pair) to many authoritative servers, that this exposure is acceptable, and that caching keeps it small. In trace-driven experiments PDNS achieves median query times of 208 ms with a 64 MB cache, faster than ODoH's 272 ms and about twice as fast as DNS over Tor, at the cost of a resolver throughput of only 4-8 queries per second on an 8-core server.

Load-bearing premise

The paper assumes that when a user's query misses the resolver's cache, the final authoritative name server learning the user's IP and queried domain is not a new privacy loss because that server already sees the user's subsequent traffic to the domain.

Editorial extensions

If this is right

  • PDNS removes the need to trust a proxy not to collude with a resolver, the assumption that limits ODoH.
  • PDNS is about twice as fast as DoH over Tor with comparable privacy guarantees, and with a small cache it is faster than ODoH (208 ms versus 272 ms median).
  • Only cache misses expose queries to authoritative servers; in the paper's traces fewer than 10% of queries miss, and 90% of misses come from expired records that can be resolved directly at the final authoritative server.
  • With foreseen PIR hardware accelerators, answer time drops to a few milliseconds, making PDNS competitive with plain DoH while retaining collusion resistance.

Reading between the lines

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

  • If the claim that final authoritative servers already see users' subsequent traffic fails for a large fraction of real users, PDNS's privacy guarantee would reduce to 'resolver learns nothing, final ANS learns query and IP on misses,' which is still stronger than DoH but not equivalent to Tor.
  • The cache-refill mechanism generalizes to other hierarchical systems with shared caches, such as certificate transparency logs or blockchain light clients, wherever a cache must be populated without revealing who asked for what.
  • A direct test of the paper's scalability projection would be to run Spiral's Answer primitive on an FHE accelerator and measure whether query resolution actually falls to the assumed few milliseconds on multi-GB caches.
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.

Referee Report

2 major / 7 minor

Summary. PDNS is a DNS privacy extension that integrates single-server PIR (Spiral) into the recursive resolver (ReR). A user hashes the queried domain to a cache slot, encrypts the slot index, and the ReR evaluates the PIR answer over an encoded cache without learning the domain; to populate the cache after a miss, the user performs the iterative lookup directly and the final authoritative name server (ANS) forwards the record to the ReR via the paper's EDNS-PR extension, with randomized delay to hinder timing correlation. The paper claims that PDNS removes the proxy non-collusion assumption that limits ODoH, achieves median query latencies of 208 ms (64 MB cache) versus 272 ms for ODoH, and is about 2x faster than DoH over Tor, with privacy guarantees 'similar' to DoHoT, at the cost of scalability (4-8 QPS per ReR). The contributions include a working prototype (Rust Spiral client/ReR, ~200-line BIND9 patch), trace-driven evaluation over 1,415 residential VPN nodes and 122K domains, a cache-miss proof mechanism to defend reflection attacks, and a deployment cost model.

Significance. If taken at face value, the ReR-blind query path is a meaningful advance: it removes the trusted proxy from the query path entirely, and the PIR construction rests on the published LWE-based security of Spiral rather than on fitted parameters; the cache shape, PIR choice, and throughput numbers are measured engineering decisions, and the paper reports the 4-8 QPS bottleneck and its cost model transparently. The paper also deserves credit for shipping an open-source prototype and for honestly disclosing its limitations (anycast, scalability, third-party final ANSes). The significance is nevertheless conditional: the headline parity with DoHoT and the 'Survive Non-Collusion Violation: Yes' entry in Table 1 hold only if exposing (user IP, full domain) to final ANSes on cache misses is privacy-neutral, a premise that Section 3.1 hedges with 'likely' and Section 9 partially retracts for Route 53-class deployments. As a system that distributes DNS exposure across many ANSes rather than concentrating it at one resolver, PDNS is a credible and useful contribution; as a no-trust-assumptions protocol it is not yet demonstrated.

major comments (2)
  1. [§3.1, §7.1, Table 1, abstract; §9 'Third-Party Final ANSes'] The load-bearing premise of the paper's central claim is stated in Section 3.1: a cache-miss query that reveals the full domain and the user IP to the final ANS 'does not leak any extra private information about a user than what the subsequent traffic directed to the domain' reveals, because 'ANSes are likely already gaining information about users from users' subsequent traffic [73].' This premise converts the design's inherent exposure of (IP, domain) to final ANSes into the abstract's 'similar privacy guarantees' to DoHoT and into the 'Survive Non-Collusion Violation: Yes' entry for single-server PIR in Table 1, and it is not established. First, the paper provides no evidence that the final ANS that serves a user's cache-miss query also observes that user's subsequent HTTP(S) traffic, and the claim is contradicted by the paper's own Section 9, which admits that for third-party ANS services such as Route 53, PDNS 'would leak some information to a third party which does not already have access to this information via direct traffic,' with the fix deferred to future work. Second, even if the ANS already knew the query, that does not make it known to the ReR: a single colluding ANS can transmit the (domain, user IP) pair to the ReR over the cache-population path (or simply omit the randomized delay), giving the ReR exactly the link the PIR query was designed to hide. The Section 3.1 restriction to 'realistic collusion... not among millions of ANSes' does not bound this threat, because one colluding ANS, or one multi-service operator such as Google or Cloudflare (discussed in Section 9), suffices. DoHoT, with which the paper claims parity, hides the user IP from the resolver entirely; PDNS does not. The abstract, Table 1, and Section 7.1 therefore overstate the guarantee: either the claims must be scoped to non-collusion between the ReR and the final ANS (which makes PDNS a different trade-off than advertised), or the PIR-at-the-ANS mechanism of Section 9 must be moved into the design rather than left as future work.
  2. [§4.2, §7.2, Appendix G] The timing-attack defense is load-bearing for the cache-miss path, because the ReR learns the domain when the ANS populates the cache, and the randomized delay is the only mechanism preventing the ReR from correlating that event with the user IP and query time it already observes. The Appendix G analysis supports a weaker conclusion than the Section 7.2 claim that PDNS 'effectively thwarts' timing attacks. For the uniform delay U(0, 2Δ) proposed in Section 4.2, Equation (2) yields entropy exactly at the threshold Te ≈ 0.69 nats, i.e., two equiprobable candidate queries, so the ReR can attribute a given population event to the correct user with 50% probability per miss. Over the paper's measured ~10% miss rate, with the ReR knowing the source IP and exact time of every PIR query, a 50%-accurate per-event signal is a substantial accumulation of user-to-query links rather than a thwarted attack. The model also assumes equally spaced queries made by different users (Figure 9), which is violated by the bursty traffic documented in Appendix F; under bursts, Δ shrinks and the candidate set for U(0, 2Δ) shrinks with it. The authors should report the per-event correlation success probability rather than a threshold-satisfying entropy, justify choosing the geometric distribution from Figure 10 for the actual design, and analyze the bursty regime.
minor comments (7)
  1. [§7.1] The sentence 'PDNS is slightly faster than DoH and ReR-Less DoH assuming a small cache, and no connection reuse' cannot be right as written, since PDNS is 208 ms and DoH is 69 ms; 'ODoH' was presumably the intended comparison, as ODoH is 272 ms without reuse.
  2. [Abstract, intro, §7.1] The '2x faster than DoH over Tor' claim should state which cache configuration it refers to: the introduction says the factor holds 'even on a large cache (512MB)', while Section 7.1 gives 208 ms (small cache) and 450 ms (large cache) and never reports the DoHoT median used for comparison; the two sections should be reconciled and the DoHoT baseline number reported.
  3. [Figure 2 caption, §6.2] The exponent notation is lost in '216 slots' (Figure 2 caption) and '215 slots with a size of 16KB' (Section 6.2); these should read 2^16 and 2^15, and the same check should be applied to '210', '220', and similar values elsewhere in Section 6.2.
  4. [References [1], [8]] Reference [8], labeled 'Google Cloud Pricing Calculator', points to the same AWS calculator URL as reference [1]; the Google Cloud link appears to be a copy-paste error and should be corrected.
  5. [Appendix G] The threshold Te ≈ 0.69 is evaluated with natural logarithms, but the base is never stated; because the numerical value of the entropy depends on the base, the analysis should state the base or report entropy in bits.
  6. [§7.2, Figure 4(c)] The 'preserving regional access pattern' analysis treats large absolute domain-popularity rank differences between PDNS and ground truth as a privacy benefit; rank perturbation is an observation about how the PIR slot-return distribution reshapes cache-visible statistics, not a demonstrated privacy guarantee, and the framing should be softened or argued more carefully.
  7. [Appendix E.1, §7.1] The DoHoT durations are collected from a single laboratory location, while PDNS numbers are obtained by injecting 1,415-node Mysterium latencies; the paper discloses this asymmetry, but the headline 2x comparison would be considerably more robust if both protocols were measured over the same client population.

Circularity Check

1 steps flagged · score 4.0 of 10

The 'Survive Non-Collusion Violation' property is self-definitional: §3.3 declares the final-ANS-to-ReR information transfer 'not a case of collusion,' so the Table 1 'Yes' holds by stipulation rather than by the PIR construction.

  1. self definitional [§3.3 Workflow, Cache update; see also §2.3 and Table 1]
    "As long as the final ANS does not “collude” with the ReR, the user’s privacy is maintained. This is not a violation of our privacy model as final ANSes have access to the user queries anyway (§ 3.1); instead, rather than being a case of collusion, it is merely a unidirectional information transfer from the final ANS to the ReR."

    The paper's headline property, 'Survive Non-Collusion Violation: Yes' (Table 1), is evaluated against a threat model in which only ReR–proxy collusion counts as collusion. In PDNS, every cache miss sends the user's IP and full query directly to the final ANS, and that ANS then forwards the response to the ReR. If the final ANS and ReR collude, or are the same operator (as the paper acknowledges for Google/Cloudflare in §9), the ReR learns the exact user–query link. The paper pre-empts this by stipulating that the transfer is 'not a case of collusion' because ANSes already have the query from subsequent traffic. The property is therefore satisfied by definition, not by the PIR construction.

full rationale

No other circular steps were found. The ReR's blindness rests on Spiral's published single-server PIR and standard LWE assumptions, not on any quantity fitted in this paper. Performance claims (208 ms and 450 ms median query times, 2x faster than DoHoT, QPS limits) come from the implemented prototype plus measured trace latencies; the F1-based 5 ms 'hardware accelerator' point is explicitly a simulation assumption, not a fitted parameter. The cache shape (2^15 slots of 16 KB) is selected from the benchmarks, and the timing-attack entropy analysis uses an explicit model with a stated threshold T_e. Self-citations ([121]–[123]) support methodology and prior systems, not the central privacy claim. The one definitional circularity is the collusion-resistance label discussed above: the paper makes 'collusion' exclude the final ANS, which is the very actor whose collusion with the ReR would defeat the claimed guarantee. That is a partial circularity in a central claim, while the rest of the derivation is self-contained and benchmarked against external baselines.

Assumptions & free parameters 4 free parameters · 6 assumptions · 0 invented entities

The central design rests on standard cryptographic assumptions (LWE) plus several domain assumptions: that ANSes already see equivalent user traffic, that ANS collusion is out of scope, that a minimum user population exists, and that ANSes will adopt DoH and EDNS-PR. The paper's free parameters are engineering choices made from its own benchmarks, not fitted constants disguised as predictions.

free parameters (4)
  • PDNS cache shape: N=2^15 slots, S=16KB = 2^15 slots x 16KB = 512MB
    Chosen in Section 6.2 to minimize measured Answer latency on a 512MB cache; affects all reported PDNS query times.
  • F1 hardware Answer time assumption = 5ms
    Assumed future FHE accelerator performance in Section 7.1; used to project 70ms PDNS query times.
  • Timing-attack delay distribution = U(0,2Δ) or G(1/Δ) with E[X]=Δ
    Assumed delay sampling in Section 4.2 and Appendix G; the defense effectiveness depends on this distribution choice.
  • Entropy threshold Te = 0.69
    Chosen in Appendix G as the equal-likelihood two-query bound; the defense's effectiveness conclusion depends on this threshold.
assumptions (6)
  • standard math LWE hardness and Spiral's FHE security hold.
    Spiral PIR security rests on standard lattice assumptions (Section 2.2, Appendix B).
  • domain assumption Final ANSes already see equivalent user information from subsequent traffic.
    Used in Sections 2.3 and 3.1 to justify the privacy trade-off of exposing cache-miss queries to ANSes.
  • domain assumption Malicious ANSes and ReR-ANS collusion are out of scope.
    Section 3.1 restricts collusion to a limited number of parties, such as a few ReRs and proxies, and treats ANSes as non-critical; this limits the collusion-resistance claim.
  • domain assumption At least a few PDNS users are active simultaneously.
    Section 2.3 states a single active user with a cache miss is identifiable via timing; privacy relies on user population.
  • domain assumption Participating ANSes will adopt DoH and EDNS-PR.
    Section 4.3 acknowledges no popular ANS supports DoT/DoH today; the design depends on this adoption.
  • domain assumption DNS query name minimization is used at non-final ANSes.
    Section 3.1 privacy analysis for non-final ANSes assumes QNAME minimization.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Collusion Resistant DNS With Private Information Retrieval." pith.science (2026). https://pith.science/paper/TKZKP2XS

@misc{pith2026250720806,
  author       = {Pith},
  title        = {Pith review of: Collusion Resistant DNS With Private Information Retrieval},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TKZKP2XS}},
  note         = {Machine review of arXiv:2507.20806}
}
read the original abstract

There has been a growing interest in Internet user privacy, demonstrated by the popularity of privacy-preserving products such as Telegram and Brave, and the widespread adoption of HTTPS. The Domain Name System (DNS) is a key component of Internet-based communication and its privacy has been neglected for years. Recently, DNS over HTTPS (DoH) has improved the situation by fixing the issue of in-path middleboxes. Further progress has been made with proxy-based solutions such as Oblivious DoH (ODoH), which separate a user's identity from their DNS queries. However, these solutions rely on non-collusion assumptions between DNS resolvers and proxies -- an assumption difficult to guarantee in practice. To address this, we explore integrating single-server Private Information Retrieval (PIR) into DNS to enable encrypted query processing without relying on trust assumptions. However, applying PIR to DNS is challenging due to its hierarchical nature -- particularly, interactions with recursive resolvers can still leak information. Navigating performance and privacy trade-offs, we propose PDNS, a DNS extension leveraging single-server PIR to strengthen privacy guarantees. We have implemented a prototype of PDNS and compared its performance against state-of-the-art solutions via trace-driven experiments. The results show that PDNS achieves acceptable performance (2x faster than DoH over Tor with similar privacy guarantees) and strong privacy guarantees today, mainly at the cost of its scalability, which specialized hardware for PIR can address in the near future.

Figures

Figures reproduced from arXiv: 2507.20806 by the authors.

Figure 1
Figure 1. Visualization of PDNS and its workflow. stateless PIR schemes. Assuming that the database size 𝑁 is known to both user and server. [C] is denoted as an encoding of C and is initially filled with zeros. The way a server encodes the database is specific to the PIR scheme. Define the following primitives for the user setup and database construction. • SetupUser(𝑁) → (qk, pk): Given as input the database size, the user … view at source ↗
Figure 2
Figure 2. PDNS cache as a hash table with 2 16 slots. valid. DNS records stored at the ReR also contain a timestamp of when the record was resolved. Each time a DNS query is matched in the cache, the ReR checks whether this record is expired. To allow the client to perform this operation, we replace the TTL field with a timestamp indicating when the record expires, i.e., timestamp at insertion plus TTL, as illustrated in [PI… view at source ↗
Figure 3
Figure 3. Benchmarking results for PDNS. Network latency is negligible. [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Evaluation of PDNS. contrast, our security mechanism reduces significantly and puts a deterministic cap on the reflection traffic. Given the space con￾straints, we leave the full result analysis in Appendix E.3. Preserving regional access pattern – In addition to the c…
Figure 5
Figure 5. Figure 5: ANS CPU usage as a function of the query rate. [PITH_FULL_IMAGE:figures/full_fig_p016_5.png]
Figure 6
Figure 6. Figure 6: Additional benchmarking results. (a) Initialization duration, (b) communication cost during initialization, and (c) [PITH_FULL_IMAGE:figures/full_fig_p017_6.png]
Figure 7
Figure 7. Figure 7: Memory and CPU as a function of cache size. [PITH_FULL_IMAGE:figures/full_fig_p017_7.png]
Figure 8
Figure 8. Figure 8: Analysis of active DNS measurements. guarantees cache hits as long as our queries happen within such an interval. The one-second interval guarantees a cache miss as long as we perform queries slower than once a second. While many public ReRs would ignore such low TTL v…
Figure 9
Figure 9. Figure 9: Illustration of the modeling for delayed response [PITH_FULL_IMAGE:figures/full_fig_p019_9.png]
Figure 10
Figure 10. Figure 10: The effectiveness of delayed response forwarding to PDNS ReR. [PITH_FULL_IMAGE:figures/full_fig_p020_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

128 extracted references · 77 canonical work pages

  1. [73]

    Hounsel, K

    A. Hounsel, K. Borgolte, P. Schmitt, and N. Feamster. D-DNS: towards re- decentralizing the DNS. CoRR, abs/2002.09055, 2020

  2. [1]

    https://calculator.aws/#/addService/ec2- enhancement

    Add Service - AWS Pricing Calculator. https://calculator.aws/#/addService/ec2- enhancement. Accessed in 2024

  3. [2]

    https://aws.amazon.com/route53/

    Aws route 53. https://aws.amazon.com/route53/

  4. [3]

    https://www.isc.org/bind/

    Bind 9. https://www.isc.org/bind/

  5. [4]

    https://www.isc.org/blogs/bind-doh-update-2021/

    BIND DoH Update. https://www.isc.org/blogs/bind-doh-update-2021/

  6. [5]

    https://github.com/blyssprivacy/sdk

    Blyss (Previously Spiral-rs). https://github.com/blyssprivacy/sdk

  7. [6]

    https://linux.die.net/ma n/1/dig

    dig(1): DNS lookup utility - Linux man page - Die.net. https://linux.die.net/ma n/1/dig

  8. [7]

    https://www.dnscrypt.org/

    Dnscrypt. https://www.dnscrypt.org/

Show all 128 references
  1. [8]

    https://calculator.aws/#/addService/ec2- enhancement

    Google Cloud Pricing Calculator. https://calculator.aws/#/addService/ec2- enhancement. Accessed in 2024

  2. [9]

    https://download.01.org/intel-sgx/sgx-linux/2.10/docs/Intel_SGX_ Developer_Reference_Linux_2.10_Open_Source.pdf

    Intel ® Software Guard Extensions (Intel® SGX) SDK for Linux* OS Developer Reference. https://download.01.org/intel-sgx/sgx-linux/2.10/docs/Intel_SGX_ Developer_Reference_Linux_2.10_Open_Source.pdf. Accessed in 2024

  3. [10]

    https: //www.intel.com/content/www/us/en/develop/documentation/cpp-compiler- developer-guide-and-reference/top/compiler-reference/intrinsics/intrinsics- for-avx2.html

    Intrinsics for Intel ® Advanced Vector Extensions 2 (Intel ® AVX2). https: //www.intel.com/content/www/us/en/develop/documentation/cpp-compiler- developer-guide-and-reference/top/compiler-reference/intrinsics/intrinsics- for-avx2.html

  4. [11]

    https://man7.org/linux/man-pages/man8/tc.8.html

    Linux traffic control (tc). https://man7.org/linux/man-pages/man8/tc.8.html

  5. [12]

    https://mysterium.networ k/

    Mysterium network: Censorship free Internet for all. https://mysterium.networ k/

  6. [13]

    https: //images.nvidia.com/content/pdf/nvswitch-technical-overview.pdf

    NVIDIA NVSWITCH: The World’s Highest-Bandwidth On-Node Switch. https: //images.nvidia.com/content/pdf/nvswitch-technical-overview.pdf. Accessed in 2024

  7. [14]

    Sussmann, 2022 WL 1124755 (D.D.C

    USA v. Sussmann, 2022 WL 1124755 (D.D.C. 2022)

  8. [15]

    https://www.securityweek.com/tor- code-audit-finds-17-vulnerabilities/

    Tor Code Audit Finds 17 Vulnerabilities. https://www.securityweek.com/tor- code-audit-finds-17-vulnerabilities/. Accessed in 2024

  9. [16]

    https://tranco-list.eu/

    Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation. https://tranco-list.eu/

  10. [17]

    https://github.com/WPO-Foundation/webpagetest

    WebPageTest. https://github.com/WPO-Foundation/webpagetest

  11. [18]

    https://www.cloudflare.com/lea rning/dns/what-is-dns/

    What is DNS? | How DNS works | Cloudflare. https://www.cloudflare.com/lea rning/dns/what-is-dns/

  12. [19]

    https://bluecatnetworks.com/blog/when-to- replace-bind-dns/

    When to replace BIND DNS. https://bluecatnetworks.com/blog/when-to- replace-bind-dns/

  13. [20]

    RFC 1035, Nov

    Domain names - implementation and specification. RFC 1035, Nov. 1987

  14. [21]

    https://www.cloudflare.com/dns/

    Cloudflare DNS, 2022. https://www.cloudflare.com/dns/

  15. [22]

    https://support.mozilla.org/en-US/kb/firefox- dns-over-https

    Firefox DNS-over-HTTPS., 2022. https://support.mozilla.org/en-US/kb/firefox- dns-over-https

  16. [23]

    https://developers.google

    Google Public DNS: DNS over HTTPS (DoH), 2022. https://developers.google. com/speed/public-dns/docs/doh

  17. [24]

    https://developers.google.com/speed/ public-dns/docs/intro

    Introduction to Google Public DNS, 2022. https://developers.google.com/speed/ public-dns/docs/intro

  18. [25]

    https://www.chro mium.org/developers/dns-over-https/

    The chromium projects: DNS over HTTPS (aka DoH), 2022. https://www.chro mium.org/developers/dns-over-https/

  19. [26]

    https://www.theregister.com/2023/02/15/intel_sgx_vulns/

    Intel patches up SGX best it can after another load of security holes found, 2023. https://www.theregister.com/2023/02/15/intel_sgx_vulns/

  20. [27]

    Abley and K

    J. Abley and K. E. Lindqvist. Operation of anycast services. RFC, 4786:1–24, 2006

  21. [28]

    Aggarwal, E

    G. Aggarwal, E. Bursztein, C. Jackson, and D. Boneh. An analysis of private browsing modes in modern browsers. In 19th USENIX Security Symposium, Washington, DC, USA, August 11-13, 2010, Proceedings , pages 79–94. USENIX Association, 2010

  22. [29]

    A. Ali, T. Lepoint, S. Patel, M. Raykova, P. Schoppmann, K. Seth, and K. Yeo. {Communication–Computation} trade-offs in{PIR}. In 30th USENIX Security Symposium (USENIX Security 21) , pages 1811–1828, 2021

  23. [30]

    Anagnostopoulos, G

    M. Anagnostopoulos, G. Kambourakis, P. Kopanos, G. Louloudakis, and S. Gritza- lis. DNS amplification attack revisited. Comput. Secur., 39:475–485, 2013

  24. [31]

    Angel, H

    S. Angel, H. Chen, K. Laine, and S. Setty. Pir with compressed queries and amortized query processing. In 2018 IEEE symposium on security and privacy (SP), pages 962–979. IEEE, 2018

  25. [32]

    Arends, R

    R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS security intro- duction and requirements. RFC, 4033:1–21, 2005

  26. [33]

    Aumann and Y

    Y. Aumann and Y. Lindell. Security against covert adversaries: Efficient protocols for realistic adversaries. J. Cryptol., 23(2):281–343, 2010

  27. [34]

    Ballani and P

    H. Ballani and P. Francis. Mitigating DNS dos attacks. In Proceedings of the 2008 ACM Conference on Computer and Communications Security, CCS 2008, Alexandria, Virginia, USA, October 27-31, 2008 , pages 189–198. ACM, 2008

  28. [35]

    Bortzmeyer, R

    S. Bortzmeyer, R. Dolmans, and P. Hoffman. DNS query name minimisation to improve privacy. RFC, 9156:1–11, 2021

  29. [36]

    Böttger, F

    T. Böttger, F. Cuadrado, G. Antichi, E. L. Fernandes, G. Tyson, I. Castro, and S. Uhlig. An empirical study of the cost of dns-over-https. In Proceedings of the Internet Measurement Conference, pages 15–21, 2019

  30. [37]

    Brakerski, C

    Z. Brakerski, C. Gentry, and V. Vaikuntanathan. (leveled) fully homomorphic encryption without bootstrapping. In Proceedings of the 3rd Innovations in Theoretical Computer Science Conference, ITCS ’12, page 309–325, New York, NY, USA, 2012. ACM

  31. [38]

    Brakerski, C

    Z. Brakerski, C. Gentry, and V. Vaikuntanathan. (leveled) fully homomorphic encryption without bootstrapping. ACM Transactions on Computation Theory (TOCT), 6(3):1–36, 2014

  32. [39]

    Burton, S

    A. Burton, S. J. Menon, and D. J. Wu. Respire: High-rate pir for databases with small records. Cryptology ePrint Archive, 2024

  33. [40]

    Callahan, M

    T. Callahan, M. Allman, and M. Rabinovich. On modern DNS behavior and properties. Comput. Commun. Rev., 43(3):7–15, 2013

  34. [41]

    Callejo, M

    P. Callejo, M. Bagnulo, J. G. Ruiz, A. Lutu, A. García-Martínez, and R. Cuevas. Measuring doh with web ads. Comput. Networks, 2022

  35. [42]

    Cammarota

    R. Cammarota. Intel heracles: homomorphic encryption revolutionary accelera- tor with correctness for learning-oriented end-to-end solutions. In Proceedings of the 2022 on Cloud Computing Security Workshop , pages 3–3, 2022

  36. [43]

    Castillo Pérez

    S. Castillo Pérez. Contributions to privacy and anonymity on the Internet: domain name system and second-generation onion routing . 2017

  37. [44]

    Chhabra, P

    R. Chhabra, P. Murley, D. Kumar, M. Bailey, and G. Wang. Measuring dns-over- https performance around the world. In IMC ’21: ACM Internet Measurement Conference, Virtual Event, USA, November 2-4, 2021 . ACM, 2021

  38. [45]

    B. Chor, E. Kushilevitz, O. Goldreich, and M. Sudan. Private information retrieval. J. ACM, 45(6):965–981, 1998

  39. [46]

    Contavalli, W

    C. Contavalli, W. van der Gaast, D. C. Lawrence, and W. Kumari. Client subnet in DNS queries. RFC, 7871:1–30, 2016

  40. [47]

    Corrigan-Gibbs, A

    H. Corrigan-Gibbs, A. Henzinger, and D. Kogan. Single-server private infor- mation retrieval with sublinear amortized time. Cryptology ePrint Archive , 2022

  41. [48]

    Corrigan-Gibbs and D

    H. Corrigan-Gibbs and D. Kogan. Private information retrieval with sublinear online time. In Advances in Cryptology – EUROCRYPT 2020 , pages 44–75, Cham,

  42. [49]

    Csikor, H

    L. Csikor, H. Singh, M. S. Kang, and D. M. Divakaran. Privacy of dns-over-https: Requiem for a dream? In 2021 IEEE European Symposium on Security and Privacy (EuroS&P), pages 252–271. IEEE, 2021

  43. [50]

    Damas, M

    J. Damas, M. Graff, and P. Vixie. Extension mechanisms for DNS (EDNS(0)). RFC, 6891:1–16, 2013

  44. [51]

    Dauterman and H

    E. Dauterman and H. Corrigan-Gibbs. Lightweb: Private web browsing without all the baggage. In Proceedings of the 22nd ACM Workshop on Hot Topics in Networks, HotNets 2023, Cambridge, MA, USA, November 28-29, 2023 , pages 287–294. ACM, 2023

  45. [52]

    Davidson, G

    A. Davidson, G. Pestana, and S. Celi. Frodopir: Simple, scalable, single-server private information retrieval. Proceedings on Privacy Enhancing Technologies , 2023

  46. [53]

    W. B. de Vries, Q. Scheitle, M. Müller, W. Toorop, R. Dolmans, and R. van Rijswijk- Deij. A first look at QNAME minimization in the domain name system. In D. R. Choffnes and M. P. Barcellos, editors, Passive and Active Measurement - 20th International Conference, PAM 2019, Pue...

  47. [54]

    Di Bella, C

    G. Di Bella, C. Barcellona, and I. Tinnirello. A secret sharing scheme for anony- mous dns queries. In AEIT Annual Conference 2013 , pages 1–5. IEEE, 2013

  48. [55]

    Dickinson, S

    J. Dickinson, S. Dickinson, R. Bellis, A. Mankin, and D. Wessels. DNS Transport over TCP - Implementation Requirements. RFC 7766, Mar. 2016

  49. [56]

    Dingledine, N

    R. Dingledine, N. Mathewson, and P. Syverson. Tor: The second-generation onion router. Technical report, Naval Research Lab Washington DC, 2004

  50. [57]

    H. Duan, R. Fischer, J. Lou, S. Liu, D. A. Basin, and A. Perrig. RHINE: robust and high-performance internet naming with E2E authenticity. In 20th USENIX Symposium on Networked Systems Design and Implementation, NSDI 2023, Boston, MA, April 17-19, 2023, pages 531–553. USENIX A...

  51. [58]

    Fan and F

    J. Fan and F. Vercauteren. Somewhat practical fully homomorphic encryption. IACR Cryptology ePrint Archive, 2012

  52. [59]

    Fan and F

    J. Fan and F. Vercauteren. Somewhat practical fully homomorphic encryption. Cryptology ePrint Archive, Paper 2012/144, 2012. https://eprint.iacr.org/2012/1 44

  53. [60]

    Fujiwara, A

    K. Fujiwara, A. Sato, and K. Yoshida. Cache effect of shared DNS resolver. IEICE Trans. Commun., 102-B(6):1170–1179, 2019

  54. [61]

    Geelen, M

    R. Geelen, M. Van Beirendonck, H. V. Lima Pereira, B. Huffman, T. McAuley, B. Selfridge, D. Wagner, G. Dimou, I. Verbauwhede, F. Vercauteren, et al. Basalisc: programmable hardware accelerator for bgv fully homomorphic en- cryption. IACR Transactions on Cryptographic Hardware ...

  55. [62]

    C. Gentry. A Fully Homomorphic Encryption Scheme . PhD thesis, Stanford, CA, USA, 2009. AAI3382729

  56. [63]

    Gentry, A

    C. Gentry, A. Sahai, and B. Waters. Homomorphic encryption from learning with errors: Conceptually-simpler, asymptotically-faster, attribute-based. In Advances in Cryptology – CRYPTO 2013 , pages 75–92, Berlin, Heidelberg, 2013. Springer Berlin Heidelberg

  57. [64]

    Guha and P

    S. Guha and P. Francis. Identity trail: Covert surveillance using DNS. In Privacy Enhancing Technologies, 7th International Symposium, PET 2007 Ottawa, Canada, June 20-22, 2007, Revised Selected Papers , volume 4776 of Lecture Notes in Computer Science, pages 153–166. Springer...

  58. [65]

    Habib, J

    H. Habib, J. Colnago, V. Gopalakrishnan, S. Pearman, J. Thomas, A. Acquisti, N. Christin, and L. F. Cranor. Away from prying eyes: Analyzing usage and understanding of private browsing. In M. E. Zurko and H. R. Lipford, editors, Fourteenth Symposium on Usable Privacy and Secur...

  59. [66]

    K. M. Henderson, T. April, and J. Livingood. Authoritative DNS-over-TLS Opera- tional Considerations. Internet-Draft draft-hal-adot-operational-considerations- 02, Internet Engineering Task Force, Aug. 2019. Work in Progress

  60. [67]

    Henzinger, E

    A. Henzinger, E. Dauterman, H. Corrigan-Gibbs, and N. Zeldovich. Private web search with tiptoe. In J. Flinn, M. I. Seltzer, P. Druschel, A. Kaufmann, and J. Mace, editors, Proceedings of the 29th Symposium on Operating Systems Principles, SOSP 2023, Koblenz, Germany, October ...

  61. [68]

    Henzinger, M

    A. Henzinger, M. M. Hong, H. Corrigan-Gibbs, S. Meiklejohn, and V. Vaikun- tanathan. One server for the price of two: Simple and fast single-server pri- vate information retrieval. Cryptology ePrint Archive, Paper 2022/949, 2022. https://eprint.iacr.org/2022/949

  62. [69]

    Herrmann, K.-P

    D. Herrmann, K.-P. Fuchs, J. Lindemann, and H. Federrath. Encdns: A lightweight privacy-preserving name resolution service. InEuropean Symposium on Research in Computer Security, pages 37–55. Springer, 2014

  63. [70]

    N. P. Hoang, I. Lin, S. Ghavamnia, and M. Polychronakis. K-resolver: Towards decentralizing encrypted DNS resolution. CoRR, abs/2001.08901, 2020

  64. [71]

    P. E. Hoffman and P. McManus. DNS Queries over HTTPS (DoH). RFC 8484, Oct. 2018

  65. [72]

    P. E. Hoffman and P. van Dijk. Recursive to Authoritative DNS with Unau- thenticated Encryption. Internet-Draft draft-ietf-dprive-opportunistic-adotq-02, Internet Engineering Task Force, Apr. 2021. Work in Progress

  66. [74]

    Hounsel, P

    A. Hounsel, P. Schmitt, K. Borgolte, and N. Feamster. Encryption without centralization: distributing dns queries across recursive resolvers. InProceedings of the Applied Networking Research Workshop, pages 62–68, 2021

  67. [75]

    Z. Hu, L. Zhu, J. Heidemann, A. Mankin, D. Wessels, and P. E. Hoffman. Specifi- cation for DNS over Transport Layer Security (TLS). RFC 7858, May 2016

  68. [76]

    Kales, O

    D. Kales, O. Omolola, and S. Ramacher. Revisiting User Privacy for Certificate Transparency. In 2019 IEEE European Symposium on Security and Privacy (EuroS P), pages 432–447, 2019

  69. [77]

    Katz and Y

    J. Katz and Y. Lindell. Introduction to modern cryptography . CRC press, 2020

  70. [78]

    Kinnear, P

    E. Kinnear, P. McManus, T. Pauly, T. Verma, and C. A. Wood. Oblivious DNS over HTTPS. RFC 9230, June 2022

  71. [79]

    Kogan and H

    D. Kogan and H. Corrigan-Gibbs. Private Blocklist Lookups with Checklist. In 30th USENIX Security Symposium (USENIX Security 21) , pages 875–892. USENIX Association, Aug. 2021

  72. [80]

    Kosek, T

    M. Kosek, T. V. Doan, S. Huber, and V. Bajpai. Measuring dns over tcp in the era of increasing dns response sizes: A view from the edge. ACM SIGCOMM Computer Communication Review, 52(2), 2022

  73. [81]

    B. Krebs. A Deep Dive on the Recent Widespread DNS Hijacking Attacks, 2019. https://krebsonsecurity.com/2019/02/a-deep-dive-on-the-recent-widespread- dns-hijacking-attacks/

  74. [82]

    Kumar and F

    R. Kumar and F. E. Bustamante. Reclaiming privacy and performance over centralized DNS. CoRR, abs/2302.13274, 2023

  75. [83]

    Kurihara, T

    J. Kurihara, T. Tanaka, and T. Kubo. 𝜇odns: A distributed approach to DNS anonymization with collusion resistance. Comput. Networks, 237:110078, 2023

  76. [84]

    B. Li, D. Micciancio, M. Raykova, and M. Schultz-Wu. Hintless single-server private information retrieval. In Annual International Cryptology Conference, pages 183–217. Springer, 2024

  77. [85]

    Y. LU. Towards plugging privacy leaks in domain name system, cornell univer- sity library. http://arxiv. org/abs/0910.2472, 2009

  78. [86]

    Lyubashevsky, C

    V. Lyubashevsky, C. Peikert, and O. Regev. On ideal lattices and learning with errors over rings. J. ACM, 60(6), nov 2013

  79. [87]

    Y. Ma, K. Zhong, T. Rabin, and S. Angel. Incremental Offline/Online PIR. In 31st USENIX Security Symposium (USENIX Security 22) , Boston, MA, Aug. 2022. USENIX Association

  80. [88]

    Machanavajjhala, D

    A. Machanavajjhala, D. Kifer, J. Gehrke, and M. Venkitasubramaniam. L- diversity: Privacy beyond k-anonymity. ACM Trans. Knowl. Discov. Data, 1(1):3, 2007

  81. [89]

    Magnusson, M

    J. Magnusson, M. Müller, A. Brunström, and T. Pulls. A second look at DNS QNAME minimization. In A. Brunström, M. Flores, and M. Fiore, editors,Passive and Active Measurement - 24th International Conference, PAM 2023, Virtual Event, March 21-23, 2023, Proceedings , volume 1388...

  82. [90]

    Y. Meng, S. Butt, Y. Wang, Y. Zhou, S. Simoni, et al. Intel Homomorphic Encryp- tion Acceleration Library for FPGAs (version 2.0). https://github.com/intel/hexl- fpga, 2022

  83. [91]

    S. J. Menon and D. J. Wu. Spiral: Fast, high-rate single-server PIR via FHE composition. In IEEE S&P, 2022

  84. [92]

    S. J. Menon and D. J. Wu. Ypir: High-throughput single-server pir with silent preprocessing. Cryptology ePrint Archive, 2024

  85. [93]

    M. M. Michael. High performance dynamic lock-free hash tables and list- based sets. In Proceedings of the fourteenth annual ACM symposium on Parallel algorithms and architectures, pages 73–82, 2002

  86. [94]

    A. Muffett. DNS over Tor. https://developers.cloudflare.com/1.1.1.1/other- ways-to-use-1.1.1.1/dns-over-tor/

  87. [95]

    A. Muffett. DoHoT: making practical use of DNS over HTTPS over Tor. https: //medium.com/@alecmuffett/dohot-making-practical-use-of-dns-over-https- over-tor-ef58d04ca06a

  88. [96]

    M. H. Mughees, H. Chen, and L. Ren. OnionPIR: Response Efficient Single- Server PIR. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, pages 2292–2306, 2021

  89. [97]

    M. H. Mughees and L. Ren. Vectorized batch private information retrieval. Cryptology ePrint Archive, 2022

  90. [98]

    M. H. Mughees, I. Sun, and L. Ren. Simple and practical amortized sublinear private information retrieval. Cryptology ePrint Archive, 2023

  91. [99]

    Partridge, T

    C. Partridge, T. Mendez, and W. Milliken. Host anycasting service. Technical report, 1993

  92. [100]

    N. Patel. Tor networking vulnerabilities and breaches. 2016

  93. [101]

    Pernal-Stoddart

    L. Pernal-Stoddart. The Camel’s Back: Recursive to Authoritative DNS with Encryption. https://www.centr.org/news/blog/ietf110-camel-back.html

  94. [102]

    Radu and M

    R. Radu and M. Hausding. Consolidation in the dns resolver market–how much, how fast, how dangerous? Journal of Cyber Policy , 5(1):46–64, 2020

  95. [103]

    Randall, E

    A. Randall, E. Liu, G. Akiwate, R. Padmanabhan, G. M. Voelker, S. Savage, and A. Schulman. Trufflehunter: Cache snooping rare domains at large public DNS resolvers. In IMC ’20: ACM Internet Measurement Conference, Virtual Event, USA, October 27-29, 2020, pages 50–64. ACM, 2020

  96. [104]

    O. Regev. On lattices, learning with errors, random linear codes, and cryptogra- phy. J. ACM, 56(6), sep 2009

  97. [105]

    O. Regev. On lattices, learning with errors, random linear codes, and cryptogra- phy. Journal of the ACM (JACM) , 56(6):1–40, 2009

  98. [106]

    Rescorla

    E. Rescorla. Rfc 8446: The transport layer security (tls) protocol version 1.3, 2018

  99. [107]

    Rivera, V

    S. Rivera, V. K. Gurbani, S. Lagraa, A. K. Iannillo, and R. State. Leveraging ebpf to preserve user privacy for dns, dot, and doh queries. In Proceedings of the 15th International Conference on A vailability, Reliability and Security, pages 1–10, 2020

  100. [108]

    M. Sabt, M. Achemlal, and A. Bouabdallah. Trusted execution environment: What it is, and what it is not. In 2015 IEEE TrustCom/BigDataSE/ISPA, Helsinki, Finland, August 20-22, 2015, Volume 1 , pages 57–64. IEEE, 2015

  101. [109]

    Samardzic, A

    N. Samardzic, A. Feldmann, A. Krastev, S. Devadas, R. Dreslinski, C. Peikert, and D. Sanchez. F1: A fast and programmable accelerator for fully homomorphic encryption. In MICRO-54: 54th Annual IEEE/ACM International Symposium on Microarchitecture, MICRO ’21, page 238–252, New ...

  102. [110]

    Samardzic, A

    N. Samardzic, A. Feldmann, A. Krastev, N. Manohar, N. Genise, S. Devadas, K. Eldefrawy, C. Peikert, and D. Sanchez. Craterlake: A hardware accelerator for efficient unbounded computation on encrypted data. In Proceedings of the 49th Annual International Symposium on Computer A...

  103. [111]

    Schmitt, A

    P. Schmitt, A. Edmundson, A. Mankin, and N. Feamster. Oblivious DNS: Prac- tical privacy for DNS queries. Proceedings on Privacy Enhancing Technologies , 2019(2):228–244, 2019

  104. [112]

    Schomp, M

    K. Schomp, M. Allman, and M. Rabinovich. DNS resolvers considered harmful. In Proceedings of the 13th ACM Workshop on Hot Topics in Networks, HotNets-XIII, Los Angeles, CA, USA, October 27-28, 2014 , pages 16:1–16:7. ACM, 2014

  105. [113]

    Schomp, O

    K. Schomp, O. Bhardwaj, E. Kurdoglu, M. Muhaimen, and R. K. Sitaraman. Akamai DNS: providing authoritative answers to the world’s queries. In SIG- COMM’20, Virtual Event, USA, August 10-14, 2020 , pages 465–478. ACM, 2020

  106. [114]

    Schomp, M

    K. Schomp, M. Rabinovich, and M. Allman. Towards a model of dns client behavior. In International Conference on Passive and Active Network Measurement, pages 263–275. Springer, 2016

  107. [115]

    E. Shi, W. Aqeel, B. Chandrasekaran, and B. Maggs. Puncturable pseudorandom sets and private information retrieval with near-optimal online bandwidth and time. In Annual International Cryptology Conference, pages 641–669. Springer, 2021

  108. [116]

    Singanamalla, S

    S. Singanamalla, S. Chunhapanya, J. Hoyland, M. Vavrusa, T. Verma, P. Wu, M. Fayed, K. Heimerl, N. Sullivan, and C. A. Wood. Oblivious DNS over HTTPS (ODoH): A Practical Privacy Enhancement to DNS.Proc. Priv. Enhancing Technol., 2021(4):575–592, 2021

  109. [117]

    R. N. Staff. Ripe atlas: A global internet measurement network. Internet Protocol Journal, 18(3):2–26, 2015

  110. [118]

    Vekshin, K

    D. Vekshin, K. Hynek, and T. Cejka. Doh insight: detecting DNS over HTTPS by machine learning. In ARES 2020: The 15th International Conference on A vailability, Reliability and Security, Virtual Event, Ireland, August 25-28, 2020, pages 87:1–87:8. ACM, 2020

  111. [119]

    L. Wang, H. Kim, P. Mittal, and J. Rexford. Programmable in-network obfuscation of dns traffic. In NDSS: DNS Privacy Workshop. sn, 2021

  112. [120]

    Winter, R

    P. Winter, R. Ensafi, K. Loesing, and N. Feamster. Identifying and characterizing sybils in the tor network. In USENIX Security Symposium, volume 12, 2016. 14

  113. [121]

    Y. Xiao, Y. Gu, Y. Zhao, S. Lin, and A. Kuzmanovic. Enabling Anonymous Online Streaming Analytics at the Network Edge. ACM Transactions on Computer Systems, 2025

  114. [122]

    Y. Xiao, M. Varvello, and A. Kuzmanovic. Monetizing spare bandwidth: The case of distributed vpns. Proceedings of the ACM on Measurement and Analysis of Computing Systems, 6(2):33:1–33:27, 2022

  115. [123]

    Y. Xiao, Y. Zhao, S. Lin, and A. Kuzmanovic. Snatch: Online streaming analytics at the network edge. In Proceedings of the Nineteenth European Conference on Computer Systems, EuroSys 2024, Athens, Greece, April 22-25, 2024 . ACM, 2024

  116. [124]

    F. Zhao, Y. Hori, and K. Sakurai. Two-servers PIR based DNS query scheme with privacy-preserving. In The 2007 International Conference on Intelligent Pervasive Computing (IPC 2007), pages 299–302. IEEE, 2007

  117. [125]

    M. Zhou, A. Park, E. Shi, and W. Zheng. Piano: Extremely simple, single- server pir with sublinear server computation. Cryptology ePrint Archive, Paper 2023/452, 2023. https://eprint.iacr.org/2023/452

  118. [126]

    Scalability

    M. Zhou, A. Park, E. Shi, and W. Zheng. Piano: Extremely simple, single-server pir with sublinear server computation. Cryptology ePrint Archive, 2023. A ETHICS CONSIDERATIONS Our methodology in the evaluation (Appendix E.1) uses synthetic DNS traffic via a publicly available s...

  119. [128]

    We further assume when a cache miss occurs, the response can be forwarded to PDNS ReR instantaneously

    = 1−𝑚. We further assume when a cache miss occurs, the response can be forwarded to PDNS ReR instantaneously. However, to defend against timing attacks from PDNS ReR, i.e., correlating the forwarded response from ANSes and the queries where user identity is known to PDNS ReR, ...

  120. [2020]

    Springer International Publishing

Pith tools

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