Domain Decoupling Attack: Exploiting the Validation Gap Between Protective DNS and Shared Edge Routing

Domain Decoupling Attack: Exploiting the Validation Gap Between Protective DNS and Shared Edge Routing Weizhe Wang† , Minhong Dong† , Jinhao Li† , Yao Zhang† * , Hao Liu‡ , Qiang Hu† , Tao Luo† , Guangquan Xu† , Bin Wu† † Tianjin University, Tianjin, China

arXiv:2608.00643v1 [cs.CR] 1 Aug 2026

‡ QAX Technology Group Inc., Beijing, China

Abstract—Network attackers often conceal malicious communication within legitimate Internet traffic. Existing CDNbased evasion techniques rely on SNI–Host inconsistency, insufficient domain ownership verification, or provider-specific routing rewrites, which limit their applicability in modern CDN environments. We identify a validation gap in DNS-based authorization, where permission derived from an allowed domain applies to a shared IP and can be reused to reach another tenant in both CDN and non-CDN shared-hosting environments. This paper presents the Domain Decoupling Attack (DDA), which resolves an allowed domain to obtain permission for a shared edge IP and subsequently connects to the same address while presenting the hidden domain consistently in both TLS SNI and HTTP Host. Measurements of 1,069,048 domains across six continents produce 18,025,068 successful probes and identify exposure rates of 95.8% overall, 99.26% for CDN domains, 92.75% for nonCDN domains, and 97.7% for non-CDN cross-tenant IPs, while laboratory experiments reveal a structural limitation of DNSbound access control on shared addresses. These results clarify the security risks of DNS-derived IP authorization and support the evaluation and improvement of access-control mechanisms in CDN and non-CDN shared-hosting environments. Index Terms—Traffic-hiding Attack, Protective DNS, DNSbound Access Control, Shared Edge

I. I NTRODUCTION Network attackers seek to conceal malicious communication within legitimate Internet traffic [1], [2]. Such concealment supports command-and-control communication, data transfer, and censorship circumvention because external monitors cannot easily identify the actual communication destination [3]–[6]. Attackers commonly route malicious traffic through widely used Internet infrastructure, since blocking this infrastructure may also disrupt legitimate services [7], [8]. Content delivery networks are particularly suitable for this purpose because their distributed edge nodes carry large volumes of benign traffic for many independent domains. Attackers therefore exploit CDN protocol behaviors and routing mechanisms to hide communication destinations from network defenses [9], [10]. Existing CDN-based evasion techniques adopt several approaches to conceal communication destinations. Domain ∗ Corresponding author: Yao Zhang.

fronting exposes a high-reputation front domain in the DNS query and TLS Server Name Indication, while the encrypted HTTP Host header identifies another destination [4], [11]. Modern CDN providers restrict this behavior through consistency checks between TLS SNI and HTTP Host [12]. Domain borrowing maintains this consistency but depends on insufficient domain ownership verification during CDN deployment [13]. Domain shadowing relies instead on CDN routing rules that rewrite a visible front domain to another backend destination [7], [14]. These techniques consequently require cross-layer domain inconsistency, missing ownership verification, or provider-specific routing functions. Such dependencies limit their applicability in modern CDN environments. Domain-based services commonly require DNS resolution before connection establishment, which makes DNS a widely deployed component of network communication and access control. Protective DNS systems inspect domain requests, whereas Windows Zero Trust DNS translates trusted resolution results into permissions for the returned IP addresses [15], [16]. Public IP sharing is also widespread because limited IPv4 resources and name-based virtual hosting allow multiple domains to share one address [17], [18]. Modern CDNs expand this arrangement across large-scale multi-tenant edge infrastructures, where one public IP address serves many independent domains [19]. The widespread use of DNS and shared-IP hosting makes the resulting attack surface applicable beyond a specific CDN function or configuration. The combination of these properties creates a validation gap between domain approval and connection routing. A trusted DNS service approves an allowed domain and returns the address of a shared CDN edge node. The endpoint security mechanism subsequently permits outbound traffic to the returned IP address. However, this permission applies to the shared address rather than exclusively to the domain associated with the DNS response. The same address can also serve other tenants on the CDN infrastructure [20], [21]. A later connection can retain the authorized destination IP while presenting another domain consistently in both TLS SNI and HTTP Host. The DNS stage approves one domain, whereas the

Endpoint

User-Controlled Environment is "Security"

User app

resolve allowed.com

returns shared edge IP

Protective DNS domain filtering

permit this IP

Defense records allowed.com, shared IP

Firewall / Zero Trust DNS permit by IP, not by domain

≠ CDN edge (shared IP) allowed.com tenant

Other 10,000+ domains share this IP

IP can deliver any of 10,000+ domains

Fig. 1. Validation gap between DNS-based authorization and CDN tenant routing.

resulting IP-level permission provides reachability to another domain behind the same endpoint. Figure 1 illustrates this validation gap. The DNS-approved domain grants permission to a shared edge IP, while the same IP can route a subsequent connection to another tenant. An effective attack against this validation gap must satisfy two requirements. The connection must conceal the actual destination without introducing the SNI–Host inconsistency required by conventional domain fronting. Modern CDN consistency checks require both fields to identify the same domain during connection establishment [22]. The attack must also exploit shared-IP authorization without depending on insufficient domain ownership verification or internal CDN routing rewrites. Existing CDN-based evasion techniques cannot satisfy both requirements simultaneously. The domain difference must appear between the DNS and connection stages, while the TLS and HTTP identities remain consistent. This paper presents Domain Decoupling Attack (DDA), a new traffic-hiding attack that exploits the separation between trusted DNS resolution and CDN tenant routing or shared hosting. The client resolves an allowed high-reputation domain through a trusted DNS service and obtains the address of a shared edge node. The resolution result causes the endpoint policy to permit outbound communication with the returned IP address. The client subsequently retains the authorized destination IP but presents the hidden domain consistently in both TLS SNI and HTTP Host. The CDN or shared hosting then routes the connection to the hidden domain through the same shared endpoint. Unlike domain fronting, DDA does not introduce inconsistent identities between the TLS and HTTP layers. It also avoids the ownership-verification weakness required by domain borrowing and the internal routing rewrites required by domain shadowing. DDA instead places the domain difference between the DNS and connection

