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. 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.
There’s a long archive of discussions on the relative merits of blocking DNS to 127.0.0.1 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:
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:
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:
- 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.comuses this (seelocal.reserveamerica.com) - 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.comfor example. - Split-horizon DNS services by companies like Synology (
quickconnect.to), Unifi and even our own DynDNS service that is included for any subscriber. - Special apps like Plex and SQRL 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:
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.