@marchand-guy Since DNSSEC was mentioned above, just note it should be disabled when forwarding. https://support.quad9.net/hc/en-us/articles/4433380601229-Setup-pfSense-and-DNS-over-TLS "Disable Enable DNSSEC Support if enabled. DNSSEC is already enforced by Quad9, and enabling DNSSEC at the forwarder level can cause false DNSSEC failures."

@Gertjan said in Dns resolver problem: showing the user that he wanted to visit a blocked web site is impossible Never say that ;) But yeah its pretty freaking difficult to do with https, you would have to generate on the fly a cert that matches where he was wanting to go www.somewhere.tld and also that browser would have to trust the CA that created said cert on the fly. And if the site was using something like pinning, and he had been there before - again he prob going to scream at you that this cert isn't right, etc. If it was easy it would really break the whole end to end trust thing ;) its not impossible but yeah the client is doing everything it can to know that the https connection is trusted and secure from the client to the server.. Now if you control the client and get him to trust certs you create, then sure pretty easy to do mitm.. But it also become resource hungry creating certs on the fly for any fqdn the client might be going to.

@johnpoz I don't know :( I thought let me give it a try, that NULL IP thing is so random.

@viragomann the problem is I have no idea which DNS each client is using. Some use ISP DNS, others Google, others OpenDNS, others quad 9.. and so on. And some clients are from others countries.. In this case, i think the best option is let the clients use internet through VPN. Thanks for your help. I really appreciate it!

Update-> I was able to resolve the DNS issues as stated above by selecting DNS Resolution Behavior = Use Local DNS (127.0.0.1), fallback to remote DNS servers (Default), and, thanks to @viragomann's comment about enabling the DNS query forwarding mode in the DNS Resolver settings, I am finally getting somewhere! Now- I have two DNS addresses for my VPN (PIA), and two DNS addresses for my WAN (Cloudflare's DNServers), and the correct Gateway is selected for each. Now when I conduct a DNS leaktest, it shows me pfSense is resolving to both Cloudflare and to the PIA DNS addresses...? Firstly, I'm just happy that my ISP's DNS is no longer being resolved. Secondly, I guess I'm wondering if DNSleaktest.com is showing both because different devices on my LAN are using different gateways to resolve DNS queries or is it that my device which is being directed to use the VPN(PIA) gateway is actually resolving to all of the DNS addresses? I'm hoping it's the former and not the latter! Thanks.