stages, thereby preserving SNI–Host consistency while reusing the IP permission derived from an allowed DNS resolution. Overall, this paper makes the following contributions. • We introduce Domain Decoupling Attack (DDA), a new traffic-hiding attack that exploits the missing binding between DNS authorization and CDN tenant routing while preserving SNI–Host consistency. DDA achieves exposure rates of 92.75% for non-CDN domains, 97.7% for non-CDN cross-tenant IPs, and up to 99.26% under common CDN policies. • We conduct a large-scale measurement of 1,069,048 domains across six continents and collect 18,025,068 successful probe results. The measurement characterizes the vulnerability level and geographic distribution of the targets and reports an overall exposure rate of 95.8%. • We identify the co-location chain, which extends DDA from one domain pair to a connected group of tenants sharing edge infrastructure. A single authoritative domain can therefore provide cover for accessing multiple colocated tenants without modifying the cover domain. • We evaluate DDA against representative network defenses and reveal a structural limitation of DNS-bound access control. Existing defenses cannot reliably distinguish allowed and hidden tenants that share the same authorized edge address, while DDA introduces negligible overhead. II. D OMAIN D ECOUPLING ATTACK A. System and Authorization Model We consider an enterprise network access-control system represented as M = (Pdns , Pfw , Pdpi , Ccdn ).

(1)

The component Pdns represents the domain-filtering policy enforced by a protective DNS service. The component Pfw denotes the IP-level access policy implemented by a network firewall or a Zero Trust DNS mechanism. The component Pdpi represents the application-layer inspection policy that examines domain identities exposed during TLS communication. The component Ccdn describes the tenant-routing logic of a shared CDN edge node. A complete HTTPS communication lifecycle is represented as L = (Dreq , IPres , SN I, Host), (2) where Dreq denotes the domain submitted for DNS resolution, IPres denotes the returned destination address, and SN I and Host denote the domain identities presented during TLS and HTTP communication. A conventional domain-binding assumption requires Dreq = SN I = Host

(3)

IPres ∈ Resolve(Dreq ).

(4)

and Under this assumption, the domain approved during DNS resolution remains consistent with the identities used during the subsequent connection.

DNS stage

Legitimate session

Client

Connection stages

1 · DNS query

2 · Address permit (firewall)

3 · TLS handshake

4 · HTTP request (shared edge)

allowed domain

shared edge IP

allowed domain

allowed domain

allowed domain DDA connection

Client (attacker)

1 · DNS query

2 · Address permit (firewall)

3 · TLS handshake

4 · HTTP request (shared edge)

allowed domain

shared edge IP

malicious domain

malicious domain

allowed domain no DNS log shared edge IP only

Visible

— Direct IP Mode — no DNS query

≠

malicious domain SNI visible: malicious domain sees allowed domain (C1) no DPI in path C2 within Δt skipped

sees outer SNI only inner SNI encrypted

— Simple Mode — — Split Mode — — ECH Mode — plaintext SNI

2nd conn. within Δt

inner SNI encrypted

Fig. 2. DDA overview: the DNS-approved domain and the connection-level tenant diverge at the shared edge.

The DDA, challenges this cross-stage binding. DDA separates the domain approved during DNS resolution from the domain presented during connection establishment. The attack preserves valid domain information within the HTTPS connection whenever possible, while it exploits the fact that the DNS and firewall policies authorize an IP address rather than a unique CDN tenant. The attacker controls a client application and a CDNhosted destination identified by Dmalicious . The attacker also identifies an allowed domain Dallowed that resolves to a shared CDN edge address IPcdn . The attacker does not modify the protective DNS service, firewall, inspection engine, or CDN routing infrastructure. Instead, DDA exploits the different information available to these components during the communication lifecycle.

A3. Ccdn selects the tenant from the connection-level identity (the SNI, or the inner SNI after ECH decryption) and does not cross-check this identity against the domain resolved during the DNS stage. A4. The attacker preserves consistency between the TLS identity and the HTTP Host as observed by the CDN edge, so no SNI–Host mismatch is introduced.

B. Threat Model

C. Attack Overview

We formalize the threat model in terms of attacker capabilities, attacker limitations, and environmental assumptions. Attacker capabilities. The attacker controls a client application on the endpoint and a destination domain Dmalicious hosted on a shared CDN edge. The attacker can select an allowed domain Dallowed that resolves to a shared edge address IPcdn , can issue DNS queries through the endpoint’s trusted resolver, and can craft the TLS ClientHello (including the SNI field and, where supported, the ECH extension) and the HTTP Host header. Attacker limitations. The attacker cannot modify Pdns , Pfw , Pdpi , or Ccdn , cannot alter the DNS response returned by the trusted resolver, cannot obtain the CDN edge private key, and cannot register Dallowed on the CDN control plane. The attacker therefore reaches Dmalicious through ordinary CDN tenant routing rather than through infrastructure compromise. Assumptions. The DNS-governed modes (Simple, Split, and ECH) rely on the following conditions: A1. The trusted DNS service resolves Dallowed to a shared edge address IPcdn that also serves Dmalicious . A2. Pfw grants outbound permission at the address level and does not bind this permission to the domain associated with the DNS response.

Direct IP Mode does not assume A1 and does not reuse the DNS-derived address permission of A2. It applies when the endpoint is not required to resolve destinations through a local protective DNS service, and it therefore characterizes the boundary case in which trusted DNS usage is not enforced. The four modes share the domain-decoupling principle but differ in which of the above conditions they assume.

The core DDA workflow is represented as (Dallowed , IPcdn , Dmalicious , Dmalicious ).

(5)

