Executive Summary

The ip6.arpa TLD exists for one purpose: reverse DNS lookups. It was never designed to host websites, serve content, or point to IPv4 addresses. That makes it invisible to most security tools - and that is exactly why threat actors have started using it.

In February 2026, Infoblox documented the known exploitation of this blind spot attackers were placing wildcard A records inside ip6.arpa reverse DNS zones, then embedding those zones as URLs in phishing emails. Because ip6.arpa carries no domain reputation, email gateways and URL scanners pass them without inspection.

Upon investigating further we ran a global BGP scan against 127,906 IPv6 prefixes to validate and extend the findings by Infoblox. We confirmed the original campaign is still active and found a second, independent campaign running on completely different infrastructure: a server in Frankfurt, Germany, under a different ASN, with no Cloudflare proxying.

That second zone, 0.d.7.2.7.0.1.b.e.0.a.2.ip6.arpa, resolves to 85.215.34.119. It was active during our scan window, has been live since at least January 29, 2026, and at time of writing remains active with Cloudflare NS records in place.

How the attack works

To understand why threat actors use this technique helps to understand what ip6.arpa is supposed to do. When a mail server receives an email, it often performs a reverse DNS lookup on the sender's IP — querying the ip6.arpa namespace to find the associated hostname. Security tools treat this namespace as infrastructure plumbing, not as a source of malicious URLs.

First, they obtain a free IPv6 /48 prefix from a tunnel provider like Hurricane Electric. This gives them administrative control over the corresponding ip6.arpa reverse DNS zone — a zone that, by RFC design, should only ever contain PTR records mapping addresses back to hostnames.

Instead, they set a wildcard A record: * IN A <malicious-ip>. Now every possible subdomain under that zone resolves to their server. A URL like xqjerorqxs.d.d.e.0.6.3.0.0.0.7.4.0.1.0.0.2.ip6.arpa is technically valid DNS, resolves to a real IP, and looks to automated scanners like a routine PTR query rather than a phishing link.

Each phishing email embeds a different randomly-generated subdomain prefix every recipient gets a unique URL. Because the zone has a wildcard A record, all of them resolve without the attacker registering anything. Bulk blocklists are useless: by the time an analyst extracts and blocks one subdomain, every other victim already received a different one.
‍

Any A record response from an ip6.arpa zone is an RFC violation. There is no legitimate use case. False positive rate: 0%.

Analysis of Observed Infrastructure and Campaigns

In order to investigate further we tested the global IPv6 BGP routing table. In stage one pulled all //48 and more-specific prefixes from BGP.tools 127,906 in total and converted each to its corresponding ip6.arpa nibble zone, and checked for Cloudflare nameservers. A Cloudflare NS on an ip6.arpa zone is the staging signal: the attacker has delegated the zone, ready to add A records when a campaign launches.

Stage one returned 384 zones with Cloudflare NS. Stage two fired 100 randomly-generated subdomain probes at each of those zones. A wildcard A record response confirmed a zone as actively malicious.

Out of 127,906 zones tested: 384 suspicious, 2 confirmed malicious.

The first hit was the zone documented by Infoblox: d.d.e.0.6.3.0.0.0.7.4.0.1.0.0.2.ip6.arpa, corresponding to the Hurricane Electric IPv6 prefix 2001:470:63d::/48. It was active during our scan, with 100 out of 100 subdomain probes returning A records for the Cloudflare edge IPs 104.21.3.194 and 172.67.131.33.

This zone has been intermittently active and dormant across multiple scan runs on March 12, 2026, which is consistent with campaign-based activation  the attacker turns the wildcard on when sending phishing emails and off between campaigns, making passive monitoring unreliable.

The second hit was not in the Infoblox report. Zone 0.d.7.2.7.0.1.b.e.0.a.2.ip6.arpa corresponds to the IPv6 prefix 2a0e:b107:27d0::/48 and resolves to 85.215.34.119 — a single non-Cloudflare IP in Frankfurt, Germany, hosted on IONOS SE infrastructure.

Unlike Campaign A, this zone does not use Cloudflare as a proxy. The origin server IP is directly exposed. Currently the server stack is nginx + Plesk on a managed server.

