{"id":"6b39fed5-e61f-46f2-89dd-86a4d6087b7e","arxiv_id":"1908.04574","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Resolver-less DNS proposes a DNS-Record HTTP response header letting web servers push A/AAAA records to clients, saving the client-to-resolver round trip on subsequent connections.","lead":"Web servers could send their own IP addresses to browsers in an HTTP header, letting browsers skip the usual DNS lookup for later connections to the same site. This paper measures how much latency that would save and argues the approach also hides some browsing activity from DNS resolvers.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Censorship-resilience claim fails for insecure traffic by the paper's own validation logic: a tampered fallback resolver wins whenever the client follows Figure 2.","rationale":"The reader's weakest assumption is close but slightly broader: it worries about non-compliant clients and untrustworthy fallback. My concern is sharper and does not require client misbehavior. Even a perfectly compliant client, following the right branch of Figure 2, discards the resolver-less DNS record on a mismatch and uses the fallback address for insecure connections. That is a logical consequence of the proposed design, quoted in Section 3.2.2 ('the client uses the address within the fallback DNS record'), and it collides with the paper's headline censorship claim. The paper's own Section 5.1 limits the censorship improvement to 'connections ... established using server authentication,' but the abstract and design goal 9 do not. This is an internal overclaim rather than an attack on the performance measurements, which are honest lower bounds. The performance and privacy parts of the central claim are not disturbed. I therefore keep the reader's CONDITIONAL verdict; the security/censorship section should be qualified to TLS-authenticated connections or the insecure-path validation should be re-specified.","tokens_in":11443,"tokens_out":12932,"duration_ms":135606,"concrete_test":"Build a minimal client that implements the Figure 2 strategy exactly. Configure its fallback resolver to return a tampered answer for victim.example, e.g., A=203.0.113.1, while a test server sends DNS-Record: hostname=victim.example; A=198.51.100.2. Load an http:// page whose subresource is http://victim.example/asset.js and record the destination IP of the asset GET. If the request goes to 203.0.113.1 rather than 198.51.100.2, the validation logic itself moves insecure traffic to the tampered resolver, and the abstract's unconditional 'improves resilience against censorship' claim fails for every non-TLS connection.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 5.1 conditions the security guarantee on the fallback DNS mechanism 'still provid[ing] trustworthy DNS records,' and Figure 2 requires a fallback lookup before any application data can be sent over an insecure connection. These two conditions undermine the abstract's claim that resolver-less DNS 'even improves the user's resilience against censorship through tampered DNS resolvers.' Under a tampered resolver, the fallback is untrustworthy by definition. For any plain-HTTP connection—the right branch of Figure 2, where no server authentication is indicated—the client must conduct a fallback DNS lookup; when the resolver-less and fallback records differ, the client is instructed to use the fallback record to connect and send data. That is precisely the tampered resolver's address, so the censored answer wins. The censorship benefit thus exists only for server-authenticated (TLS) connections; the paper concedes this in the last sentence of the censorship paragraph but states the improvement without qualification in the abstract and design-goal list. For insecure traffic, the mechanism offers no more censorship resilience than traditional DNS, and its security guarantee reduces to the trustworthiness of the very resolver it was intended to bypass.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":11575,"tokens_out":7909,"duration_ms":80938,"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":[{"comment":"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.","section":"3.2.2 / Figure 2; 4.1.2"},{"comment":"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.","section":"5.1 and Abstract"},{"comment":"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":"5.1, four-case analysis"},{"comment":"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.","section":"Section 4 (overall)"}],"minor_comments":[{"comment":"There is a typo in 'it's identity' that should read 'its identity'.","section":"3.2.2"},{"comment":"The related-work section refers to 'Oblivous DNS'; the correct spelling is 'Oblivious DNS'.","section":"6"},{"comment":"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.","section":"4.3.1"},{"comment":"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.","section":"4.2.2"},{"comment":"References [25] and [26] appear to be the same arXiv paper (1907.01291) listed twice; one entry should be removed.","section":"References"},{"comment":"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.","section":"Figure 2"}],"recommendation":"major_revision","confidential_remarks":"This is a borderline case: the idea is simple, the measurements are honestly reported, and the paper is within the scope of a networking venue that accepts design-plus-measurement work without a full prototype. However, the abstract and design-goal list overclaim both performance and censorship resilience relative to the design's own validation logic. I recommend requiring the qualifications and threat-model additions described in the major comments before reconsideration."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","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.\n\nThe 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.\n\nThe 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.\n\nMinor 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.\n\nBottom 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.","headline":"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.","tokens_in":12197,"tokens_out":1826,"would_cite":false,"duration_ms":19101,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A proposed DNS-Record HTTP header lets web servers hand clients DNS answers, letting those clients skip a resolver round trip on later connections.","keywords":["DNS","resolver-less DNS","HTTP response header","DNS-Record header","recursive resolver","web performance","privacy","censorship resistance"],"falsifier":"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.","tokens_in":11136,"feed_emoji":"⚡","tokens_out":7963,"duration_ms":75711,"temperature":0.7,"pith_summary":"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.","feed_headline":"DNS records via HTTP headers can save slow users 80 ms per lookup","feed_subtitle":"The slowest 1% of users save at least 80 ms per lookup, and the resolver sees fewer of the user's queries.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the distributed measurement network used to obtain client-to-resolver RTTs that ground the 80 ms saving claim.","marker":"[20]"},{"why":"Documents that roughly a quarter of DNS transactions take between 10 ms and 1 s, showing why resolver RTT understates the lookup time saved.","marker":"[3]"},{"why":"Reports DNS cache hit rates and the share of TCP connections that follow a DNS query, defining the performance and privacy baseline.","marker":"[12]"},{"why":"Provides the top-site list whose fresh A and AAAA TTLs are measured to show the server-side refresh cost is modest.","marker":"[11]"},{"why":"Defines EDNS client subnet, the compatibility feature whose support is measured to show the design works with location-aware resolution.","marker":"[5]"},{"why":"Documents real-world DNS manipulation by resolvers, the censorship threat the design claims to improve upon.","marker":"[19]"},{"why":"Shows DNSSEC validation gaps, motivating the paper's reliance on server authentication and fallback lookups rather than DNSSEC.","marker":"[4]"}],"fun_headline_variants":["HTTP header replaces DNS lookup on repeat visits, saving 80ms","Resolver-less DNS: Shave 80ms off slowest 1%, more privacy","Server sends DNS via HTTP: No resolver round trip, 80ms saved","DNS records via HTTP: Faster, more private, no security loss"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["HTTP header replaces DNS lookup on repeat visits, saving 80ms","Resolver-less DNS: Shave 80ms off slowest 1%, more privacy","Server sends DNS via HTTP: No resolver round trip, 80ms saved","DNS records via HTTP: Faster, more private, no security loss"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.0007,"raw_usage":{"total_tokens":3138,"prompt_tokens":902,"completion_tokens":2236,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":518,"completion_tokens_details":{"reasoning_tokens":2155}},"tokens_in":518,"tokens_out":2236,"duration_ms":17063,"temperature":1.0,"reasoning_tokens":2155,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T13:39:22.454958+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"8 Dominik Herrmann, Christian Banse, and Hannes Federrath","cited_arxiv_id":null,"evidence_quote":"Documents that roughly a quarter of DNS transactions take between 10 ms and 1 s, showing why resolver RTT understates the lookup time saved."},{"cited_title":"Accelerating QUIC's Connection Establishment on High-Latency Access Networks","cited_arxiv_id":"1907.01291","evidence_quote":"Reports DNS cache hit rates and the share of TCP connections that follow a DNS query, defining the performance and privacy baseline."}],"review_version":1}