The client submits Dallowed to the trusted DNS service and receives the shared edge address IPcdn . The DNS decision causes Pfw to permit outbound communication with this address. The client subsequently connects to the same authorized address but presents Dmalicious in both TLS SNI and HTTP Host. Each component observes only part of the complete communication state. The policy Pdns observes and approves Dallowed , while Pfw verifies whether IPcdn appears in the allowed address set. The CDN routing component Ccdn receives the connection-level domain identity and selects the corresponding tenant. No individual component necessarily verifies whether the domain used during the connection matches the domain that originally authorizes the shared address. This separation distinguishes DDA from conventional domain fronting. Domain fronting introduces inconsistent identities within one HTTPS connection because TLS SNI and HTTP Host refer to different domains. DDA instead maintains SN I = Host = Dmalicious

(6)

while allowing Dreq ̸= SN I.

(7)

The domain difference therefore appears between the DNS and connection stages rather than between the TLS and HTTP. D. Simple Mode Simple Mode targets environments that deploy Pdns and Pfw without an application-layer inspection policy Pdpi . The attack communication follows Lsimple = (Dallowed , IPcdn , Dmalicious , Dmalicious ).

(8)

The client first resolves Dallowed through the protective DNS service. The returned IPcdn belongs to a shared CDN edge node and receives outbound permission from the firewall or ZTDNS policy. The client then establishes a TLS connection with the authorized address and places Dmalicious in the SNI field. The subsequent HTTP request uses the same domain in the Host field. The firewall approves the connection because its destination remains IPcdn . The CDN accepts the connection-level domain identity when Dmalicious represents a valid tenant hosted on the shared infrastructure. Its edge-routing logic then forwards the request to the corresponding service. The connection does not expose an SNI–Host mismatch, and the DNS filtering policy does not observe the domain used after connection establishment. Simple Mode directly demonstrates the validation gap identified in the introduction. The DNS policy approves a domain, while the firewall grants permission to a shared address that represents multiple domains. The attack reuses this addresslevel permission without modifying the CDN configuration or exploiting insufficient domain ownership verification. E. Split Mode Split Mode considers environments that deploy both DNSbased control and application-layer traffic inspection. The mode targets implementations in which the inspection engine maintains session state for an initial connection and applies reduced inspection to closely related follow-on traffic. Its applicability therefore depends on the state-management and performance policies of the deployed inspection system. The attack establishes two connections within a short interval ∆t. The first connection follows C1 = (Dallowed , IPcdn , Dallowed , Dallowed ).

(9)

All identities in C1 remain consistent. The protective DNS service approves Dallowed , the firewall permits IPcdn , and the inspection engine observes an allowed SNI. This connection establishes a trusted communication context for the shared destination address. The second connection follows C2 = (Dallowed , IPcdn , Dmalicious , Dmalicious ).

(10)

The client retains the same authorized CDN address but replaces the connection-level identity with Dmalicious . The

TLS SNI and HTTP Host remain consistent during C2 . When the inspection implementation reuses the trusted state associated with the destination or reduces analysis of subsequent connections, the second connection can avoid an independent domain decision. Split Mode extends the core DDA principle into the temporal dimension. Simple Mode exploits the separation among protocol layers and security components, whereas Split Mode additionally examines whether trusted state created by one connection affects the inspection of another connection. The mode does not require an SNI–Host inconsistency, domain ownership verification weakness, or CDN routing rewrite. F. ECH Mode ECH Mode considers CDN environments that support Encrypted Client Hello. The communication state is represented as Lech = Dallowed , IPcdn , OuterSN Iallowed ,
{InnerSN Imalicious }Enc .

(11)

The client resolves Dallowed and obtains the shared CDN address IPcdn . The trusted DNS result grants outbound permission to this address. During the TLS handshake, the client places an allowed public name in the outer ClientHello and encrypts Dmalicious inside the ECH extension. The CDN edge node decrypts the inner ClientHello and uses the inner domain identity during tenant selection. A network inspection component without access to the CDN private key can observe the outer name but cannot recover the encrypted inner SNI. The visible identity remains associated with the allowed CDN service, while the CDN processes the hidden identity after ECH decryption. The subsequent HTTP Host identifies the same hidden tenant selected through the inner ClientHello. ECH Mode preserves the central DDA separation between externally authorized communication and CDN tenant routing. The encryption of the inner domain further limits the visibility available to Pdpi . This mode does not depend on a visible mismatch between TLS SNI and HTTP Host because the effective connection-level identities remain aligned after ECH processing. G. Direct IP Mode Unlike Simple, Split, and ECH Mode, Direct IP Mode does not rely on a DNS-derived address permission and is therefore a boundary extension of the shared-infrastructure threat rather than a fourth DNS-governed DDA mode. It characterizes environments that do not require clients to resolve destinations through a local protective DNS service. Its communication state follows Ldirect = (N U LL, IPcdn , Dmalicious , Dmalicious ).

(12)

The client stores a known CDN edge address and establishes a TCP connection without issuing a local DNS request. The TLS SNI and HTTP Host identify Dmalicious , while the destination remains a public CDN address shared by many

legitimate services. A firewall that relies primarily on static IP threat intelligence observes only the shared CDN address at the network layer [23]. The broad legitimate use of CDN address ranges limits the effectiveness of address-level blocking in this setting. The absence of a DNS request also removes the malicious domain from local DNS-resolution records. Direct IP Mode therefore illustrates the security boundary of deployments that rely on IP reputation without enforcing trusted DNS resolution. It does not provide the DNS-derived permission used in Simple Mode, Split Mode, or ECH Mode. H. Relationship to Existing CDN Evasion Techniques DDA addresses the limitations identified for previous CDNbased evasion techniques. Domain fronting requires SN I ̸= Host,

(13)

which exposes a cross-layer inconsistency that modern CDN providers can detect. DDA instead preserves SN I = Host

(14)

