Oh well, that's all right then
As long as it's just small, unknown vendors like *checks notes* Oracle and Adobe, we should be fine.
AdGuard on Thursday published a list of more than 6,000 CNAME-based trackers so they can be incorporated into content-blocking filters. CNAME tracking is a way to configure DNS records to erase the distinction between code and assets from a publisher's (first-party) domain and tracking scripts on that site that call a server …
If a webpage has a link to https://deviouscname.firstparty.tld and that is actually a CNAME for adserver.devious.tld, won't my system make 2 dns reqeusts: the first for deviouscname.firstparty.tld which returns adserver.devious.tld, and a 2nd that resolves adserver.devious.tld to 220.127.116.11, which will be blocked because of 1) devious.tld or 18.104.22.168/16?
> Perhaps I don't appreciate how difficult this is for a web browser but if I ping a CNAME address the real address gets shown.
You mean if you have
foo.bar IN CNAME adtech.foo
adtech.foo IN A 22.214.171.124
When you do ping foo.bar you'll get
64 bytes from adtech.foo (126.96.36.199)
That's reliant on there being a valid PTR record for 188.8.131.52 naming it adtech.foo. That's not a given, and checking the PTR for every IP you connect to gets quite expensive (but would sometimes yield results).
True, but it's still additional latency per-FQDN, and the benefit from it is fairly limited, as ad companies just won't bother adding reverse records for their IPs, where they even own their ads.
A stonking number of ad/tracker services uses AWS/Azure/GCP too, so the PTR already won't yield much useful information in terms of identifying that it's a tracker service.
> won't my system make 2 dns reqeusts: the first for deviouscname.firstparty.tld which returns adserver.devious.tld, and a 2nd that resolves adserver.devious.tld to 184.108.40.206, which will be blocked because of 1) devious.tld or 220.127.116.11/16?
Assuming you've an even semi-standard setup on your OS, no.
- Your OS will send a query to your configured recursor (lets say google, 18.104.22.168) for deviouscname.firstparty.tld
- Google will go and find the authoritatives for firstparty.tld and query deviouscname
- The authoritatives will reply with CNAME adserver.devious.tld
- Google will then go find the authoritatives for devious.tld and query adserver
- Those authoritatives will return a response (lets say 1 A record)
- Google will then reply to you with the two records
- Your browser will connect out to the IP in the A record
The response you get will be something like
deviouscname.firstparty.tld IN CNAME adserver.devious.ltd
adserver.devious.ltd IN A 22.214.171.124
Only one DNS query ever leaves your system - for deviouscname.firstparty.tld - it's the recursor that follows the CNAME (hence recursor).
Of course, you *might* be running a recursor on your own machine, which changes things, but most users aren't, or are but have configured forwarding, so the query still goes out to another recursor which does all the work (doesn't stop their local recursor inspecting the response and blocking, of course).
> and a 2nd that resolves adserver.devious.tld to 126.96.36.199, which will be blocked because of 1) devious.tld or 188.8.131.52/16?
As above no, but this is how the adblocker extensions that support CNAME blocking achieve this. They resolve deviouscname.firstparty.tld and inspect the response. When it sees the CNAME, it checks whether the target is in the block list.
Even at the DNS blocking level, being able to inspect CNAME targets is relatively new.
In Unbound it used to be that if you had
local-data: "adserver.devious.ltd A 127.0.0.1"
Then you'd get inconsistent looking behaviour depending on whether you were directly querying that name, or it was a CNAME target (
curl http://adserver.devious.ltd # Connects to loopback
curl http://cnamedtoadserver.foo.ltd # Resolves correctly and connects to adserver
Pihole itself also only relatively recently got the ability to block CNAME targets.
Seriously, the solution to this isn't a browser plugin, it's to control your DNS. It is also going to protect you from other horrors. And if you blackhole the DNS requests it will also wipe out some of the hit tracking data your ISP has been selling them thanks to Idjit Pai. Filtering DNS servers are the new firewall.
And don't worry about "what will they think of next", they have already moved on to A records instead of CNAMES (which you can also block by IP btw).
Doesn't think come from the bad old days where you accepted plaint text email on port 25 and assumed that sender would never lie about their address? Is there really a use for them given that you can update A and AAAA records automagially? And while I am whining why not take the axe to the PTR records. Nobody cares what IP they connect to, as machines and address no longer have any real meaning due to network mangling and manipulation.
Really disappointing that nobody took the bait. Where are the CNAME apologists that say I NEED to call something by something else in my domains, usually to some other thirdparty over which I have no control. And nobody going to say that if I cannot do a reverse look up on the SSH server I connected to I wont really know who it is, because since v2 of the protocol, I still don't trust the key it presents me?
So as a novice Firefox with uBlockOrigin user I wondered if I could add a CNAME filter list, clicked on the article links, and came across this dublious looking address on a place called GitHub. +++https://bananamovies.net/gangbang-stars-vol-3/ (nsfw) - popup+++ .
Blimey! I won't be clicking on that thanks, but is this the same scary place I should be looking for a legit' filter list please?
Does uBlock work automatically or do I need to add a CNAME filter myself?
Biting the hand that feeds IT © 1998–2021