what could be the issue initial failure of duckduckgo

4o4rh

Ever since 24.03 and now 24.11 i have a problem when I open firefox with the default duckduckgo search engine.

I get the error

Hmm. We’re having trouble finding that site.
We can’t connect to the server at duckduckgo.com. Did you mean to go to www.duckduckgo.com/?t=lm&atb=v353-1?

As soon as I refresh, it comes good. Same if I start from linking a link

Gertjan

@4o4rh said in what could be the issue initial failure of duckduckgo:

Hmm. We’re having trouble finding that site.

"finding" is a bit vague. Before connecting to the IP of the web server of duckandgo, it neds to know the IP of that server.
Keep in mind : programs, OSes etc don't now nothing about text like "duckgo.com", these are only there for humans.
So, firefox start to execute a DNS request first.
Something like this : what is the IP of the host "duckgo.com".

Go here : about:preferences#privacy
and look at the bottom of the page. If you see this, your fine :

If some other option is selected, you have to talk to the admin of pfSense.
Or select what I've shown in the image.
Also : inform yourself about why Firefox is using DoH .... (this bypassing your local device DNS and pfSense)
If your pfSense pfBlockerng, and blocked DoH, the Firefox will have issues (as that is what the pfSense wanted when blocking DoH).

If Firefox uses : "Use your default DNS resolver", Firefox will ask your device (OS° to resolve duckgo.com.
Your device OS will look up if it already knows the answer by checking its DNS cache, and if not present, ask the upstream DNS server (== your pfSense) to resolve duckgo.com
( do not assume this. Check your DHCP lease info to see what DNS your devic eis using. maybe it isn't pfSense, as some like to use 8.8.8.8 for some reason )
If the device is using 192.168.1.1 (== pfSEnse == the default) then the pfSense Resolver will check its own cache, and if not present, will actually resolve duckgo.com for your device, and communicate back the answer, the duckgo.com IP address.

Firefox to;d you : "We’re having trouble finding that site."
I'm not sure who 'we' is but what you know now, you can check the entire chain. That said, I'm not sure what propose you to check if DoH works.

Anyway, if Firefox can't find the IP of duckgo.com, or it took to long to receive an answer, Firefiox will show you this message (I guess, Firefox is open source, so I could look up the exact condition).

To make things even more confusing : if your device uses IPv6 (they all do now by default) the DNS request of "what is the IP of duckgo.com" will give firefox back two answers : an IPv6 and an IPv4.
The IPv6 is 'always' used first, and if it fails ... firefox will fall back to IPv4.
If all this took to much time, you see the message.
I admit, I'm just thinking out loud now. If it was my firefix, and my pfSense, I would look it all up, see what is actually happening.

Btw : this has been set up correctly :

patient0

@4o4rh I got the same issue but only for a few days. I usually use start.duckduckgo.com (the simplest webite version of duckduckgo.com). And I do use the Arc browser on macOS, so it's not Firefox related.

What DNS servers are you using? I do use Control D at the moment and do suspect it to be the culprit. Since I don't use pfBlockerNG or any IPS don't think pfSenses has anything to do with it.

4o4rh

@patient0 i am using pfsense as my dns server

@Gertjan I already have the DNS over HTTPS off as I am using my pfsense as the dns server.

I wonder if it is because the dns server has to forward the request the first time?

patient0

@4o4rh said in what could be the issue initial failure of duckduckgo:

I wonder if it is because the dns server has to forward the request the first time?

That not it for me because multiple following calls to the URL are sometimes very slow, but don't time-out.

And beside: that would be true for ever site you visit the first time since its TTL run out.

Addition: I'm none the wiser -> Since I'm on the road I do use a travel router based on VyOS with Technitium DNS running in a container and doing all the DNS-ing. It allows to create DNS zone and I did now create one for duckduckgo.com with an A record to 40.114.177.156 (the IP duckduckgo.com resolves where I am) and a CNAME for start.duckduckgo.com to duckduckgo.com - same as other DNS resolver resolve to.

The travel router is wired to a LTE router.

Access to start.duckduckgo.com works fine as long I take down my WG tunnel to my home router (pfSense) and route all traffic through the LET router.
When I enable the WG tunnel to my pfSense (and disable the 0.0.0.0/0 route to the LTE router and enable the 0.0.0.0/0 route using WG tunnel endpoint as next-hop) the timeout start to happen again.

DNS resolution did change, still happening on the Technitium DNS server with the authoriative zone on it.

Calling it from a Firefox in a private tab, Web Developer Tools/Network with 'Disabled Cache' throws a connection timeout with NS_ERROR_NET_TIMEOUT.

Screenshot 2024-12-12 at 13.02.20.png

I don't know what to make of it right now

Gertjan

@4o4rh

If you have a PC, do this :

C:\Users\Gauche>nslookup
Serveur par défaut :   pfSense.bhf.tld
Address:  2a01:cb19:907:bbaa:92ec:77ff:fe29:392c

> set d2
> www.ducduckgo.com

So you type :
nslookup [enter]
set d2 [enter]
www.duckduckgo.com. [enter]

and admire the results.
There you have your answers ( don't worry, took me years to reach the moment that it was possible that I understood each line ).
This is DNS,

You'll find that the answer came back with an A record, the IPv4. And this record can be cached locally for :

ttl = 30 (30 secs)

after which www.duckduckgo.com. should be resolved again .. (yep, you wonder why, so do I)

Btw ; I couldn't find the query time, but it was instantaneously for me.

So Firefox, doing exactly the same thing, should receive an answer within the same delays.

Just for the record : you use Kea or ISC ?
If ISC, there is an additional story.

4o4rh

@Gertjan I don't see a ttl with a linux client.
what i do see is the server coming back with safe.duckduckgo.com and the ip address.

I have DNSBL SafeSearch enabled in pfBlockerNG, so I wonder if that has something to do with it.

has for KEA, I was using ISC on 24.03 and am using KEA since 24.11 so I don't think that has anything to do with it, as the safe symptoms existed in both

Gertjan

@4o4rh said in what could be the issue initial failure of duckduckgo:

so I don't think that has anything to do with it

Correct.
But if you were using ISC and activated the DHCP registration in the Resolver, unbound (the resolver) would get restarted ( !) on every lease (renewal) coming in.
You use pfBlockerng also ? The unbound restart can last tens of seconds.
Side effect ; (very) frequent DNS lookup failures - and moments later : all is fine.

@4o4rh said in what could be the issue initial failure of duckduckgo:

I have DNSBL SafeSearch enabled in pfBlockerNG

You mean this :

the first two are a no-go for me.
Dono what it does exactly, but I've been playing with this option for a while. Then 'complaints' start coming in at the front desk. I disabled the option and never came back.

patient0

JFYI I was able to solve it for me by running tcpdump with host set to 40.114.177.156 (duckduckgo.com address): had to adjust/reduce the mss value on my travel router's WG connection.

A bit strange since no other website I visit was having that issue but hey, so be it.

Squuiid

Just add the following line to your DNS Resolver Custom options:

local-zone: "duckduckgo.com" redirect