and moves the domain difference to the DNS and connection stages. Domain borrowing depends on insufficient domain ownership verification during CDN deployment. DDA does not require the attacker to register an unowned high-reputation domain in the CDN control plane. Domain shadowing depends on provider-supported rules that rewrite a visible frontend domain to another backend destination. DDA reaches the hidden tenant through ordinary CDN routing on a shared edge address and does not require an internal domain rewrite. The four modes apply the same domain-decoupling principle under different network-control conditions. Simple Mode targets DNS and IP-level enforcement without applicationlayer inspection. Split Mode considers session-state behavior in environments that also inspect TLS identities. ECH Mode limits inspection visibility through encrypted ClientHello processing. Direct IP Mode describes the boundary case in which trusted DNS usage is not enforced. Across the DNS-governed modes, DDA reuses a shared address authorized through one domain while preserving consistent connection-level identities for another domain. III. E VALUATION A. Measurement Setup 1) Dataset and Environment: We construct the measurement dataset from the Tranco [24] Top 1M list. The measurement covers all domains in the list and performs a detailed subdomain analysis for the top 3,000 domains. After deduplication and filtering out inaccessible domains, the dataset contains 1,069,048 unique domain records, including 875,958 apex domains, 2,447 parent domains associated with the collected subdomains, and 190,643 subdomains. We conduct a breadth scan over the Tranco Top 1M apex domains and a depth scan over the top 3,000 domains and their collected subdomains. We conduct all measurements on a cloud server running Ubuntu

24.04. The server is equipped with two ARM Neoverse-N1 CPU cores and 12 GB of memory. 2) Defense Setup: We evaluate DDA against network inspection and DNS-bound access control in a controlled laboratory. The inspection stack includes Zeek [25], [26], Suricata [27] in both IDS and inline-IPS deployments, OPNsense [28], and pfSense [29]. We use Windows ZTDNS as the representative DNS-bound access-control mechanism. An allowed domain Dallowed and a blocked domain Dmalicious share the same CDN edge IP throughout the experiments. The evaluation covers Simple Mode and ECH Mode. Split Mode uses the same connection-level identity as Simple Mode but introduces a timing condition that depends on the sessionstate policy of the inspection system. Direct IP Mode is excluded because it represents the boundary case in which trusted DNS resolution is not involved. 3) Measurement procedure: We implement the measurement with a two-phase scanner. Phase 1 resolves each domain and its collected subdomains over DoH and groups domains according to their returned IP addresses. Domains that share an IP address form candidate cross-tenant paths. Phase 2 probes each candidate domain–IP pair with a TLS handshake whose SNI identifies another domain served through the same address. The scanner then sends an HTTP request and compares the response with the public baseline of the probe domain. We calculate content similarity with SimHash [30] and use 0.90 as the similarity threshold. 4) Exposure classification: We classify each probe into four exposure levels. HIGH indicates that the endpoint accepts the TLS handshake and returns HTTP content that matches the probe-domain baseline. MEDIUM indicates that TLS succeeds and an HTTP response is returned without a baseline match. LOW indicates that TLS succeeds without HTTP verification. NONE indicates that the endpoint rejects the TLS handshake. We regard HIGH, MEDIUM, and LOW results as exposed because all three categories accept an external SNI during TLS establishment. 5) Probe sources: The scanner selects probe domains from CDN provider domains, same-IP co-tenant domains, and a built-in fallback for isolated IPs. The fallback mechanism uses the same provider-domain set as the CDN provider source. The measurement produces 18,025,068 successful probes. Among them, 14,354,459 probes, or 79.6%, use CDN provider domains, while 3,670,609 probes, or 20.4%, use same-IP cotenant domains. The measurement results therefore include independent probe sources rather than relying exclusively on one domain category. B. Evaluation against Network Defenses 1) Network inspection: In Simple Mode, the connection presents Dmalicious in the cleartext SNI. Zeek records the malicious SNI, while Suricata in IDS mode generates a corresponding alert. Suricata in inline-IPS mode can further block Dmalicious without affecting Dallowed because the two domains remain distinguishable at the SNI level. However, this selectivity does not extend to IP-based controls. Since

C. Attack Effectiveness 1) CDN and Non-CDN Environments: Figure 3 presents the overall exposure results. Among the 1,069,048 measured domains, 1,024,540 domains accept a TLS handshake carrying an external SNI, which corresponds to an exposure rate of 95.8%. Moreover, 904,789 domains, or 84.6% of all measured domains, reach the HIGH level and return content that matches the probe-domain baseline. Only 44,508 domains reject the

TABLE I L ABORATORY OUTCOME BY DEFENSE AND DDA MODE . A IS Dallowed AND B IS Dmalicious , SHARING ONE EDGE IP.

Defense Zeek Suricata (IDS) Suricata (IPS) OPNsense pfSense

Simple Mode logs B’s SNI

ECH Mode outer name only

alerts on B’s SNI

no inner SNI alert

drops B (A intact) IP-only, non-selective IP-only, non-selective direct B blocked; reused after A

ZTDNS

Proportion of domains (%)

