Hacker News new | ask | show | jobs
by stefan_ 2400 days ago
So block content, as always? That's not possible for NextDNS, which I guess is their concern, but then DNS blocking was always going to be a very very blunt instrument.
4 comments

"NextDNS is proud to announce that all your blocklists are now applied to each intermediate CNAMEs in addition to the queried domain name.": https://medium.com/nextdns/nextdns-added-cname-uncloaking-su...
At home I'm using it in addition to ad blocking in the browser, for apps and other things that might slip through.

Currently it's just dnsmasq with a huge blacklist, and I guess it doesn't support checking the whole CNAME chain against that list, which would be really cool.

It doesn't need to have every cname in it. The cname resolves to the actual "bad" domain, which should be in your list already. That's why DNS blocking can still combat this method easily, while it's much harder at the browser level. uBlock Origin for Firefox beta has a "run all non-local domains back through and check for cname redirection" feature, which can also block the cname trick, but it will increase DNS latency because it has to check each external domain again for the "true" domain.
> [uBO] will increase DNS latency because it has to check each external domain again for the "true" domain.

The browser API used by uBO returns the last CNAME in the chain. I consider the DNS lookup itself to be an non-issue overhead-wise in uBO because:

- The browser would need to do it anyways

- DNS lookup results are cached at both the browser and uBO level

> It doesn't need to have every cname in it. The cname resolves to the actual "bad" domain, which should be in your list already.

That doesn't help if dnsmasq only checks the incoming request against the list, and not the whole cname chain of the result.

the NextDNS people are really smart; I just submitted a request for the ability to blacklist replies (for any hostname) that match a given IP/mask or originating AS number. This would solve the problem, especially if it is supported in blocking lists.
>Security implications of CNAME Cloaking

>While this is considered bad practice for a website to set cookies as accessible to all subdomains (i.e., *.website.com), many do this.

>In that case, those cookies are automatically sent to the cloaked third-party tracker.

So website.com decided to sellout and now the cookies you send to website.com that betrayed your trust are also sent to it's chosen third-party tracker?

That is a distinction without difference. The security implication is storing any data with website.com!

Yes, but www.website.com cookies won't be sent. But you'll have to crack open devtools to figure out which one each website is doing.
Yes, the cookies of the website that installed a third-party tracker to spy on you will be sent to the website and the tracker. They could always do that.