@DavidIr I just tried configuring Azure DNS in Dynamic DNS and I am seeing the same. I am on version 23.05-RELEASE. The record exists already in the zone, I am trying to get pfsense to keep it up-to-date. Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Dynamic DNS azure (test.<mydomain.com>): _update() ending. Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Dynamic DNS azure (test.<mydomain.com>): _checkStatus() ending. Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: phpDynDNS (test.<mydomain.com>): (Unknown Response) Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: phpDynDNS (test.<mydomain.com>): PAYLOAD: 400 Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Dynamic DNS azure (test.<mydomain.com>): _checkStatus() starting. Jun 3 16:32:37 php-fpm 13896 </html> Jun 3 16:32:37 php-fpm 13896 </body>\x0d Jun 3 16:32:37 php-fpm 13896 </div>\x0d Jun 3 16:32:37 php-fpm 13896 at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)</p>\x0d Jun 3 16:32:37 php-fpm 13896 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)\x0d Jun 3 16:32:37 php-fpm 13896 at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)\x0d Jun 3 16:32:37 php-fpm 13896 at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)\x0d Jun 3 16:32:37 php-fpm 13896 at System.ServiceModel.Dispatcher.DispatchOperationRuntime.DeserializeInputs(MessageRpc& rpc)\x0d Jun 3 16:32:37 php-fpm 13896 at System.ServiceModel.Dispatcher.UriTemplateDispatchFormatter.DeserializeRequest(Message message, Object[] parameters)\x0d Jun 3 16:32:37 php-fpm 13896 at System.ServiceModel.Dispatcher.DemultiplexingDispatchMessageFormatter.DeserializeRequest(Message message, Object[] parameters)\x0d Jun 3 16:32:37 php-fpm 13896 at System.ServiceModel.Dispatcher.SingleBodyParameterMessageFormatter.DeserializeRequest(Message message, Object[] parameters)\x0d Jun 3 16:32:37 php-fpm 13896 at System.ServiceModel.Dispatcher.SingleBodyParameterDataContractMessageFormatter.ReadObject(Message message)\x0d Jun 3 16:32:37 php-fpm 13896 at System.Runtime.Serialization.Json.DataContractJsonSerializer.ReadObject(XmlDictionaryReader reader, Boolean verifyObjectName)\x0d Jun 3 16:32:37 php-fpm 13896 <p> at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName, DataContractResolver dataContractResolver)\x0d Jun 3 16:32:37 php-fpm 13896 <p>The server encountered an error processing the request. The exception message is 'There was an error deserializing the object of type Microsoft.WindowsAzure.Dns.Frontend.Common.DataStructures.API.Dns.CsmResourceRecordsPackageBody. The value '' cannot be parsed as the type 'Int64'.'. See server logs for more details. The exception stack trace is: </p>\x0d Jun 3 16:32:37 php-fpm 13896 <p class="heading1">Request Error</p>\x0d Jun 3 16:32:37 php-fpm 13896 <div id="content">\x0d Jun 3 16:32:37 php-fpm 13896 <body>\x0d Jun 3 16:32:37 php-fpm 13896 </head>\x0d Jun 3 16:32:37 php-fpm 13896 <style>BODY { color: #000000; background-color: white; font-family: Verdana; margin-left: 0px; margin-top: 0px; } #content { margin-left: 30px; font-size: .70em; padding-bottom: 2em; } A:link { color: #336699; font-weight: bold; text-decoration: underline; } A:visited { color: #6699cc; font-weight: bold; text-decoration: underline; } A:active { color: #336699; font-weight: bold; text-decoration: underline; } .heading1 { background-color: #003366; border-bottom: #336699 6px solid; color: #ffffff; font-family: Tahoma; font-size: 26px; font-weight: normal;margin: 0em 0em 10px -20px; padding-bottom: 8px; padding-left: 30px;padding-top: 16px;} pre { font-size:small; background-color: #e5e5cc; padding: 5px; font-family: Courier New; margin-top: 0px; border: 1px #f0f0e0 solid; white-space: pre-wrap; white-space: -pre-wrap; word-wrap: break-word; } table { border-collapse: collapse; border-spacing: 0px; font-family: Verdana;} table th { border-right: 2px white solid; border-bottom: 2px white solid; font-weight: bold; background-color: #cecf9c;} table td { border-right: 2px white solid; border-bottom: 2px white solid; background-color: #e5e5cc;}</style>\x0d Jun 3 16:32:37 php-fpm 13896 <title>Request Error</title>\x0d Jun 3 16:32:37 php-fpm 13896 <head>\x0d Jun 3 16:32:37 php-fpm 13896 <html xmlns="http://www.w3.org/1999/xhtml">\x0d Jun 3 16:32:37 php-fpm 13896 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">\x0d Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Data: <?xml version="1.0" encoding="utf-8"?>\x0d Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: date: Sat, 03 Jun 2023 14:32:37 GMT Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: x-ms-routing-request-id: GERMANYWESTCENTRAL:20230603T143237Z:62223bf7-3bc2-40d0-ba3a-8f0576793a0c Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: x-ms-correlation-request-id: 62223bf7-3bc2-40d0-ba3a-8f0576793a0c Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: x-ms-request-id: 62223bf7-3bc2-40d0-ba3a-8f0576793a0c Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: x-powered-by: ASP.NET Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: server: Microsoft-IIS/10.0 Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: x-ms-ratelimit-remaining-subscription-resource-requests: 11999 Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: strict-transport-security: max-age=31536000; includeSubDomains Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: x-content-type-options: nosniff Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: content-type: text/html Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: content-length: 3221 Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: cache-control: private Jun 3 16:32:37 php-fpm 13896 /services_dyndns_edit.php: Response Header: HTTP/2 400 Jun 3 16:32:35 php-fpm 13896 /services_dyndns_edit.php: Dynamic DNS azure (test.<mydomain.com>): _update() starting. Jun 3 16:32:35 php-fpm 13896 /services_dyndns_edit.php: Dynamic DNS (test.<mydomain.com>): running get_failover_interface for wan. found pppoe0 Jun 3 16:32:35 php-fpm 13896 /services_dyndns_edit.php: Dynamic DNS azure (test.<mydomain.com>): <myip> extracted from local system. Jun 3 16:32:35 php-fpm 13896 /services_dyndns_edit.php: Dynamic DNS azure (test.<mydomain.com>): _checkIP() starting. Jun 3 16:32:35 php-fpm 13896 /services_dyndns_edit.php: Jun 3 16:32:35 php-fpm 13896 /services_dyndns_edit.php: Dynamic DNS: updatedns() starting Jun 3 16:32:35 check_reload_status 436 Syncing firewall Jun 3 16:32:35 php-fpm 13896 /services_dyndns_edit.php: Configuration Change: admin@192.168.20.199 (Local Database): Dynamic DNS client configured. (private info redacted from logs)

@SteveITS I used the second option you mentioned. But the problem is that the "domain override" was not working. As @viragomann mentioned, I needed to set the Active Directory DNS in "General Setup" and activate forward option in the DNS Resolver. After that, I configured the OpenDNS IP (208.67.222.222) in the Active Directory forwarder. Everything is working now, including the NAT rules that were conflicting.

FYI, everything is working. After additional checks, it was necessary to activate the DNS resolver like this: [image: ehpi.png]

@Johan1974NL If this device is somewhat recent and a wifi device, and uses the MAC randomizer, this will mean it will use a random IP also. Because : as soon as the MAC changes, the IP changes. Blocking a moving target : hummmm, that's a no go. The only feasible option is : bloc 'something' for the entire LAN using the option Dobby_ listed.

@GameHoundsDev I’m not sure actually. So it didn’t work recreating the interface with a /24 mask?

It seems DHCP/PXE implemention is somehow broken in current v 2.6.0. In my setup there is no any VLAN, but EFI machines are requesting "BIOS" boot file from TFTP server. I think it worked normally in some previous version.

@jamesjose03 What is a VM here, pfsense and some other guest - just pfsense? Just some guest vm you have running on what proxmox, esix, virtualbox, hyper-v, qemu ? What are you restarting exactly? The dns that is provided by dhcp - your saying pfsense is not handing that out? In the dhcp offer? Did the client ask for it? Lets see your dhcp packet capture.. Example - here is a dhcp exchange.. [image: 1685370384123-dhcpjpg.jpg] You can see in the discover and request client asking for dns, and in the offer and ack the dhcp server sending the info. So your saying even though the dhcp client asks for dns - the dhcp server is not sending it? But then you restart "network" which means what exactly? Reboot the vm, reboot the host, disable enable some interface either physical or virtual? Some other network reset in the os like "netsh int ip reset" in windows?

@KimbleWorshack Great that you could resolve this. 23.05 seems to fix all other bugs for me aswell.

@mohsh86 i registered an account just to say thank you for this!

Just this one : @ibbetsion said in When trapping rogue DNS requests, logging looks strange: That means family will scream at me for X device not working That's the ever ongoing discussion between "you and the others". You : want to protect the entire network, and also from the others hurting themselves and/or your LAN. You don't want them to shoot in their own foots. Everybody knows all about security and that they should be careful .... and then they tap on the "Install tiktok" button. Life is hard, .... but we keep on smiling.

@scorpoin said in unbound stop after pfblockerng upgrade: @jdeloach Thanks for your prompt response, list indeed has not been updated except pkg it self. As I mentioned that this behavior occurred right after pkg upgrade. Cront job start at 12Pm and its been running till now 3:20Pm still running at TLD finalizing....... and service of unbound stopped so I had to start it manually . How do I fix this or find out root cause of this behavior to resolve it. DNSBL status on main dashboard turn yellow out of sync as well. Regards This has been an issue for a long time for some folks, myself included. It seems to occur most often when one has a lot of large block lists. The maintainer, @BBcan177, was aware of it and I thought Netgate had come up with a fix for it but I guess it is still happening.

@kenw said in Intermittent DNS Falure: @steveits Thank you so much for your help in better understanding how DNS in pfsense works! I have made the following changes and will monitor the results over the next few days. 1/ System Domain local Zone Type: Transparent (unchanged) 2/ Enable DNSSEC Support: UnChecked (changed) 3/ Enable Forwarding Mode: Checked (changed) 4/ Use SSL/TLS for outgoing DNS Queries to Forwarding Servers: Checked (changed) 5/ Register DHCP static mappings in DNS Resolver: checked (unchanged) I also checked system logs for unbound restarts and saw only 3 in the month of April. System has been running without problems for 2 weeks after applying the above changes. problem seems to be resolved.

If you're running 23.01, it's likely this bug we fixed in 23.05: https://redmine.pfsense.org/issues/14091