both domains share the same edge address, OPNsense and pfSense treat them as the same destination when applying IPand port-based policies. Blocking the edge address therefore affects both tenants. ECH Mode removes the visible connection-level identity from the inspection path. Zeek and Suricata observe only the outer public name and the destination IP, so rules targeting the inner SNI no longer match Dmalicious . The remaining observable signals are the shared edge address and ECH extension 65037. A rule based on either signal cannot selectively block the malicious tenant without also affecting legitimate traffic to Dallowed . Structural parsing can identify the presence of ECH, but it neither reveals the encrypted inner domain nor confirms that the ECH handshake succeeds. Our controlled ECH deployment successfully negotiates ECH and reaches Dmalicious after the shared edge address receives permission. 2) DNS-bound access control: Windows ZTDNS blocks a direct connection to Dmalicious , as recorded by BlockedConnections Event ID 2. However, after the client resolves Dallowed , ZTDNS grants a dynamic permit to the returned shared edge address. A subsequent ordinary-TLS connection to the same address presents Dmalicious in the SNI and successfully retrieves its content. This result shows that the permission derived from Dallowed can be reused by another tenant on the same edge address. The same permission reuse occurs in ECH Mode. After obtaining a valid ECHConfig for Dmalicious and resolving Dallowed , a Windows-native ECH client completes the connection with ech_accepted=true and retrieves the content of Dmalicious . ECH is not required for the bypass because ordinary TLS already reuses the shared-IP permission. Its role is to hide the connection-level domain from network inspection. External DoH alone does not grant permission to the address of Dmalicious . Once Dallowed permits the shared edge address, however, the external-DoH and ECH path reaches Dmalicious while concealing both the DNS query content and the inner SNI. DoH therefore strengthens traffic concealment but does not create the underlying bypass. These results reveal a structural limitation of DNS-bound access control. A domain-level DNS decision becomes an address-level permission, but the permitted address may represent multiple independent tenants. The control therefore cannot preserve the original domain binding when a later connection selects another tenant behind the same shared address. Table I summarizes the outcomes for each defense mechanism and DDA mode.

SNI misses; IP/65037 hits both IP-only, non-selective IP-only, non-selective reused after A (confirmed)

100 84.64%

80 60 40 20 0

10.74%

4.16%

0.46%

High

Medium

Low

None

Fig. 3. Exposure by vulnerability level.

external SNI. These results show that external SNI acceptance is widespread and that most accepted connections reach the intended tenant rather than terminating at a generic edge response. The comparison between CDN and non-CDN domains reveals a clear difference in attack effectiveness. DDA exposes 99.26% of the 506,763 CDN domains and 92.75% of the 562,285 non-CDN domains, which represents a difference of 6.51 percentage points. The higher exposure rate among CDN domains is consistent with their use of shared edge nodes that perform TLS termination for multiple tenants. However, the exposure rate among non-CDN domains also exceeds 90%, which indicates that DDA is not restricted to conventional CDN deployments. Figure 4 further compares the results across eleven CDN providers. Ten providers exhibit exposure rates above 90%. Cloudflare reaches 99.72% across 385,145 domains, AWS CloudFront reaches 99.14% across 49,880 domains, and Azure CDN reaches 99.05% across 6,664 domains. In contrast, Alibaba CDN records an exposure rate of 76.52%. This variation suggests that provider-specific connection and tenant-routing policies affect the feasibility of DDA, although the attack remains effective across most measured CDN infrastructures. Overall, DDA achieves high exposure rates in both CDN and non-CDN environments. Shared CDN infrastructure increases the attack success rate, but the results from nonCDN domains show that the underlying validation gap extends beyond a single infrastructure type.

100

Cloudflare

Exposure rate (%)

AWS CloudFront Fastly Akamai Google Cloud CDN Azure CDN Alibaba CDN Tencent CDN BunnyCDN CDN77 KeyCDN 0

20

40 60 Exposure rate (%)

80

94.0% 96.5%

95.8% 95.5%

99.1%

85.8%

80 60 40 20

100

0

NA

EU

AS

SA

OC

AF

Fig. 4. Exposure rate by CDN provider. Fig. 6. Exposure rate by continent. 52,811

54,069

50000

IPs

40000

30000

20000

10000 3,336

0 L1 intra-tenant (exploitable)

L2 cross-tenant (exploitable)

L2 cross-tenant (all)

US RU DE JP NL CA CN FR SG GB IE IN KR BR MD PL CZ IT ES AU

50.4% 6.3% 5.8% 5.2% 4.6% 3.3% 2.8% 2.8% 2.1% 1.6% 1.2% 1.1% 0.9% 0.9% 0.7% 0.6% 0.6% 0.5% 0.5% 0.5%

0

100000

200000 300000 400000 Exposed domain-IP pairs

500000

600000

Fig. 5. Non-CDN same-IP multi-tenancy and exploitable cross-tenant IPs. Fig. 7. Top-20 countries by exposed domain–IP pair count.

2) Geographic Distribution: We map each edge IP to its country and continent using GeoLite2 [31], which reflects approximate registration geography rather than resolution geography. Exposure is high on every continent (Fig. 6), Africa 99.07%, Oceania 96.48%, North America 95.77%, Europe 95.50%, South America 93.98%, and Asia 85.80%; Asia is the lowest because a larger share of its domains sit on origin or non-CDN hosting. By exposed domain–IP pair count (Fig. 7), the United States dominates with 571,334 pairs, followed by Russia, Germany, Japan, the Netherlands, Canada, France, Singapore, China (31,815, with Hong Kong, Taiwan, and Macao merged), and the United Kingdom. The concentration tracks the geographic distribution of CDN edge infrastructure rather than any single region’s policy. 3) Large-Scale Measurement on the Tranco Top 1M: The 1,024,540 exposed domains resolve to 520,340 unique IP addresses, but their distribution across these addresses is highly skewed. The busiest edge IP hosts 16,985 exposed domains, while the twenty busiest IP addresses host an average of 3,541 exposed domains, as shown in Fig. 8. These results show that a substantial number of exposed domains concentrate on a small set of shared addresses. Exposure decreases with DNS depth (97.90% for apex domains, 92.15% for subdomain parents, and 86.42% for subdomains), as subdomains more often sit on origin servers rather than shared edges, as shown in Fig. 9.

D. Extended Co-location Chain Attack We represent same-IP co-location as a graph in which domains are connected when they share an IP address. Among the exposed domains, 758,232 belong to 81,466 connected components with more than one domain. The largest component contains 77,991 domains, while 666,413 domains belong to components that span multiple organizations, as shown in Fig. 10. This component structure supports a co-location chain attack. An authoritative domain A resolves to a shared edge IP and causes the address to receive network permission. The attacker then connects to the same address while presenting another tenant B as the connection-level identity. The edge consequently routes the connection to B rather than binding it to the domain approved during DNS resolution. Our probes confirm these cross-tenant paths by retrieving the content of B when its SNI is presented to an edge IP obtained through A. Several unrelated organizations share the same edge IP, which allows the address obtained through one authoritative tenant to provide a path to the remaining tenants in the component. Concretely, if the victim network’s DNS-bound control whitelists an allowed domain A and the attacker hosts a malicious domain C on the same edge address, the endpoint resolves A to obtain the address permit and then connects to that address while presenting C in both the TLS SNI and the

