Hacker News new | ask | show | jobs
by strenholme 2401 days ago
The way to counter this is to know the IP a given CNAME resolves to, and to block “rogue” (read: tracking) IPs.

As an open-source DNS implementer, I know this has already been done, since my DNS server (MaraDNS’s Deadwood recursive resolver) has the ability to refuse to resolve DNS names with bad IPs via ip_blacklist.

The reason I implemented this is to block NXDOMAIN redirects (when using an ISP’s DNS server and mistyping a domain name, instead of getting “nothing there”, it goes to an ad-filled “search” page provided by the ISP), but the implementation scales and it should work for blocking a large number of rogue CNAME redirects like this one.

I’m sure others have implemented something similar out there (I will let someone who knows the pihole ad-blocking DNS server, not to mention NextDNS, better than me tell us how they do this), and I’m sure Firefox, if they do not do so already, will allow ad/privacy blockers to know the IP of a given name to allow blocking at the browser level.

2 comments

A dead response notes that IPv6 makes blocklists intractable as IPs can be rotated at will until doomsday with few consequences.

The response in this case will all but certainly be an increasing tendency to apply IP-level whitelists, and deny or at least limit traffic until it's demonstrated trustworthyness.

Much as port-based firewalling progressively closed off virtually all service access other than HTTP/HTTPS, and a few other exceptions, bad actors will likely limit the effectively-reachable scope of IP address space itself.

> block “rogue” (read: tracking) IPs.

With IPv6 that's as impractical as blocking "rogue" FQDNs.

Why? Just block ranges.
Exactly. If I were to update this code, for IPv4 blocking, I would allow it to block /32 (single IP) and /24 networks. For IPv6 blocking, I would allow blocking a single IPv6 address, a /64 range, and (for extreme offenders) a /48 range.

One way to do this is to have multiple hash tables: One for single IPv4 addresses, one for IPv4 /24 ranges, one for single IPv6 addresses, one for /64 IPv6 ranges, and one for /48 IPv6 ranges. Note that while the hashes have (generally speaking) a “big O” of 1, we need to perform one additional operation per range size. IPv4 /32 and /24 blocking requires two lookups, and IPv6 /128, /64, and /48 blocking requires three lookups.