From these 688 host names only 306 did resolve, while 382 did not.
Now what I'm interested in is, how would you interpret these findings?
a) regarding DNSSEC enabled
b) regarding the quality of the blocklist source
c) regarding the volatility of hostnames
Finally the practical question: Should the unresolving hostnames still be added to the blocklist?
Yes, they
should be added. They're for tracking
in-and-of-themselves, and meant not to resolve - at least in some cases (see my last post). But, I think the black-list method in general will fail (if used only by itself) because of the dynamics. It'll slow down the deluge tho, so it is useful ...
So, the ad servers have six prongs of attack:
- 1 - Normally resolved addresses associated directly with their https/http servers.
- 2 - Unresolvable addresses that are really for DNS tracking by the DNS itself.
- 3 - Buried addresses that are resolved server-side, and used as in item 1.
- 4 - Cookies in various forms (shared or not) - lesser now because people are adverse.
- 5 - Persistent super cookie client storage (because #4 is unpopular, often purged).
- 6 - Persistent image cache tags.
I'm seeing more of item 3 (where IP addresses are just included in the page). I don't see how you deal with those addresses, other than dynamic firewalling, based on (again) - the blacklist, which won't be all-inclusive. Maybe, a source scrubber could be used, but that'd be browser specific. Alternatively, maybe a proxy/scrubber could be set up so as to make the process browser transparent.
Experiment: do a dump of an unbound cache:
unbound-control dump_cache > thedateandtime.cache
Then, watch your outgoing connections, look for suspicious ones, and plug those addresses into a
grep on the cache file (or just do both on one line):
grep "x.x.x.x" thedateandtime.cache
Doing this, (assuming you've firewalled the DNS port) - will let you (occasionally) catch the item #3 stuff, mentioned above (in other words, in such cases a connection was made without the benefit of DNS). It would be beneficial to automate this kind of thing. Note that to load a cache file into
unbound:
unbound-control load_cache < thedateandtime.cache
One can manually add an item to cache:
unbound-control local_data "theservertoadd.tld A x.x.x.x"
... or delete existing local data:
unbound-control flush theservertoflush.tld
One other thing: browser DNS cache can upset the apple-cart, since it seems to drop cache entries unexpectedly (only on one browser brand I noticed). So, I always turn DNS browser cache (browser based resolver cache) off when I can. Due to item #6 in the list (above) - I usually also disable image caches. Disabling local storage for super cookies sometimes causes sites to break, so it's tough to turn it off unless one is not using javascript (in which case the site might be, by that fact, broken anyway). One can flush it regularly, though. Number #5 and #6 are kinda similar, but listed separately because they usually need to be disabled via separate mechanisms in browsers.
I could see certificate authorities hooking up with ad people,
to use OCSP for tracking. I've no proof of such a thing, but now that DNS is being so thoroughly abused ...
One more thing: with or without javascript, more and more sites are blending ad server functionality with site funtionality, so if you don't take the syrup, you don't get the puddin. It's turning internet into pay-for-view television, naturally. It's the progression.
For legal purposes: I'm not an expert, this is all uneducated opinion, and so please don't do what I do. Whew! Since this is not my blog, I'm done.
