{"id":"e2890b04-b4e5-420b-ad0b-2329286d6610","arxiv_id":"2608.00643","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"An attacker can reuse a DNS-derived IP permit for one allowed domain to reach a different co-located tenant on the same shared IP; 95.8% of 1M measured domains are exposed to this.","lead":"The paper shows a traffic-hiding attack that resolves an allowed domain to obtain a firewall permit for a shared IP, then connects to that IP presenting a different domain in both the TLS name and HTTP Host, so the shared server routes to the hidden tenant. Probing 1,069,048 domains, the authors report 95.8% of measured domains sit on addresses that accept this.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Generalization to 'any DNS-bound access control' is unsupported: a control that binds the DNS-approved domain to the connection SNI defeats DDA, and the prevalence of the vulnerable address-level subclass is never measured.","rationale":"The paper makes a genuine, mechanically plausible observation: address-level permits derived from DNS resolution can be reused for a different tenant on a shared IP, and the lab result with ZTDNS demonstrates that this works for at least one real control. The measurement of 1,069,048 domains is substantial and the HIGH/MEDIUM/LOW decomposition is transparent. The load-bearing weakness is not the lab mechanism but the generalization. The paper's own Assumption A2 limits the threat model to controls that do not bind the address permit to the DNS-approved domain. Yet §III-B2 concludes that 'DNS-bound access controls cannot preserve the approved-domain binding' and §IV asserts that the bypass is 'structural and transfers to any DNS-bound control that admits resolver-returned addresses.' A DNS-bound control that requires the connection-level identity to match the resolved domain—which is exactly what the paper recommends as a mitigation—defeats the attack. The paper never measures how many real deployments use the address-level-only subclass, so the 95.8% exposure rate cannot be read as an attack-success rate. The reader already identified Assumption A2 and the missing prevalence measurement as the weakest assumption; this check agrees and adds a concrete falsification test for the overbroad structural claim. The verdict remains CONDITIONAL because the core mechanism is sound but the scope claim needs to be narrowed and the prevalence of the vulnerable class established.","tokens_in":13548,"tokens_out":6520,"duration_ms":76280,"concrete_test":"Build a DNS-bound egress enforcement point that (1) permits only IP addresses returned by the trusted resolver for allowlisted domains and (2) binds each permit to the domain(s) in that DNS response, checking the TLS ClientHello SNI (and, for ECH, the decrypted inner SNI) against the bound domain before allowing the connection—implementable as a Windows WFP callout, an eBPF/LSM hook, or an inline TLS-intercepting proxy. Re-run the paper's Simple-Mode and ECH-Mode lab scenarios against it with the same shared-edge setup. If the second-tenant connection is blocked/flagged, the paper's 'structural and transfers to any DNS-bound control' claim is falsified in its current breadth and must be restricted to controls lacking domain binding; then the missing quantity is the real-world prevalence of that restricted subclass.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's core generalization is the claim in §III-B2 and §IV that DNS-bound access control cannot preserve the approved-domain binding on a shared address and that the bypass is structural, transferring to any DNS-bound control that admits resolver-returned addresses. The laboratory demonstration, however, exercises exactly one control (Windows ZTDNS), whose dynamic permit is address-level. This instantiates Assumption A2 ('does not bind this permission to the domain associated with the DNS response'), but A2 is an assumption, not a measured property of the control population. A DNS-bound control could admit only resolver-returned addresses and still require the TLS SNI/certificate of each connection to match the domain that justified the address permit; that is precisely the mitigation the paper recommends ('bind connection-time identity to the approved domain'). Such a control would block Simple Mode and expose ECH Mode's inner SNI at the enforcing point. So the 'structural' conclusion holds only for the subclass of controls without domain binding, and the paper provides no evidence about how widely that subclass is deployed. The 95.8% exposure rate quantifies edge-side acceptance of foreign SNIs; it does not measure attack success under DNS-bound controls. The central mechanism is plausible and the lab result appears internally consistent, but the scope of the central claim is asserted rather than established.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper introduces the Domain Decoupling Attack (DDA), which exploits the separation between DNS-based domain authorization and IP-level connection permissions on shared CDN and non-CDN hosting edges. The attacker resolves an allowlisted domain to obtain a permit for a shared edge IP, then connects to the same IP while presenting another domain consistently in TLS SNI and HTTP Host. Four modes are described: Simple, Split, ECH, and Direct IP. A laboratory evaluation with Windows ZTDNS shows that after resolving an allowed domain, the resulting address-level permit can be reused to reach a blocked domain on the same shared edge with ordinary TLS and with ECH. A large-scale measurement of 1,069,048 Tranco domains reports that 95.8% accept a TLS handshake carrying an external SNI, with 84.6% reaching the HIGH level where the hidden tenant's content is returned. The paper further claims a co-location chain attack that extends a single approved domain to all domains in a connected same-IP co-location graph, and concludes that DNS-bound access controls have a structural limitation on shared addresses.","tokens_in":13803,"tokens_out":9682,"duration_ms":93081,"significance":"The laboratory result is a clean, direct demonstration that a real DNS-bound access control (Windows ZTDNS) grants address-level permissions that can be reused by another tenant on the same shared IP. The measurement is large-scale (over one million domains, 18 million probes) and the exposure claim is not the product of a fitted parameter; the SimHash threshold only separates HIGH from MEDIUM. If the results hold, the paper documents an important architectural gap between DNS-domain decisions and IP-level enforcement. The contribution is currently weakened by two overstatements: the 'structural' generalization from ZTDNS to all DNS-bound controls is not established, and the co-location-chain transitivity claim is mathematically incorrect as stated. With corrected framing, this would be a solid empirical contribution to the literature on DNS-based egress control and shared-infrastructure security.","major_comments":[{"comment":"The claim that the bypass is 'structural and transfers to any DNS-bound control that admits resolver-returned addresses' (§IV) is unsupported. The laboratory evaluates only Windows ZTDNS, which exactly matches Assumption A2 (address-level permit without domain binding). A control that admits resolver-returned addresses but binds the permit to the resolved domain's SNI/certificate—the paper's own recommended mitigation—would block Simple Mode and force the ECH inner SNI to be exposed at the enforcement point. The 95.8% measurement quantifies edge-side acceptance of foreign SNIs, not the prevalence of the vulnerable control class or attack success under DNS-bound controls. The conclusion must be scoped to DNS-bound controls that grant address-level permissions without domain binding; as written, the central 'structural limitation' claim is an assertion, not a demonstrated result.","section":"§IV / §III-B2"},{"comment":"The co-location-chain argument overstates reachability. The graph is defined by same-IP co-location, so a connected component can contain domains that do not share any single IP (e.g., A shares IP1 with B, B shares IP2 with C). The statement that 'co-location is transitive over shared IPs, one approved domain reaches every tenant in its connected component' is false: A's approved DNS permit covers IP1 only; reaching C requires a separate permit for IP2. The component-size statistics (largest component 77,991 domains) therefore do not support the claim that a single allowlisted domain covers an entire component. The chain attack is only valid when each additional tenant along the path is itself an authorized domain. This should be stated explicitly, and the abstract and contribution list should be reworded to avoid the transitive-reach claim.","section":"§III-D"}],"minor_comments":[{"comment":"The abstract's 95.8% exposure rate includes MEDIUM and LOW results (TLS success without content match). The HIGH rate of 84.6% is the rate at which the hidden tenant's content is actually served. Please report both rates together in the abstract or clarify that 'exposure' means SNI acceptance only, to avoid overstating practical attack success.","section":"Abstract / §III-A3"},{"comment":"Split Mode is presented as a DDA mode, but the laboratory evaluation covers only Simple Mode and ECH Mode. If Split Mode is not empirically evaluated, this should be stated explicitly in the evaluation section; otherwise the mode remains an untested hypothesis.","section":"§III-A2 / §II-E"},{"comment":"The phrase 'across six continents' refers to GeoLite2 registration locations of edge IPs, not to measurement vantage points. The location of the measurement server is not stated. Clarify this to avoid implying geographically distributed scanning.","section":"§III-A1 / §III-C2"},{"comment":"Only the SimHash threshold 0.90 is mentioned; no sensitivity analysis or score distribution is provided. The paper states the exposure claim is threshold-independent, but a figure of similarity-score distributions would substantiate this.","section":"§III-A3"},{"comment":"The country-level aggregation merges Hong Kong, Taiwan, and Macao into 'China'. This is a politically sensitive labeling choice; please align with ISO 3166 or provide a clarifying footnote.","section":"§III-C2"}],"recommendation":"major_revision","confidential_remarks":"The core laboratory result appears sound and the measurement is large and potentially useful. The main problems are the overgeneralized 'structural' conclusion about all DNS-bound controls and the incorrect transitivity claim in the co-location-chain section. Both can be fixed by scoping the claims and correcting the graph argument. After these revisions, the paper could be a strong contribution to the security community's understanding of DNS-derived IP authorization on shared infrastructure."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nThe one thing you should know: the core DDA mechanism is real, and the ZTDNS lab result is clean. What is not real is the sweeping generalization that the bypass is structural for 'any DNS-bound access control.' That claim is asserted, not established.\n\nWhat's actually new: DDA keeps SNI=Host consistent and moves the divergence to the DNS stage vs connection stage. That is a distinct variant from domain fronting (SNI≠Host), borrowing, and shadowing. The lab demonstration in §III-B2 is direct: after resolving an allowed domain, ZTDNS's address-level permit lets a separate TLS connection to the same IP with a different SNI reach the other tenant, with and without ECH. The 1M-domain measurement is large and transparent, with HIGH/MEDIUM/LOW decomposed and the confidence that TLS acceptance itself is the exposure criterion. The co-location chain is a nice extension: one allowed domain covers a whole connected component.\n\nSoft spots, in order of size. First, the generalization. The paper tests exactly one control — Windows ZTDNS — and its own Assumption A2 says the firewall 'does not bind' the permission to the DNS-answered domain. That is the very property that makes DDA work. A control that admits only resolver-returned IPs but also requires the TLS SNI/cert to match the domain that justified the permit would defeat DDA in Simple Mode and expose ECH's inner SNI at the enforcement point. The paper recommends exactly this binding as a mitigation, so the 'structural limitation' conclusion applies only to the address-level subclass. The prevalence of that subclass in real deployments is never measured. Related: the 95.8% figure is a routing-side exposure rate (edge accepts a foreign SNI), not an attack-success rate under actual DNS-bound controls. The paper is careful to define exposure that way, but the abstract's framing invites over-reading.\n\nSecond, Simple Mode's 'traffic-hiding' label is too strong. Table I shows Zeek logs the malicious SNI in Simple Mode; what's hidden is only the DNS-stage approval, not the SNI. Split/ECH modes hide more, but Simple Mode is only stealthy against DNS and IP-level controls.\n\nMinor: no code or data artifacts released, and no error bars, though the sample is large enough that sampling error is unlikely to change the headline.\n\nWho should read it: network-security researchers and anyone designing or deploying ZTDNS-class DNS-bound egress controls. It deserves serious peer review, but with a required revision to bound the generalization and reframe the exposure metric. I'd bring it to a reading group — there's a good discussion about what 'structural' means in security claims.","headline":"The core DDA mechanism is real and the ZTDNS lab result is clean, but the paper overreaches when it calls the bypass structural for 'any DNS-bound control' — that is an assumption, not a measured property.","tokens_in":14386,"tokens_out":2704,"would_cite":true,"duration_ms":28657,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that DNS-based egress controls are structurally unable to keep a permitted connection bound to the domain that earned the permission, and that an attacker can reach nearly any tenant sharing the allowed domain's IP address","keywords":["Domain Decoupling Attack","Protective DNS","DNS-bound access control","shared edge","TLS SNI","CDN multi-tenancy","traffic hiding","egress filtering"],"falsifier":"A concrete falsifier would be a single enterprise deployment where, after a client resolves an allowed domain and receives an IP-level permit, the egress control rejects or flags a TLS connection to the same IP when the SNI names a different domain that is also hosted on that IP — or a measurement showing that a representative DNS-bound egress product binds the permit to the resolved domain at connection time in its default configuration.","tokens_in":13355,"feed_emoji":"🔓","tokens_out":2400,"duration_ms":29196,"temperature":0.7,"pith_summary":"The paper introduces the Domain Decoupling Attack (DDA), which exploits a validation gap in DNS-based authorization: a protective DNS service approves a domain, but the resulting firewall or Zero Trust DNS permit applies to the resolved IP address, not to that domain. Because CDN and shared-hosting edges serve many tenants behind one IP, an attacker can resolve an allowed domain, obtain permission for the shared edge address, then connect to that same address while presenting a hidden domain consistently in TLS SNI and HTTP Host. A large-scale measurement of 1,069,048 domains found that 95.8% accept such a connection, with 99.26% exposure among CDN domains and 92.75% among non-CDN domains. Laboratory tests with Windows ZTDNS confirmed the underlying structural limitation: DNS-bound access control cannot preserve the approved-domain binding when a later connection selects another tenant behind the same shared address. The paper argues this makes DDA distinct from domain fronting (no SNI–Host inconsistency), domain borrowing (no ownership verification weakness), and domain shadowing (no routing rewrite), and recommends defenders bind connection-time identity to the approved domain.","feed_headline":"DNS door pass reused: 95.8% of domains reachable via one allowed name","feed_subtitle":"A shared IP turns a single approved domain into a key to nearly every tenant behind it, bypassing SNI–Host checks.","key_machinery":"The core mechanism is the 'validation gap' described as a tuple (D_allowed, IP_cdn, D_malicious, D_malicious), where the DNS-approved domain D_allowed yields a permitted shared address IP_cdn, and the connection then presents D_malicious consistently in both SNI and Host. The load-bearing object is the address-level permission granted by DNS-bound access control (e.g., Windows ZTDNS), which applies to the IP rather than to the domain associated with the DNS response. A second mechanism is the 'co-location chain': same-IP tenants form connected components in a graph, so one approved cover domain extends to every tenant in its component.","core_discovery":"DDA is a new traffic-hiding attack that separates the domain approved during DNS resolution from the domain presented during connection establishment while preserving SNI–Host consistency. The attack resolves an allowed domain to obtain an address-level permission for a shared edge IP, then connects to the same IP while presenting the hidden domain in both TLS SNI and HTTP Host. The CDN or shared-hosting edge routes the connection to the hidden tenant because tenant selection is based on connection-level identity, not on the DNS-approved domain. Measurements on 1,069,048 domains show that 95.8% accept a TLS handshake carrying an external SNI, and that a co-location chain extends a single aut","pith_inferences":["The prevalence of the vulnerable architecture on real enterprise networks is not measured; the paper verifies the bypass in a controlled lab for one DNS-bound control (Windows ZTDNS) and extrapolates structurally. A follow-up could survey how many enterprise egress controls issue address-level permits without domain binding.","The attack likely also applies to other address-level allowlists (e.g., some cloud firewalls or access-control proxies) that derive permit state from a DNS response; testing these would show whether the validation gap is broader than CDN and shared hosting.","A defense that binds connection-time identity to the approved domain would need to handle legitimate scenarios where a domain resolves to multiple IPs and where connections to the same IP may be load-balanced; the paper does not discuss the usability cost of such binding.","The measurement's 'exposure' is defined as TLS acceptance plus content match where applicable; a stricter definition that requires a full application-layer response might yield lower rates, though the paper separates HIGH, MEDIUM, and LOW levels."],"forward_implications":["If the central claim is correct, DNS-bound egress allowlists cannot reliably restrict traffic to approved domains when the permitted IP serves multiple tenants, because permission is granted at the address level.","Defenders should bind connection-time identity to the approved domain (e.g., require SNI to match the DNS-approved domain at the edge) and treat address-level reuse on shared edges as a security property.","The co-location chain means that a small allowlist can cover a large reachable set: one approved domain can provide cover for every tenant in its same-IP connected component, potentially thousands of unrelated domains.","Encrypted Client Hello (ECH) removes the connection-level domain from inspection, so SNI-aware inspection cannot distinguish the hidden tenant from the allowed one in ECH Mode; rules based on the outer name or shared IP are non-selective.","The attack adds no protocol overhead and requires no special privilege, certificate, or modification of network controls, making it a low-cost technique for concealing C2, data exfiltration, and censorship-circumvention traffic.","Provider-specific edge policies affect feasibility (exposure ranges from 76.52% for one CDN to 99.72% for another), suggesting that some providers can mitigate the attack by cross-checking connection identity against the DNS-approved domain."],"fun_headline_variants":["DNS validation gap lets one domain reach 95.8% of neighbors","Domain Decoupling Attack: one approved domain, many tenants","Shared edge IP: DNS permission reused to reach other hosts","95.8% of domains exposed via DNS-auth gap on shared IPs","Bypass access control with SNI-Host consistency using DDA"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The attack's generality rests on the assumption that real DNS-bound egress controls grant outbound permission at the address level without binding that permission to the domain associated with the DNS response, and that no inline application-layer inspection blocks or flags the hidden domain's cleartext SNI in Simple Mode.","fun_headline_variants_meta":{"raw":{"variants":["DNS validation gap lets one domain reach 95.8% of neighbors","Domain Decoupling Attack: one approved domain, many tenants","Shared edge IP: DNS permission reused to reach other hosts","95.8% of domains exposed via DNS-auth gap on shared IPs","Bypass access control with SNI-Host consistency using DDA"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000806,"raw_usage":{"total_tokens":3390,"prompt_tokens":769,"completion_tokens":2621,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":513,"completion_tokens_details":{"reasoning_tokens":2530}},"tokens_in":513,"tokens_out":2621,"duration_ms":18641,"temperature":1.0,"reasoning_tokens":2530,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T01:26:20.049325+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A concrete falsifier would be a single enterprise deployment where, after a client resolves an allowed domain and receives an IP-level permit, the egress control rejects or flags a TLS connection to the same IP when the SNI names a different domain that is also hosted on that IP — or a measurement showing that a representative DNS-bound egress product binds the permit to the resolved domain at connection time in its default configuration.","supporting_citations":[],"review_version":1}