Is there a quick way to figure out what Advertisement Domain is causing a site to fail?

I’ve been trying to implement the Advertising DBL in the DNS Firewall at my workplace, but I keep getting users telling me that sites are broken. When I try searching through System Logs->DNS Unbound, there are thousands of entries and it is nearly impossible to find “the” domain that is breaking the site in a timely manner. After about a week of trying, I finally resorted to disabling it this morning. I had a user today that could not input CC information on doordash.com (the rest of the site worked) and by the time I disabled the DBL and they were able to input the CC info, they got an email from Door Dash saying their account was deactivated for violating their terms of service. They were trying to send a customer some donuts. :man_facepalming: I would really like to use this DBL because I know there are some malicious ads out there that might not be blocked by malware/phishing DBLs, but having a user get their Door Dash account deactivated was enough of a blemish on me that I’m reluctant to try again.

Is there a quick way to determine false positives, or is it a trial and error process?

I hate to bump up my post, but how are other folks here determining what domain is causing a site to not work?

I open the DNS system logs in a browser window. Note the time for the last entry. Then I try and access the web site having problems. When it gets blocked I then go back to the DNS system Logs and review all the blocked entries from the category that is causing the problems.

In the few cases I have evaluated where I or a user in the forum had problems with there were not too may lines in the logs to review.

In these cases it was relatively easy to identify a whitelist entry or to identify it was a false positive or a couple of false negatives in the early days.

I have not had to deal with many adverts based issues. If I find a website that requires a lot of adverts to be whitelisted I tend to stop using that website.

Thanks, that’s exactly what I’ve been doing, but I’m on a very busy network (close to 100 users at its peak) so it’s impossible to keep up with the log updates. They scroll to the next page almost instantly. What I have been doing is taking the site information home and testing on my very quiet home network, then whitelisting and/or reporting any false positives. Also, with so many users, the amount of ad-based issues will be much higher. And I can’t very well tell my boss to stop using a website if it is a legitimate site.

These are the steps I use:

  1. Grab the IP Address of your computer (it is much easier to track your own use)

  2. Open Terminal and login, via SSH, to the IPFire device. After connected enter:

tail -f /var/log/messages | grep --color -i "rpz.*[yourIP]"
  1. Go to your local browser and enter the blocked URL. In this case DoorDash.
[root@ipfire ~] # tail -f /var/log/messages | grep --color -i -e "rpz.*192.168.65.169"
. . .
Jul 14 22:07:10 ipfire unbound: [1894:1] info: rpz: applied [ads.rpz.ipfire.org] beacon.riskified.com. rpz-nxdomain 192.168.65.169@56693 beacon.riskified.com. HTTPS IN
Jul 14 22:07:10 ipfire unbound: [1894:0] info: rpz: applied [ads.rpz.ipfire.org] beacon.riskified.com. rpz-nxdomain 192.168.65.169@55166 beacon.riskified.com. A IN
Jul 14 22:07:10 ipfire unbound: [1894:1] info: rpz: applied [ads.rpz.ipfire.org] *.cloudflareinsights.com. rpz-nxdomain 192.168.65.169@55220 static.cloudflareinsights.com. HTTPS IN
Jul 14 22:07:10 ipfire unbound: [1894:3] info: rpz: applied [ads.rpz.ipfire.org] *.cloudflareinsights.com. rpz-nxdomain 192.168.65.169@64530 static.cloudflareinsights.com. A IN
. . .
Jul 14 22:07:11 ipfire unbound: [1894:1] info: rpz: applied [ads.rpz.ipfire.org] *.sentry.io. rpz-nxdomain 192.168.65.169@53763 o17585.ingest.us.sentry.io. HTTPS IN
Jul 14 22:07:11 ipfire unbound: [1894:2] info: rpz: applied [ads.rpz.ipfire.org] *.sentry.io. rpz-nxdomain 192.168.65.169@56141 o17585.ingest.us.sentry.io. A IN
Jul 14 22:07:12 ipfire unbound: [1894:3] info: rpz: applied [ads.rpz.ipfire.org] *.segment.com. rpz-nxdomain 192.168.65.169@61828 cdn.segment.com. A IN
Jul 14 22:07:12 ipfire unbound: [1894:2] info: rpz: applied [ads.rpz.ipfire.org] *.segment.com. rpz-nxdomain 192.168.65.169@64649 cdn.segment.com. HTTPS IN
Jul 14 22:07:14 ipfire unbound: [1894:2] info: rpz: applied [ads.rpz.ipfire.org] *.stripe.network. rpz-nxdomain 192.168.65.169@57538 m.stripe.network. A IN
Jul 14 22:07:14 ipfire unbound: [1894:3] info: rpz: applied [ads.rpz.ipfire.org] *.stripe.network. rpz-nxdomain 192.168.65.169@61219 m.stripe.network. HTTPS IN
  1. You’ll see a big handful of messages and one, or a few, or all of them need to be allowlisted.

Your method for testing at home is the best way to do it!

This may be too ambitious for a one-person IT dept who also manages another dept (non-IT related). I may just leave the Ads category turned off, as much as I’d like for it to work.

Just a thought. If you installed noscript in your browser, it should show all the sites that website is trying to link to. Then you could allow or disallow to find the culprit. Just a thought.. Noscript is a bit of an eye opener if you want to see all the “behind the scenes” links…

Thanks, back in the day I used to use the noscript plugin before the web become so dependent on scripting. I might give that a try if I decide to enable Ads again.