--- title: "DNS Rebind Protection Revisited: Blocking Localhost Tracking" description: "How DNS rebind protection in adam:ONE blocked Yandex localhost tracking on Android by default, and how to exempt legitimate private-IP answers." url: https://adamnet.works/blog/dns-rebind-protection-revisited/ index: https://adamnet.works/llms.txt --- [All Articles](https://adamnet.works/blog/articles.md) Articles · DNS Rebinding · Privacy · adam:ONE # DNS Rebind Protection Revisited Yandex and Meta used localhost to track Android users across web and apps. How DNS rebind protection in adam:ONE blocked the Yandex technique by default for years, and how to exempt legitimate private-IP answers. David Redekop | ADAMnetworks • June 13, 2025 ![adam:ONE block page for localhost.fictitious.io blocked by DNS rebind protection](https://adamnet.works/uploads/dns-rebind-protection-revisited-2.webp) After this week’s attention to META and Yandex localhost abuses, it is time to revisit a core feature/option of protective DNS that offers a feel-good moment to those that applied this safety technique long before this abuse report came about. The in-depth report that triggered this is: [Disclosure: Covert Web-to-App Tracking via Localhost on Android](https://localmess.github.io/). I will address the META approach in a separate blog article, but here I want to focus on the Yandex approach to tracking users, specifically with the intent to bypass modern privacy standards and public policy. As with the vast majority of transactions online, including non-monetary information exchanges, DNS plays a necessary role. Yandex used `yandexmetrica[.]com` as a way to make a localhost connection since it resolved to `127.0.0.1`. Yandexmetrica literally was designed to live inside your own device. Most modern DNS servers offer DNS Rebind Protection; some are on by default, some include `127.0.0.0/8` and `0.0.0.0`, while others include only [rfc1918](https://datatracker.ietf.org/doc/html/rfc1918). There’s a long archive of discussions on the relative merits of [blocking DNS to 127.0.0.1](https://news.ycombinator.com/item?id=36399208) and our perspective is from doing this to millions of endpoints successfully as evidenced by the simple result that our users, by default, were protected against this Yandex tracking effort many millions of times. According to passive DNS records, Yandex has been doing this since October 2017! At the same time, DNS rebind protection protected users against any other tracking effort that utilizes the same technique. The most common reason this protection technique has not been implemented in the past is due to its one-size-fits-all approach on traditional protective DNS resolvers, but more on that later. In the case of adam:ONE default, the `anmuscle.conf` file includes this line: ``` private-subnets=127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,169.254.0.0/16,192.168.0.0/16,::ffff:a00:0/104,::ffff:ac10:0/108,::ffff:a9fe:0/112,::ffff:c0a8:0/112,fd00::/8,fe80::/10 ``` `private-subnets` is what we use to check against DNS answers, and if matched, that destination is re-written and effectively blocked. Consider the difference here: ``` unprotectedendpoint ~ % dig @1.1.1.1 localhost.fictitious.io +short 127.0.0.1 ``` Compare the above result with an attempt to resolve the same domain when DNS rebind protection mode is on: ``` protectedendpoint ~ % dig localhost.fictitious.io +short 192.168.1.1 ``` From this **protected endpoint**, the adam:ONE live log shows the end user the detail like this: ![adam:ONE domain log showing a localhost answer blocked by rebind protection](https://adamnet.works/uploads/dns-rebind-protection-revisited-1.webp) The re-written answer is that of the block page, which does not offer anything except adam:ONE services, including the block page. And if it’s the end-user browser that made an attempt at some obscure service, this is the experience: ![adam:ONE block page for localhost.fictitious.io blocked by DNS rebind protection](https://adamnet.works/uploads/dns-rebind-protection-revisited-2.webp) Note that this block is a result of either (a) blocked domain, or (b) a DNS rebind protection decision — defense-in-depth. ## Legitimate private IP address usage in the public DNS The objections network administrators have against DNS rebind protection is due to the false positives for legitimate usage. Our approach is to offer exemptions on a domain or rule basis. Broadly speaking, we find legitimate usage in these key categories: 1. **License validation**. A vendor of proprietary hardware/software solution often uses localhost license validation in order for the site/location to interact with the vendor’s internet infrastructure. `ReserveAmerica.com` uses this (see `local.reserveamerica.com`) 2. **BYOD devices with corporate split VPNs for internal services**. A significant number of Fortune 500 companies are using this approach to have public DNS records of internal private IP infrastructure. This is the case for `ctr.cantire.com` for example. 3. **Split-horizon DNS services** by companies like Synology (`quickconnect.to`), Unifi and even our own DynDNS service that is included for any subscriber. 4. **Special apps** like [Plex](https://support.plex.tv/articles/200288666-opening-plex-web-app/) and [SQRL](https://www.grc.com/sqrl/sqrl.htm) to facilitate an experience of complex solutions with a simple end-user experience. When the live log shows `Blocked: System private IP address` and it falls into a legitimate category, the simple solution is to exempt such a domain. Within the adam:ONE dashboard, this can be facilitated by simply adding a reference DNS resolver that does not process any rebind protection: ![adam:ONE rule exempting selected domains from rebind protection](https://adamnet.works/uploads/dns-rebind-protection-revisited-3.webp) When applied to an endpoint policy legitimate localhost lookups work just fine, like this: ``` C:\Users\David>nslookup Default Server: adamone Address: 192.168.1.1 > set type=A > local.reserveamerica.com. Server: adamone Address: 192.168.1.1 Non-authoritative answer: Name: local.reserveamerica.com Address: 127.0.0.1 ``` In essence, any forwarding rule is exempted from DNS Rebind protection. ## Yandex behaviour change We can confirm that Yandex have changed their behaviour since this report was published. Regarding Yandex, when I checked today, there is no longer a `127.0.0.1` answer to `yandexmetrica.com`: ``` unprotectedendpoint ~ % dig @1.1.1.1 yandexmetrica.com ; <<>> DiG 9.20.2 <<>> @1.1.1.1 yandexmetrica.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45689 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;yandexmetrica.com. IN A ;; AUTHORITY SECTION: yandexmetrica.com. 300 IN SOA ns3.yandex.ru. sysadmin.yandex.ru. 1749738001 900 600 3600000 300 ;; Query time: 401 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP) ;; WHEN: Thu Jun 13 10:24:59 EDT 2025 ;; MSG SIZE rcvd: 104 ``` ## Conclusion DNS Rebind protection offers tremendous value. Applying this simple technique with an exemption process for legitimate uses meets the needs of apps, services and users alike while raising the security posture against any other actor that may attempt a rebinding exploit in the future. ## Related reading Articles ### [Hairpin NAT vs Split-DNS](https://adamnet.works/blog/hairpin-nat-vs-split-dns.md) March 19, 2025 Articles ### [DTTS | Zero Trust DNS Enforcement: Policy Violation Management](https://adamnet.works/blog/dtts-policy-violation-management.md) October 23, 2025 Video ### [From Reactive to Proactive: A New Cybersecurity Philosophy](https://adamnet.works/videos/one9-from-reactive-to-proactive.md) September 18, 2025 ## See it on your own network Zero Trust Connectivity reduces attack surface 7000:1 by denying egress by default. Talk to us about what that looks like in your environment. [Request a Demo](https://adamnet.works/contact.md) [How adam:ONE® Works](https://adamnet.works/how-it-works.md)