CU 201: Safe Search via DNS failing with google.com

After upgrading to CU 201 two of my installations with activated Safe Search via DNS (on the DNS-tab) failed to open google.com - the URL could not be translated to an IP. After deactivating the Safe Search option, and waiting for the cache to flush, everything worked smoothly again.

Both installations use the opendns-Nameservers for resolving DNS-names - changing to other DNS (joindns4.eu, cleanbrowsing.org) did not solve the issue though.

Were there any changes to this option from CU 200 to CU 201? Did anyone else encounter this behaviour?

I just turned on safe search on my system and saved the setting.

Then tried opening google.com and it opened with no problems.

I also cleared all caches that I had running and still the same result.

So I can’t replicate the effect you are experiencing.

There were changes to unbound in CU201 due to the implementation of the DNS Firewall but no changes to the safe search section of the code ands as far as I can see no changes to any of the code in the DNS WUI page.

Thanks for the response. The problem seems to only occur on networks with Active Directory. The Domain Controller forwards the outgoing DNS-requests to IPFire.

On networks without Active Directory, Safe Search works perfectly.

If the first DNS on the DC is replaced with the IP of the IPFire, it also works - but obviously noone can login anymore (but the local admin could use Google Safe Search then).

So I assume it’s a problem between Windows Server 2019 (the only version I have to test) forwarding the DNS requests and IPFire’s Safe Search settings. Very weird indeed.

I will take a closer look at it later.

I was wrong when I said that the safe search section of the code was not modified.

It was refactored
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=7be4e129af88f8f9e5d78054bbe487ac1c83aee2

It is not clear to us why this would give a problem with AD but not without AD.

If it is related to the code changes in unbound then we would expect that there would be some messages in the unbound logs.

You can find these in the WUI - Logs - System Logs - Select DNS: Unbound in the drop down box labelled Section:

If you could try and access google.com on a network with AD and then look in the unbound logs and share what is there it might help us understand what is causing this problem.

Thanks for this hint. I activated Safe Search again and found this entry regarding my request.

I removed the local IP of our DC.

13:22:11 unbound: [1766:0] info: rpz: applied [custom] *.google.com. rpz-passthru @49904499044990449904 clients3.google.com. HTTPS IN
13:22:11 unbound: [1766:0] info: rpz: applied [custom] *.google.com. rpz-passthru ip@49904 clients3.google.com. HTTPS IN
13:22:11 unbound: [1766:1] info: rpz: applied [custom] *.google.com. rpz-passthru ip@50249 clients3.google.com. A IN
13:22:11 unbound: [1766:0] info: rpz: applied [custom] *.google.com. rpz-passthru ip@50853 forcesafesearch.google.com. HTTPS IN
13:22:39 unbound: [1766:0] info: rpz: applied [custom] *.google.com. rpz-passthru ip@50542 addons-pa.clients6.google.com. A IN
13:22:39 unbound: [1766:0] info: rpz: applied [custom] *.google.com. rpz-passthru ip@51848 addons-pa.clients6.google.com. HTTPS IN
13:22:47 unbound: [1766:1] info: rpz: applied [custom] *.google.com. rpz-passthru ip@51413 forcesafesearch.google.com. HTTPS IN
13:22:47 unbound: [1766:1] info: rpz: applied [custom] google.com. rpz-passthru google.com. DS IN

Looks like IPFire converts google.com to forcesafesearch.google.com - I tried to reach this URL directly now (without Safe Search activated, and after flushing the DNS cache on the DC), and it’s not reachable (not found).

Next I will test this on a network without DNS and check the logfile there. :slight_smile:

Edited: Logfile was not correctly pasted

Good morning everyone.

I’m experiencing this issue too. I have about 51 machines deployed, and roughly 30% of them are affected. In this latest version (core 201), I’ve had to disable SafeSearch and reset the unbound connection via SSH on some machines that were working fine with SafeSearch enabled.

I haven’t yet figured out the cause of this error, as almost all the machines share the same configuration.

Cheers.