CNAME for SafeSearch (duckduckgo)

Help
1

(Ubuntu 22.04) I have been using Pihole's DNS Record to force SafeSearch for Google, Bing and Duckduckgo and was working fine, but I noticed SafeSearch in duckduckgo is not being implemented. I found that the safe.duckduckgo.com IP address changed.. but....

When I do an nslookup for safe.duckduckgo.com comes back as 52.149.247.1, but if I ping it, I get no results back.

I see there's an option for CNAME Records in Pihole, but I am not sure how to use it.

I have tried:
Domain: duckduckgo.com
Target Domain: safe.duckduckgo.com

Is this correct?
If not, how do I create a CNAME record for safe.duckduckgo.com?

thanks in advance.

2

You're correct and you can see it working with the dig command.

Before adding the entry

$ dig duckduckgo.com
...
;; ANSWER SECTION:
duckduckgo.com.		182	IN	A	52.142.124.215
...

After adding the entry

$ dig duckduckgo.com
...
;; ANSWER SECTION:
duckduckgo.com.		0	IN	CNAME	safe.duckduckgo.com.
...

EDIT: I've not used the CNAME feature before in Pi-hole. I noticed the text regarding CNAME limitations. Sure enough, although the above enables the CNAME, it stopped the duckduckgo.com domain from working. To fix this I tried adding the safe.duckduckgo.com IP address to the local DNS, and that fixed it.

To summarise:

Local DNS > CNAME Records
Domain --> Target
duckduckgo.com --> safe.duckduckgo.com

Local DNS > DNS Records
Domain --> IP
safe.duckduckgo.com --> 52.142.126.100

$ dig duckduckgo.com
...
;; ANSWER SECTION:
duckduckgo.com.		0	IN	CNAME	safe.duckduckgo.com.
safe.duckduckgo.com.	0	IN	A	52.142.126.100
...
3

I fear that won't work the way you want it to.

It is the correct way to define a CNAME, but CNAMEs won't be forwarded to resolve them any further, i.e. the DNS resolver has to know the IP address for the CNAME target domain in order to return an IP address.

This is pointed out directly on Pi-hole's CNAME page:

The target of a CNAME must be a domain that the Pi-hole already has in its cache or is authoritative for. This is a universal limitation of CNAME records.

Of course, you could add a local DNS record for safe.duckduckgo.com, but then you'll run into the same issue again every time DuckDuckGo decides to change IP addresses.

4

Why does nslookup provide a different IP address (52.149.247.1) vs dig?

EDIT...
Wait.. I ran dig and it comes up as the same IP.. where did you get 52.142.126.100 from?

5

Likely, DuckDuckGo applies load-balancing as well as location-based optimisations, so resolution results may be expected to differ.
(E.g. for me, duckduckgo.com currently resolves to 40.114.177.156 and safe.duckduckgo.com is 40.114.177.246.)

6

so it's based on location?

7

This actually worked for me!.. thanks so much.

EDIT:
I noticed that now just by adding this..

Local DNS > DNS Records
Domain --> IP
safe.duckduckgo.com --> 52.142.126.100

Also works.. my question is... what happens if the IP changes again?
Will it still connect to the correct IP and this is the reason to ALSO set this...?

Local DNS > CNAME Records
Domain --> Target
duckduckgo.com --> safe.duckduckgo.com

8

I answered my own question. I entered a bogus IP address for safe.duckduckgo.com and it didn't connect.
So I then added the CNAME record and after a few minutes the browser refreshed and duckduckgo.com opened with strict search.. so adding the CNAME record does eventually connect to the correct IP for safe.ducduckgo.com if it ever changes in the future.

EDIT:
Never mind.. it didn't work. duckduckgo.com stopped working.. won't even pull up.

9

It's probably a combo of what @Bucking_Horn and yourself said – DNS load balancing and/or geo-based servers. I'm in the UK and that IP is what safe.duckduckgo.com resolves to. That could well change based on their setup – they might decomission that address, or tomorrow it might resolve to another one in their pool. Or it may keep working but isn't where the updated work is taking place, so it's more of a fluke that it keeps working. Or they may use that IP for a different language region and suddenly the results are in another language.

So this static IP approach isn't ideal, but then they do advise this exact approach to enforce at the network level. They only state the CNAME part, but Pi-hole notes spells this out – "The target of a CNAME must be a domain that the Pi-hole already has in its cache or is authoritative for. This is a universal limitation of CNAME records.". So if DDG is advising this CNAME approach, presumably this need for an additional entry for the CNAME target comes up for sysadmins everywhere?

I'd drop them a mail to ask them to clarify this situation but I can't find a contact for the docs.

Is there a way to see that it's doing this?

I found it takes a few minutes for the changes to become used on the local network, presumably as the previous settings/defaults expire and get replaced with the fresh info.

10

Is this even the case after flushing dns cache and clearing browser and refresh internet connection.. do I still have to wait minutes?

11

I was clearing browser cache and cookies and flushing my upstream resolver (Unbound), but not flushing the client's DNS cache. If you're doing the latter (and are sure it's the right way to do it, no other OS-related under-the-hood services that's being sneaky in caching stuff, etc) I'd expect any changes to be picked up straight away.