oh my no reply for so long

OK, for anyone that has an issue in future, there are 2 main things that need to be done:

Set a rule for port 53 (DNS) to allow Set up an Access List (at the top of the page for the resolver). This would normally be for the network range you are using (or any range you want to access this DNS).

I also unticked the forwarding option as I have been told that is to always forward, pfsense will still resolve with the DNS servers in the general settings.

@kiokoman said in DNS failover:

windows doesn't always query the first dns server

Correct it does not. Windows queries the "last successful" DNS server first. Other OSs query DNS servers in order. Notably, on a Windows Server domain the domain DNS should always be queried because public DNS doesn't know about the LAN network.

Oh, I see what you're referring to now. When 127.0.0.1 fails, it tries the next server at 1.1.1.1#53, which should have been 1.1.1.1#853. Could that be a pfsense bug because I have it set up exactly as described in that post. Or perhaps just a side effect of trying nslookup on the pfsense box, which has 3 ips listed (although the cloudflare ones really should be tls only, not udp over 53)

The status page for dns resolver clearly shows that it is set up to use tls over port 853. When I follow step 3 from that post and go to diagnostics/states and filter for 1.1.1.1, I see tcp 853, and Also checked packet capture and see the dns requests go to cloudflare on port 853

Just an update, as of today, 127.0.0.1 on pfsense resolves nvidiagrid.net. I'm thinking perhaps nvidia had some configuration issue on their dns. But then again, it baffles me why direct queries to 1.1.1.1 over tls resolved, whereas dns resolver forwarded requests to it failed.

@kiokoman
(BTW, pfSense could say more, simply by testing items one at a time... ;) )

After a bunch of googling:

unbound is not ever authoritative dnsmasq CAN be authoritative. I'm working on it...

@timboau-0 Exactly. The case you describe :"if the WAN has a 0.0.0.0 or N/A IP address and is set to DHCP it should be continually be trying to obtain a valid IP address" is exactly the behavior that this bug prevents.

Specifically, once dhclient times out, it will not retry for a potentially very long time; if you can share the dhclient logs (real IPs not necessary) from when you see the IP loss, we will be able to tell if this bug is indeed being triggered.

Hammering the WAN link with a large quantity of DHCP requests is also indeed bad, hence the implementation of an exponential backoff algorithm to mitigate this.

Never Mind, found the problem even though I don't need multiple views, they setup the GUI so that you still have to create one view, and put the zone in that view before it creates the Zone configuration file and links it in the named.conf.

I'm not sure that's a factor for DoT but I'd have to check. It would be a factor for DoH but that's still up to the DoH client. That's why it worked when you enabled DoH+ESNI in your browser, because your browser was doing it.

SNI matters for DoH since it's based on HTTPS and SNI is a concept for HTTPS servers.

If you do a packet capture of a DoT request, you probably wouldn't even see an SNI exchange.

I have figure out how to resolved the issues base on a post I saw.

There is no need to use DHCP options Use the pfsense "Network Booting" If your boot file contain reverse slashs, you would have to escape it with a second reverse slash.

@reberhar Yes indeed my DNS is now reliable and fast. My problem with DNS was not the service provider or indeed in the DNS, but an error in the traffic shaper.

Found it on my own.

Entered it there.

@Robertsonland

To monttor the bulb side, you configure a mirror port to monitor the appropriate switch port. Then connect a computer running Wireshark to the mirror port. Packet capture can only monitor what it's directly connected to. So, it could monitor it's side of the switch, but not the bulb side. With Wireshark, you can see which devices have that bit changing and whether it's being done by the AP. You just have to poke around and look. You can use filters to help isolate the devices. For example, if you filter on IP, then only that device, regardless of what the MAC turns out to be, will be captured. While Wireshark comes with several filters, you can create your own or modify the existing ones to suit your needs. For example, I have created MAC address filters for every device I have. For example, here's one for my tablet's MAC address:
ether host b0:6e:bf:19:bc:f4

I could also filter on it's IPv4 address:
host 172.16.0.93

There are lots of different things to filter on. Have fun!

@Gertjan said in DNS Resolver Issues...What's going on here?:

And as always : I would really like to know why people insist on replicating their, far more then just 'web' activities, to external companies ? Really, please, tell me why.
1.1.11. 8.8.8.8. 1.0.0.1 8.8.4.4 are doing exactly what the resolver does : they resolve and cache. And one thing more, like some sort of a payload : they feed their big data and yes, they promised NOT to 'tape' your WAN IP with it. I'm sceptical.

+1.

And users should ask themselves this question: "what's in it for the companies that are providing this "free" DNS?"

What could motivate a for-profit company to spend the large sums of money required to maintain a robust DNS infrastructure and then offer it for free? Are you sure it is just pure altruism, or could it be that they see a huge opportunity for monetization of something they get from offering the service? My bet is on the latter, and the thing they are monetizing is your browsing data.

Why not do as @Gertjan suggests and just use the default pfSense settings with unbound?

@moussa854
Strange issue. Thanks for coming back and posting the solution.

@gschmidt said in DHCP clients getting different lease times:

I want to decrease that time to 3-5 minutes, because this may save some energy

Ok this peaked my curiosity ;)

How many freaking lights do you have on exactly that a savings of lets say 17mins would be of any significance? I could see turning them off if nobody is home, ie they forget to turn them off when they left the house for day of work... But how much do you think that extra 17 minutes gets you?

Lets make the math easy... lets say you got every light in the house on - and your burning 1000watts.. You have some major floodlights ;)

For 1 hour, at .12 cents per kwh (average in the US).. that would be $0.12... So that extra 17 minutes of off time would be saving you a whole 3.4 cents... I can not image anyone using close to 1000 watts of "lights" especially these days of led lights.. So your talking talking what maybe a penny of savings, maybe ;)