Findings

The structural similarity between Campaign A and Campaign B strongly  confirm technique reuse. Both use the same wildcard A records accepting arbitrary subdomain prefixes, both use Cloudflare NS for zone delegation, and both were active on the same day.

Both confirmed malicious zones represent 2 out of 384 that passed Stage 1 of our scan. The remaining 382 have Cloudflare NS records on ip6.arpa zones but no active A records. They are staged.

This is the more significant finding from a defensive standpoint. An attacker does not need to register a domain or configure a server on the day they launch a campaign. They can stage the infrastructure weeks

in advance, delegate the zone, point it at Cloudflare, and wait. When they are ready to send phishing emails, they add the wildcard A record. The campaign is live within seconds. When they are done, they remove it. The zone goes quiet again, but it remains armed.

Monitoring these 382 zones for A record activation is directly actionable. Any organisation running DNS monitoring can alert on A record responses from any *.ip6.arpa zone. Any of those 382 zones activating is a zero-false-positive signal that a campaign has launched.

Note: As of 2026-03-12, the wildcard A record on 0.d.7.2.7.0.1.b.e.0.a.2.ip6.arpa remains active and resolving to 85.215.34.119. The DNS infrastructure for Campaign B is fully operational. However, no phishing email, TDS redirect chain, or phishing landing page directly linked to this zone has been observed by our team. Active probes of 85.215.34.119 returned a Plesk default page. This does not rule out a TDS-gated or referrer-filtered landing page that would only activate via the correct attack chain. The malicious intent is confirmed by DNS,  a wildcard A record on ip6.arpa has no legitimate use case under any RFC but downstream victim-facing infrastructure has not been directly observed.

Impact

• Evasion of Traditional Defenses: Attackers can successfully bypass reputation-based email gateways and URL scanners because the ip6.arpa namespace is universally treated by security tools as benign infrastructure plumbing rather than a host for malicious content.
• Complete Ineffectiveness of Blocklists: By placing wildcard A records (* IN A) in their delegated IPv6 zones, threat actors can generate a unique, randomized subdomain for every single targeted victim. By the time an analyst identifies and blocks one malicious URL, the list is already obsolete.
• Silent Pre-Staging of Attack Infrastructure: Threat actors are arming infrastructure weeks in advance by delegating zones to commercial CDNs (like Cloudflare) and leaving them dormant.

Recommendations

• Implement Strict DNS Anomaly Blocking: Configure Response Policy Zones (RPZ) and DNS monitors to block and alert on any A or AAAA record responses for .arpa domains. By RFC design, ip6.arpa zones should only return PTR records. Any A record resolution in this namespace is an explicit RFC violation.
• Enhance Email Gateway URL Extraction & Regex: Update email security gateways to aggressively extract and inspect hyperlinks hidden within image tags (a common evasion tactic for this campaign). Apply custom regex rules (e.g., [\w]{6,}\.([\da-f]\.){8,}ip6\.arpa) to identify and block DGA-pattern subdomains prepended to reverse DNS strings.
• Monitor for Abnormal Zone Delegations (Staged Infrastructure): Actively monitor DNS telemetry for delegated .arpa zones that resolve through commercial CDN nameservers (e.g., Cloudflare NS). This is operationally abnormal and provides an early-warning signal, allowing defenders to track and block staged infrastructure before the wildcard A records are activated.
• Apply Heuristics to Lures and Network Paths: Adjust email filtering heuristics to flag messages where the only clickable content is an image with no visible URL text, as this highly correlates with this attack style. Additionally, treat incoming mail relayed through known free IPv6 tunnel provider netblocks as a risk signal.

Conclusion

The ip6.arpa abuse technique documented by Infoblox in February 2026 is not an isolated campaign. Our independent global scan found it actively in use with suggesting independent campaigns.

The 382 staged zones we found are the most operationally significant finding. They are not historical artefacts but can be rather treated as loaded weapons. An attacker who has already done the work of delegating a zone to Cloudflare NS can launch a campaign with a single DNS record change, faster than any blocklist can respond.

Indicators of Compromise