Mean (top-20) = 3,541

105

IP #1 IP #2 IP #3 IP #4 IP #5 IP #6 IP #7 IP #8 IP #9 IP #10 IP #11 IP #12 IP #13 IP #14 IP #15 IP #16 IP #17 IP #18 IP #19 IP #20

Domains in component (log)

20,174

104

2000

4000

6000 8000 10000 12000 Exposed domains on IP

14000

16000

Fig. 8. Top-20 edge IPs by exposed-domain count (anonymized). 97.9%

100

92.2%

86.4%

80 60 40 20 0

in Ma

ma do

ins

bd Su

a om

i

a np

ts re n

b Su

ma do

ins

Fig. 9. Exposure rate by DNS depth.

HTTP Host, so the channel between the endpoint and C is recorded as communication with A. The permission does not stop at one domain pair: because the permit covers the shared address rather than a single tenant, and co-location is transitive over shared IPs, one approved domain reaches every tenant in its connected component. A few allowlist entries can therefore cover a much larger reachable set, and the chain spans multiple hops as each additionally approved intermediate tenant extends the permitted address set one step further. For a defender, the effective reachable surface of a DNS-bound allowlist is the union of the connected components of its entries. The same structure also appears outside conventional CDN deployments. Among 58,854 non-CDN IP addresses that host multiple domains, 54,069 serve domains associated with different organizations. DDA successfully exploits 52,811 of these cross-tenant IP addresses, corresponding to 97.7%, and covers 330,369 exposed domains, as shown in Fig. 5. The colocation chain is therefore not limited to CDN infrastructure and also applies to cross-tenant shared hosting. E. Attack Overhead Overhead. DDA adds no protocol step or new channel to the communication path. The client performs an ordinary DNS resolution and a standard TLS handshake, and the only

4,5104,284 3,7973,509 3,035 2,471 1,8601,8281,8251,728 1,5421,5211,3221,278 1,2421,192 1,021 971

103

102

101

100

0

Exposure rate (%)

77,991

0.0

2.5

5.0

7.5 10.0 12.5 Component rank (largest →)

15.0

17.5

20.0

Fig. 10. Connected-component sizes of the same-IP co-location graph.

difference from normal traffic is that the domain presented during the connection differs from the domain approved during the DNS stage. It therefore costs nothing beyond a normal HTTPS connection. Impact scope. The measurement quantifies how often this gap is exploitable on the current Internet: 95.8% of the 1,069,048 measured domains accept a TLS connection carrying another tenant’s SNI, and 84.6% route the connection to that tenant’s content. The effect is not confined to a single provider or infrastructure type: CDN domains reach 99.26%, and non-CDN shared hosting still reaches 92.75%. Because the underlying behavior is ordinary multi-tenant routing, DDA requires no privilege, no certificate, and no modification of the network controls. It needs only an attacker-controlled client and a destination co-located on a shared edge. Extended attack. The co-location chain amplifies the danger. Because the tenants that share an edge form connected components, a single authoritative domain on the edge serves as cover for every other tenant in its component, so the attacker does not need to pair each target with a dedicated cover. Our measurement finds 666,413 exposed domains in components spanning multiple organizations, with the largest component containing 77,991 domains, and 97.7% of non-CDN crosstenant IPs exploitable. At every hop of the chain, the DNS query and the address-level permission carry a legitimate authoritative name, while the connection-level identity selects the actual tenant. Abuse scenarios. Two abuse scenarios motivate defensive attention. First, the APT attacker can use DDA to conceal C2 and data-exfiltration traffic: a compromised endpoint appears, at the DNS and permission layers, to communicate only with an allowed domain, and with ECH the connection-level identity is hidden from inspection as well. Second, the same mechanism provides censorship circumvention, because the externally visible identities remain those of allowed domains on shared infrastructure. Neither scenario introduces traffic patterns that existing detectors match. We therefore caution that DNS-bound access controls alone cannot protect sharedinfrastructure deployments. Defenders should bind connectiontime identity to the approved domain and treat address-level reuse on shared edges as a security property rather than an

implementation detail. IV. T HREATS TO VALIDITY Exposure-classification validity. The primary exposure claim rests on TLS acceptance alone and is independent of the SimHash threshold, which only separates HIGH from MEDIUM. MEDIUM and LOW are reported separately and never promoted to HIGH. Measurement-configuration validity. Exposure is determined by the edge’s tenant-routing configuration rather than by the probe’s location, and the two independent probe sources (CDN-provider and same-IP co-tenant) yield consistent rates. GeoLite2 labels describe registration geography only, not precise resolution geographies. Attack-deployment validity. A real deployment additionally requires the attacker to control a destination co-located on the target edge. The measurement quantifies exactly the reachability such a destination would enjoy. The co-location chain relaxes this pairing, as one authoritative cover domain extends to every tenant in its component. Acquiring a tenant is ordinary CDN onboarding and is orthogonal to the validation gap. Defensive-evaluation validity. The defensive experiments run in a controlled laboratory on private addresses. The inspection stack observes two attacker-controlled domains that share one CDN edge IP. The stack is representative but not exhaustive. Because ZTDNS grants its permit at the address level on a shared edge, the bypass is structural and transfers to any DNS-bound control that admits resolver-returned addresses. V. R ELATED W ORK A. CDN-Based Traffic Evasion Domain fronting exposes a high-reputation domain in DNS and TLS SNI while directing the encrypted HTTP Host header to another destination, provider-side SNI–Host consistency checks were designed to restrict it, yet a measurement of 30 CDNs found 22 still permitted some form of it [4], [9]. Domain borrowing instead presents another domain consistently as both SNI and Host, relying on gaps in domain ownership verification [14], domain shadowing relies on CDN-internal frontto-backend mapping [7], and domain hiding used early ESNI with a visible outer name, a historical behavior not equivalent to standardized ECH [32]. IP-level blocking of shared edges also causes collateral impact on benign domains [33]. These techniques place the domain difference within the connection or depend on provider-specific weaknesses, indicating that the domain observed by DNS, the connection identity, and the shared edge address are not a fixed one-to-one correspondence. B. Shared-Edge Infrastructure and Network Measurement Shared addressing is a basic deployment model for CDNs and virtual hosting, in which one address hosts many domains and TLS SNI with the HTTP authority select the service [17], measurements such as Satellite have characterized the resulting many-to-many relationship between domains, addresses, and services [20], [34]. Protective DNS enforces policy at

