Given the reserved nature of the .arpa TLD, we wouldn’t expect it to be as easy as entering the domain in a web form. When we evaluated a few DNS providers to check if they were vulnerable, this was the point in the process that was ultimately the determining factor. If the provider prevented us from claiming ownership of a .arpa domain, either by explicitly denying the request or by the request failing, we considered the DNS provider not vulnerable.
...so, why would you ever call that a vulnerability in the DNS provider? Why shouldn't I be able to host my reverse DNS zone on a "normal" DNS provider? And if I want to add an A record there... why do you care? How does that affcet you?
The abuse of the .arpa TLD is novel in that it weaponizes infrastructure that is implicitly trusted and essential for network operations.
I also don't really get how it's "implicitly trusted". If you have some weird security system that implicitly trusts .arpa domains... good job, I guess?
This would also be really easy to deal with. The odds of a legitimate website (that's of interest to non-tech people) being hosted on .arpa are around 0, so if you're concerned about phishing you could mark all of them as suspicious or something. But why break DNS providers?
I'm in a bit of unique position here. I was heavily involved in anti-spam work for a while. I also worked at Inboblox for a bit, where I worked on their DNS/DHCP server, sat next to Cricket Liu, and attended some of the meetings of the root name server operators. I'm also one of the few people who have officially allocated something within the .arpa domain: eap.arpa. That domain is used for 802.1X network access, such as with unauthenticated EAP-TLS.
Let's start with .arpa domains in email messages. There are very, very, few reasons to reference a .arpa domain in an email message. There are some legitimate uses, such as discussing reverse addresses, etc. But I can't think of many legitimate reasons to put a .arpa address in as the target of an href. That alone should raise all kinds of red flags, and hit major signals for being spam.
Another consideration is the special nature of the .arpa domain. The IANA page says
The .arpa domain is the “Address and Routing Parameter Area” domain
and is designated to be used exclusively for Internet-infrastructure
purposes.
What this means in theory is that the content of .arpa is extremely restricted. At least, so far as standards go. In practice, .arpa is just another domain in DNS, and you can put pretty much whatever you want there.
This difference between theory and practice creates vectors for all kinds of attacks. People expect .arpa domains to contain only a few types of resource records, but DNS resolvers don't actually enforce any of those restrictions. Even worse, DNS resolvers are explicitly required to not enforce much of anything on the data they transport. If they did enforce rules for things they knew about, then it would be very difficult to add anything to DNS.
But your personal DNS resolver is free to enforce all kinds of things that you know about. This realization opens up the possibility for you (or your DNS server) to filter out all kinds of things that you know you will never use.
Addressing some of the comments below:
why would you ever call that a vulnerability in the DNS provider? Why shouldn't I be able to host my reverse DNS zone on a "normal" DNS provider?
Because it's not your reverse zone. The .arpa domain is owned by IANA. IANA allows certain uses of .arpa, one of which is allowing people to use subdomains in specific ways without prior notification to IANA.
The issue here is that domains within .arpa are different from domains within the rest of the DNS hierarchy. If you want to host foo.example.com on a public DNS server somewhere, then you also have to own example.com. (To be technical, if you didn't own example.com. you could perhaps list foo.example.com on a DNS server somewhere, but people looking it up would find example.com, who would then never point to you.)
There's no such hierarchy for in-addr.arpa. If you own 192.168.1.2, you don't get assigned that address from the 192/8 people. So you can arguably put pretty much anything into a reverse zone, and no one will ever notice.
To put it another way, whoever owns a block of IP addresses also officially owns that (reverse) subdomain within the in-addr.arpa domain. That ownership isn't really enforced much of anywhere, which opens the system up to various attacks.
This is a strong argument for having DNS providers put strong limitations on what they allow to be done with reverse zones in .arpa. If you're not a network provider, you arguably shouldn't be publishing anything within the in-addr.arpa domain.
I used in-addr.arpa and ip6.arpa zones to host mirrors of my personal site just for fun because it looks cool (serving http on my side and use Cloudflare ACM to get SSL.com certs for the .arpa zones, then proxy traffic thru Cloudflare). But it stopped working since (maybe) a week ago.
Because you don't own those domains. While certificates can contain domain names, the certification authorities were not enforcing the DNS rules for domain names in certs. This opens up the system for cross-protocol attacks.
The CA/B forum has apparently decided to enforce some of the official DNS rules. But they're still open to more attacks:
Effective 2026-03-15, the entry MUST NOT contain a Domain Name that ends in an IP Address Reverse Zone Suffix.
OK, that's nice. What about the other zones within .arpa? e.g.
home.arpa For non-unique use in residential home networks RFC 8375
It seems that you can get a legitimate cert for home.arpa, even though you don't actually own that domain. You only have the right to use it within the physical boundaries of your home.
There are more reserved domains than just .arpa. list. ICANN and IANA have also reserved .internal, which is for internal use within organizations, much like reverse zones.
I can't find anything on the CA/B site which limits certificate issuance for these other domains. Sadly, this means that these attacks will continue.
There's no such hierarchy for in-addr.arpa. If you own 192.168.1.2, you don't get assigned that address from the 192/8 people.
Huh? There absolutely is a hierarchy, though it is complicated and tangled due to address transfers. (I guess you are using 192.168/16 as an example because as a concrete instance it’s a misleading special case.)
Before they were used up, IANA allocated /8 chunks to RIRs, which allocated sub-chunks to LIRs (aka ISPs) which in turn suballocated to their customers. You can trace this path through whois or RDAP referrals, and the reverse DNS delegations should correspond to the IP address allocations.
But IP addresses can be transferred between LIRs in different regions, so the /8 chunks are fragmented across RIRs. (This has long been the case for the old pre-RIR pre-CIDR class B allocations.) IANA delegates the reverse DNS for each /8 to an RIR, and there’s a somewhat shonky mechanism for the other RIRs to send to the /8 zone owner reverse DNS zone fragments for transferred IP address ranges.
(I think they should use classless reverse DNS delegation, but DNAME still scares people even though it works pretty well for this purpose.)
To put it another way, whoever owns a block of IP addresses also officially owns that (reverse) subdomain within the in-addr.arpa domain. That ownership isn't really enforced much of anywhere, which opens the system up to various attacks.
The ownership is implemented in the RIR databases. When an LIR is allocated a block of addresses, that is recorded in the RIR database. The LIR has access to the database to manage the allocation’s whois records and reverse DNS delegation, and they are supposed to ensure that this metadata is correctly set up.
But yes in practice ISPs vary a lot in how diligently they manage their registrations, and there’s not much the RIRs can do to get the slackers to improve.
The main risk that’s relevant to this article is that an ISP can allow divergence between the users of some IP addresses and the controllers of the reverse DNS. I suppose in that respect it has some similarity to the problem of dangling CNAMEs and subdomain takeover attacks.
Yeah, the hierarchy for IP address allocation is stratified but not strictly nested.
(And domain name registration is more complicated than implied by just the forward DNS delegation hierarchy, because of the registry/registrar split and EPP. Made worse by the ossified design mistake of separating host objects from domain objects in the registry data model, bah.)
I used in-addr.arpa and ip6.arpa zones to host mirrors of my personal site just for fun because it looks cool (serving http on my side and use Cloudflare ACM to get SSL.com certs for the .arpa zones, then proxy traffic thru Cloudflare). But it stopped working since (maybe) a week ago. I tried manually provision the certs but they are all stuck in validation stage.
Not sure why CAs like Let's Encrypt are treating .arpa certs so differently, they are just another TLD... (I think) These kind of phishing attack is common for other TLDs as well and they can most be mitigated by enforcing DNSSEC.
These kind of phishing attack is common for other TLDs as well and they can most be mitigated by enforcing DNSSEC.
No, DNSSEC just protects DNS data from being corrupted. It doesn’t do anything to prevent someone with control over a domain name from doing bad things with it. (Much like TLS doesn’t prevent a webserver from hosting a phishing site.)
This article is a bit annoying because it’s mixing up the use of .arpa as a way to obfuscate the domain name of a phishing site, with dangling CNAMES and subdomain takeovers, which are two almost completely different kinds of attack. Well, they both involve DNS and phishing, but their purposes, techniques, and goals are widely divergent.
dzwdz | a day ago
...so, why would you ever call that a vulnerability in the DNS provider? Why shouldn't I be able to host my reverse DNS zone on a "normal" DNS provider? And if I want to add an A record there... why do you care? How does that affcet you?
I also don't really get how it's "implicitly trusted". If you have some weird security system that implicitly trusts .arpa domains... good job, I guess?
This would also be really easy to deal with. The odds of a legitimate website (that's of interest to non-tech people) being hosted on .arpa are around 0, so if you're concerned about phishing you could mark all of them as suspicious or something. But why break DNS providers?
alandekok | 10 hours ago
I'm in a bit of unique position here. I was heavily involved in anti-spam work for a while. I also worked at Inboblox for a bit, where I worked on their DNS/DHCP server, sat next to Cricket Liu, and attended some of the meetings of the root name server operators. I'm also one of the few people who have officially allocated something within the
.arpadomain:eap.arpa. That domain is used for 802.1X network access, such as with unauthenticated EAP-TLS.Let's start with
.arpadomains in email messages. There are very, very, few reasons to reference a.arpadomain in an email message. There are some legitimate uses, such as discussing reverse addresses, etc. But I can't think of many legitimate reasons to put a.arpaaddress in as the target of anhref. That alone should raise all kinds of red flags, and hit major signals for being spam.Another consideration is the special nature of the
.arpadomain. The IANA page saysWhat this means in theory is that the content of
.arpais extremely restricted. At least, so far as standards go. In practice,.arpais just another domain in DNS, and you can put pretty much whatever you want there.This difference between theory and practice creates vectors for all kinds of attacks. People expect
.arpadomains to contain only a few types of resource records, but DNS resolvers don't actually enforce any of those restrictions. Even worse, DNS resolvers are explicitly required to not enforce much of anything on the data they transport. If they did enforce rules for things they knew about, then it would be very difficult to add anything to DNS.But your personal DNS resolver is free to enforce all kinds of things that you know about. This realization opens up the possibility for you (or your DNS server) to filter out all kinds of things that you know you will never use.
Addressing some of the comments below:
Because it's not your reverse zone. The
.arpadomain is owned by IANA. IANA allows certain uses of.arpa, one of which is allowing people to use subdomains in specific ways without prior notification to IANA.The issue here is that domains within
.arpaare different from domains within the rest of the DNS hierarchy. If you want to hostfoo.example.comon a public DNS server somewhere, then you also have to ownexample.com. (To be technical, if you didn't ownexample.com. you could perhaps listfoo.example.comon a DNS server somewhere, but people looking it up would findexample.com, who would then never point to you.)There's no such hierarchy for
in-addr.arpa. If you own 192.168.1.2, you don't get assigned that address from the192/8people. So you can arguably put pretty much anything into a reverse zone, and no one will ever notice.To put it another way, whoever owns a block of IP addresses also officially owns that (reverse) subdomain within the
in-addr.arpadomain. That ownership isn't really enforced much of anywhere, which opens the system up to various attacks.This is a strong argument for having DNS providers put strong limitations on what they allow to be done with reverse zones in
.arpa. If you're not a network provider, you arguably shouldn't be publishing anything within thein-addr.arpadomain.Because you don't own those domains. While certificates can contain domain names, the certification authorities were not enforcing the DNS rules for domain names in certs. This opens up the system for cross-protocol attacks.
The CA/B forum has apparently decided to enforce some of the official DNS rules. But they're still open to more attacks:
OK, that's nice. What about the other zones within
.arpa? e.g.It seems that you can get a legitimate cert for
home.arpa, even though you don't actually own that domain. You only have the right to use it within the physical boundaries of your home.There are more reserved domains than just
.arpa. list. ICANN and IANA have also reserved.internal, which is for internal use within organizations, much like reverse zones.I can't find anything on the CA/B site which limits certificate issuance for these other domains. Sadly, this means that these attacks will continue.
fanf | 8 hours ago
Huh? There absolutely is a hierarchy, though it is complicated and tangled due to address transfers. (I guess you are using 192.168/16 as an example because as a concrete instance it’s a misleading special case.)
Before they were used up, IANA allocated /8 chunks to RIRs, which allocated sub-chunks to LIRs (aka ISPs) which in turn suballocated to their customers. You can trace this path through whois or RDAP referrals, and the reverse DNS delegations should correspond to the IP address allocations.
But IP addresses can be transferred between LIRs in different regions, so the /8 chunks are fragmented across RIRs. (This has long been the case for the old pre-RIR pre-CIDR class B allocations.) IANA delegates the reverse DNS for each /8 to an RIR, and there’s a somewhat shonky mechanism for the other RIRs to send to the /8 zone owner reverse DNS zone fragments for transferred IP address ranges.
(I think they should use classless reverse DNS delegation, but DNAME still scares people even though it works pretty well for this purpose.)
The ownership is implemented in the RIR databases. When an LIR is allocated a block of addresses, that is recorded in the RIR database. The LIR has access to the database to manage the allocation’s whois records and reverse DNS delegation, and they are supposed to ensure that this metadata is correctly set up.
But yes in practice ISPs vary a lot in how diligently they manage their registrations, and there’s not much the RIRs can do to get the slackers to improve.
The main risk that’s relevant to this article is that an ISP can allow divergence between the users of some IP addresses and the controllers of the reverse DNS. I suppose in that respect it has some similarity to the problem of dangling CNAMEs and subdomain takeover attacks.
alandekok | 5 hours ago
Yes, that's a better phrasing.
The hierarchy is not anywhere near as clear as for "com" -> "example.com", etc.
fanf | 5 hours ago
Yeah, the hierarchy for IP address allocation is stratified but not strictly nested.
(And domain name registration is more complicated than implied by just the forward DNS delegation hierarchy, because of the registry/registrar split and EPP. Made worse by the ossified design mistake of separating host objects from domain objects in the registry data model, bah.)
[OP] ysun | a day ago
So this apparently affected me in a little bit.
I used in-addr.arpa and ip6.arpa zones to host mirrors of my personal site just for fun because it looks cool (serving http on my side and use Cloudflare ACM to get SSL.com certs for the .arpa zones, then proxy traffic thru Cloudflare). But it stopped working since (maybe) a week ago. I tried manually provision the certs but they are all stuck in validation stage.
Not sure why CAs like Let's Encrypt are treating .arpa certs so differently, they are just another TLD... (I think) These kind of phishing attack is common for other TLDs as well and they can most be mitigated by enforcing DNSSEC.
sknebel | a day ago
They have to, because it was recently decided to enforce that they are not just another TLD: https://cabforum.org/2025/11/10/ballot-sc-086v3-sunset-the-inclusion-of-ip-reverse-address-domain-names/
[OP] ysun | a day ago
So bunch of industry giants just decide to do so huh... They know how to take all the fun away for sure
pp.134 https://cabforum.org/2025/11/10/ballot-sc-086v3-sunset-the-inclusion-of-ip-reverse-address-domain-names/BR-SC086.pdf
danielrheath | 20 hours ago
Look, I love me some whimsy in tech... but cmon, not in a Certificate Authority. Those should be as boring as possible.
fanf | 23 hours ago
No, DNSSEC just protects DNS data from being corrupted. It doesn’t do anything to prevent someone with control over a domain name from doing bad things with it. (Much like TLS doesn’t prevent a webserver from hosting a phishing site.)
This article is a bit annoying because it’s mixing up the use of .arpa as a way to obfuscate the domain name of a phishing site, with dangling CNAMES and subdomain takeovers, which are two almost completely different kinds of attack. Well, they both involve DNS and phishing, but their purposes, techniques, and goals are widely divergent.
adamo | 12 hours ago
I remember I used to put MX records on the .arpa I used to manage.