Thank you! I'm not sure how I missed that tab.

@bmeeks said in pfSense DHCP + Windows DNS, Reverse Lookup Problems, No PTR Records Being Created: When DHCP is implemented, by default the PTR Records are registered to DNS by DHCP Server, whereas the Host (A) records are registered by DHCP client. This is due to the fact that client is the source of the hostname and DHCP is the source of the IP address. This is interesting, but I have enabled client PTR registration in all Windows machines, so that is resolved. All other clients are non-Windows and therefore non-Active Directory so not an issue. Despite that, I have exported the host list from DHCP to DNS and created PTR records for my non-Windows clients such as my Android phone, watch, kindle etc. Everything is working fine now. Its all sorted............ Thanks

@stewart rebind has all kinds of serious issues with it https://en.wikipedia.org/wiki/DNS_rebinding It is never a good idea for anything other than a local domain to resolve to rfc1918 space. If you have some fqdn that is going to resolve to rfc1918 space you need to take the appropriate action on unbound config to let it know this is not a rebind issue. Private domain setting for example. Plex users have to do this for their plex.direct domain since it an external dns that resolves to your local IP of your plex server.. The plex example isn't saying that its a good idea to do that - its just a way they are leveraging ability to do SSL with users different dns, etc. Rebind is not the best way to do that - but it is the way they did it - so you have to make exception for it in your overall rebind protection. If you have something else doing something where it returns rfc1918 you just have to let unbound know, so it it doesn't think its a attempt at rebind.

@gertjan Everything works now. Thanks for all the help.

^ exactly - I even pointed out private domain. disable rebind for the everything is a bad idea

@john80 You need to put a static IP address on the LAN interface, then configure DHCP server. You should not run DHCP on WAN... That would provide IP addresses to the Internet... How are you connecting to pfSense? On LAN? Your other post said you "added" a LAN interface...

@hubs04 This scenario and failure mode is not good at all. Why would unfiltered results be a valid failure mode? If your concerned with where your running your filtering failing - that make sure if 1 ns fails there is another that does the same filtering If that fails - I would want to know right away - so I can fix it - or just point unbound to different NS or just let it resolve if my filtering is down. Vs a scenario where my filtering is not working and I don't know about it, they you have say a kid looking at porn, or infecting your network with malware.. How exactly does unbound flip to this other NS - 1 query fails, 10, what if one query just takes a long time? When does it fail back - does it not? So no you run into a scenario where again you do not know what is being asked - your filter system, or not filtered. Which is a horrible scenario.. The only time you should switch to non filtered, is your sure - I you actually tested, yup if broke - and I can not fix it in 2 minutes. So flip users over to nonfiltered in 10 seconds. There is no way to do your "only" if scenario that makes any sense - if your worried about your filtering system fail - then make sure it doesnt.. That is where time spent on what happens if fail mode should be concentrated..

@ashkaan said in Improving DNS Cache: Continuing to query for something that no one wants anymore is exactly what I'm looking for. And you get it in your head to do such nonsense and then the next guy as well and the next guy as well.. And next thing you know you have millions of queries a second for stuff nobody is actually wanting to look up. If not 10's of billions.. Prefetch and serve zero will mean your clients get served from cache.. As long as some point in the past that thing was asked for and in the cache.

@gertjan said in Need help with DNS: What IP are they getting as their DNS IP ? [image: mEfcIAt.jpeg] @gertjan said in Need help with DNS: If there is nothing, it will be the IP of the pfSense LAN. ? DNS Server fields are empty in the DNS Server setup. DNS is set to the IP of the Router in these devices. @gertjan said in Need help with DNS: This means the devices on LAN will send their DNS request to pfSEnse, and the forwarder will centralize the DNS request, forward them to 1.1.1.1 or 8.8.8.8 if the answer wasn't cached. This is what I thought, but it's not happening.

@beefer so I think I somewhat solved the issue. My Site A DNS Resolver was configured with selected interfaces as 'Outgoing network interfaces'. When I changed back to 'all' all of the sudden all queries are blazingly fast - even RTO's. The only thing I don't understand is why it helped. First - I'm in forwarder mode for unbound - shouldn't this setting affect only root dns queries? Also why it was slow is still a mystery to me - perhaps it was doing round robin over those interfaces and got stuck on waiting for answers?

@scorpoin said in DNS issue local webserver resolve with public IP: May be but how do I prevent DoH of browser . Any idea There might be better places to ask this. It depends on the browser naturally. For instance Firefox: https://support.mozilla.org/en-US/kb/firefox-dns-over-https

I just posted dhcpcsv2pfsense V1.0 which supports loading static assignments to multiple VLAN DHCP servers. https://github.com/cjnaz/dhcpcsv2pfsense

@rossm said in Unbound not resolving quad9.net nameservers: if I made a firewall rule blocking all outbound port 53 traffic, would that block unbound or would it still be able to resolve addresses using DNS port 53? If you did it on floating and outbound direction, then that blocks all 53 going outbound.. Doesn't matter what processes was creating the traffic.

@jlrith This is solved... Sort of. I left the setup running for about an hour and the problem resolved itself... Pfsense now picks up the proper WAN ip address with no problem. It's weird because I had let it all sit overnight and there was no change. I had previously moved connections and other computers and NICs had no problem picking up the ip address through DHCP. Pfsense never could. Go figure.

UPDATE: This is a fundamental problem on this NGFW , since, if I keep the port alive with say WOL , I don't have this Unbound stop problem of course, it's not mind-blowing, but it's damn confusing when only one device is directly connected to a pfS port (eth) solution on Ubuntu Focal Fossa (in short): sudo apt install ethtool sudo ethtool enp4s0 sudo ethtool --change enp4s0 wol g sudo systemctl daemon-reload sudo systemctl enable wol.service +++edit: this was an unpleasant discovery (on pfSense) :(

Could you provide client log also? It's better to create a bugreport: https://docs.netgate.com/pfsense/en/latest/development/bug-reports.html