resolution time, and Windows ZTDNS blocks outbound IP traffic by default and admits addresses returned by a trusted DNS service [15]: the object actually enforced is the IP, so when that address belongs to a shared edge, the domain-level decision and the address-level permission operate at different granularities. Prior measurement work has paid limited attention to whether this DNS-derived permission remains bound to the originally approved domain. C. Encrypted Domain and Connection Metadata DoH hides query names from on-path observers [35] and ECH encrypts the server name in the inner ClientHello [36], but neither hides the connection itself, and traffic features may still reveal the target service [37], [38], on a shared IP an address rule applies to many domains simultaneously, and detecting ECH use does not reveal the encrypted inner domain. The joint effect of encrypted domain information, shared edges, and DNS-derived connection permission has not been directly examined. DDA differs from this body of work by placing the domain difference between the DNS stage and the connection stage rather than between the TLS and HTTP layers, and by reusing the address permission granted for an allowed domain without relying on SNI–Host inconsistency, ownership-verification weaknesses, or CDN-internal routing rewrites. VI. C ONCLUSION We presented Domain Decoupling Attack (DDA), which separates the domain approved during DNS resolution from the domain presented during connection establishment while preserving TLS SNI–Host consistency. An internet-scale measurement of 1,069,048 domains found that 95.8% accept a TLS handshake carrying an external SNI, with exposure reaching 99.26% for CDN and 92.75% for non-CDN domains; the co-location chain extends a single authoritative domain to 666,413 exposed domains in components spanning multiple organizations. Our evaluation showed that SNI-aware inspection cannot separate tenants under ECH, and that DNS-bound controls that admit resolver-returned addresses cannot preserve the approved-domain binding on a shared address. Because no observable signal separates the hidden tenant from the allowed one, existing detection mechanisms cannot reliably identify the attack, which enables its abuse for concealing C2 and data-exfiltration traffic and for censorship circumvention. We therefore recommend that defenders bind connection-time identity to the approved domain and treat address-level reuse on shared edges as an explicit design constraint. E THICAL C ONSIDERATIONS The measurement sends only standard TLS handshakes on port 443 followed by a few HTTP requests, all directed at publicly served edge content. It authenticates to no service, delivers no payload, and stays well below a volume that could affect availability. The probed behavior is the intended multi-tenant routing of shared infrastructure rather than a compromise of the edge.

Because this behavior reflects an architectural property rather than a patchable flaw, traditional per-vendor vulnerability disclosure does not map onto a single fix, and we therefore frame the contribution as a measurement, an attack demonstration, and a discussion of mitigation rather than a coordinated disclosure of a specific bug. The experiments run in a controlled laboratory without production traffic. Real IP addresses and domains are anonymized in all figures, and the study involves no human subjects or personal data. R EFERENCES [1] J. Zhang, X. Hu, J. Jang, T. Wang, G. Gu, and M. Stoecklin, “Hunting for invisibility: Characterizing and detecting malicious web infrastructures through server visibility analysis,” in IEEE INFOCOM 2016-The 35th Annual IEEE International Conference on Computer Communications. IEEE, 2016, pp. 1–9. [2] P. Żórawski, L. Caviglione, and W. Mazurczyk, “A long-term perspective of the internet susceptibility to covert channels,” IEEE Communications Magazine, vol. 61, no. 10, pp. 171–177, 2023. [3] B. Anderson and D. McGrew, “Assessing and exploiting domain name misinformation,” in 2023 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). IEEE, 2023, pp. 475–486. [4] D. Fifield, C. Lan, R. Hynes, P. Wegmann, and V. Paxson, “Blockingresistant communication through domain fronting,” Proceedings on Privacy Enhancing Technologies, 2015. [5] D. Sommer, A. Dhar, L. Malisa, E. Mohammadi, D. Ronzani, and S. Capkun, “Deniable upload and download via passive participation,” in 16th USENIX Symposium on Networked Systems Design and Implementation (NSDI 19), 2019, pp. 649–666. [6] M. Yao, J. Fuller, R. P. Kasturi, S. Agarwal, A. K. Sikder, and B. Saltaformaggio, “Hiding in plain sight: An empirical study of web application abuse in malware,” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 6115–6132. [7] M. Wei, “Domain shadowing: Leveraging content delivery networks for robust {Blocking-Resistant} communications,” in 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 3327–3343. [8] R. Wails, R. Jansen, A. Johnson, and M. Sherr, “Censorship evasion with unidentified protocol generation,” in 34th USENIX Security Symposium (USENIX Security 25), 2025, pp. 763–782. [9] K. Subramani, R. Perdisci, P.-C. Skafidas, and M. Antonakakis, “Discovering and measuring CDNs prone to domain fronting,” in Proceedings of the ACM Web Conference 2024, 2024, pp. 1859–1867. [10] Y. Xie, G. Gou, G. Xiong, Z. Li, and W. Xia, “Domeye: Detecting network covert channel of domain fronting with throughput fluctuation,” Computers & Security, vol. 144, p. 103976, 2024. [11] ——, “Fakeapp: A high-precision method for domain fronting detection in real networks with neuro-symbolic integration,” in 2025 IEEE International Conference on Systems, Man, and Cybernetics (SMC). IEEE, 2025, pp. 5581–5588. [12] Z. Lin, Z. Lin, R. Guo, J. Chen, M. Zhang, X. Liu, T. Yang, Z. Cao, and R. H. Deng, “Detecting and measuring security implications of entangled domain verification in cdn,” arXiv preprint arXiv:2409.01887, 2024. [13] G. H. Cimaszewski, H. Birge-Lee, L. Wang, J. Rexford, and P. Mittal, “How effective is {Multiple-Vantage-Point} domain control validation?” in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 5701–5718. [14] T. Ding and J. Zhou, “Domain borrowing: Catch my c2 traffic if you can,” Black Hat Asia 2021 Briefings, May 2021. [15] Microsoft. (2025) Zero trust dns. Microsoft Learn. [Online]. Available: https://learn.microsoft.com/en-us/windows/security/operatingsystem-security/network-security/zero-trust-dns/ [16] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, “Zero trust architecture,” NIST special publication, vol. 800, no. 207, pp. 1–52, 2020. [17] R. T. Fielding and J. Reschke, “Hypertext transfer protocol (http/1.1): Message syntax and routing,” RFC 7230, 2014. [18] C. A. Shue, A. J. Kalafut, and M. Gupta, “The web is smaller than it seems,” in Proceedings of the 7th ACM SIGCOMM conference on Internet measurement, 2007, pp. 123–128. [19] Cloudflare, “Cloudflare ip addresses,” https://developers.cloudflare.com/fundamentals/concepts/cloudflareip-addresses/, 2026, accessed: July 28, 2026.

[20] W. Scott, T. Anderson, T. Kohno, and A. Krishnamurthy, “Satellite: Joint analysis of {CDNs} and {Network-Level} interference,” in 2016 USENIX Annual Technical Conference (USENIX ATC 16), 2016, pp. 195–208. [21] C. Huitema and E. Rescorla, “Issues and requirements for server name identification (sni) encryption in tls,” RFC 8744, 2020. [22] L. Zheng, X. Li, C. Wang, R. Guo, H. Duan, J. Chen, C. Zhang, and K. Shen, “Reqsminer: Automated discovery of cdn forwarding request inconsistencies and dos attacks with grammar-based fuzzing.” in NDSS, 2024. [23] M. Kührer, C. Rossow, and T. Holz, “Paint it black: Evaluating the effectiveness of malware blacklists,” in International Workshop on Recent Advances in Intrusion Detection. Springer, 2014, pp. 1–21. [24] V. Le Pochat, T. Van Goethem, S. Tajalizadehkhoob, W. Joosen et al., “Tranco: A research-oriented top sites ranking hardened against manipulation,” in Proceedings of the 26th Annual Network and Distributed System Security Symposium. Internet Society, 2019, pp. 1–15. [25] P. V. Bro, “A system for detecting network intruders in real-time,” in Proc. 7th USENIX security symposium, 1998. [26] Zeek Project, “Zeek: The open source network security monitor,” https://github.com/zeek/zeek, 2026, gitHub repository. Accessed: August 1, 2026. [27] Open Information Security Foundation, “Suricata: Network threat detection engine,” https://github.com/OISF/suricata, 2026, gitHub repository. Accessed: August 1, 2026. [28] OPNsense Project, “Opnsense: Open source firewall and routing platform,” https://opnsense.org/, 2026, accessed: August 1, 2026. [29] pfSense Project, “pfsense: Open source firewall and router platform,” https://www.pfsense.org/, 2026, accessed: August 1, 2026. [30] C. Sadowski and G. Levin, “Simhash: Hash-based similarity detection,” Technical report, Google, Tech. Rep., 2007. [31] MaxMind, “Geolite2 free geolocation data,” https://dev.maxmind.com/geoip/geolite2-free-geolocation-data/, 2026, accessed: August 1, 2026. [32] E. Hunstad, “Domain fronting is dead, long live domain fronting: Using tls 1.3 to evade censors, bypass network defenses, and blend in with the noise,” DEF CON 28, Aug. 2020, conference presentation. [33] H. Zolfaghari and A. Houmansadr, “Practical censorship evasion leveraging content delivery networks,” in Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security, 2016, pp. 1715–1726. [34] N. P. Hoang, A. A. Niaki, M. Polychronakis, and P. Gill, “The web is still small after more than a decade,” ACM SIGCOMM Computer Communication Review, vol. 50, no. 2, pp. 24–31, 2020. [35] P. Hoffman and P. McManus, “DNS queries over HTTPS (DoH),” RFC Editor, RFC 8484, Oct. 2018. [Online]. Available: https://www.rfceditor.org/rfc/rfc8484.html [36] E. Rescorla, K. Oku, N. Sullivan, and C. A. Wood, “TLS encrypted client hello,” RFC Editor, RFC 9849, Mar. 2026. [Online]. Available: https://www.rfc-editor.org/rfc/rfc9849.html [37] M. Trevisan, F. Soro, M. Mellia, I. Drago, and R. Morla, “Attacking DoH and ECH: Does server name encryption protect users’ privacy?” ACM Transactions on Internet Technology, vol. 23, no. 1, pp. 1–22, 2023. [38] N. P. Hoang, A. A. Niaki, P. Gill, and M. Polychronakis, “Domain name encryption is not enough: Privacy leakage via ip-based website fingerprinting,” arXiv preprint arXiv:2102.08332, 2021.

Related documents

• DecoyTrace: Toxic Decoys for Active Defense in Decentralized Federated Learning#1131172
• DecoyTrace: Toxic Decoys for Active Defense in Decentralized Federated Learning#1122230
• Be Kind, Rewrite: Benign Projections via Rewriting Defend Against LLM Data Poisoning Attacks#204733
• HOWLR: A Client-Driven Approach to BGP Hijack Detection#299868
• Trojaning the Alignment: Stealthy Backdoor Attacks against Graph Foundation Models#480067