@rchiocchio Keep that NAT disabled, you don't need that. You are allowing only TCP traffic, DNS most of the times uses UDP, try to change that rule from the IPsec tab to TCP/UDP and test again.

@gertjan hello there Yeah, I'm puzzled too. I just can't prove if its from our huawei core switch or from pfsense itself. But I don't see any documentation regarding huawei having that domain.. I already escalate it to huawei TAC and they just said this "if 172.1.83.10 is the address of HW switch, switch just replay a icmp packet, will not take these information (lightspeed.moblal.sbcglobal.net), and it is the behavior of PC." and base from this forum, I think no-one yet encountered this ghost domain with their pfsense, so I think its not really the pfsense causing

@juergenbrandstaetter said in How to configure Dynamic DNS with unsupported DNS provider: In my case I my providers router works in bridge mode, and my WAN interface is configured as DHCP -> so I guess it should recognize, if the IP changes Not recognize If you use a DHCP client on your WAN interface, this client will initiate a DHCP lease request as soon as the WAN interface comes 'UP'. The ISP, with it's DHCP server, will give the client an IP (your WAN IP), a gateway, maybe a DNS or two. A DHCP lease has always a duration, like 24 hours. So, half way that duration, the DHCP client will wake up, and request for an DHCP lease 'extension'. It will of course suggest that it likes to keep the actual (WAN) IP. The ISP DHCP server can grant that lease extension, or so, "NO, now you get a new IP (WAN)". The WAN IP changes (or not) a "interface event" is fired, and this will affect all processes that are "bound to" these interfaces, so that these process can be made aware that an IP on some interface changed (or not). On of these process is : the DynDNS. It has stored the (now past) WAN IP in a file, it will compare it with the actual WAN IP, and fire up a dyndns update if the tow are different. And it will update the file with the current WAN IP for future events.

@viragomann Yes, the same chip celeron N3060. By default pfsense listen in all interfaces under DNS Resolver. Them I'm not alone. My felling is that is related to N3060 electronics. Them have discover something else about this issue?

@viper_rus Close thread, problem solved

@mctechsolutions pfSense on its own can only redirect IPs and ports. It cannot read a host header in a HTTP request if that's what you're purpose. If you want to redirect traffic on host name basis you need to install and configure the HAproxy package.

@adamitj DoT requests which are redirected to another server won't work anyway, because the SSL verification will fail. Therefore I simply block all DoT and DoH in my network. Hence the clients have to do unencrypted DNS requests, which I can redirect as needed.

@bingo600 The issue was your first quote... I feel dumb right now, I'm highly appreciated for your help.

@nhscan My best suggstions are : 1: Create a dedicated IoT Lan/Vlan , and do the Internet Access , blockking there. 2: Make your IoT "Internet Access" block rule, use an Alias for the matching source IP's. Then it's just a matter of adding the newly created IoT IP, to the Alias. I would recommend 1 , as you can do a Lan/Vlan wide block. And it doesn't matter if the IoT "thingy" pull's another DHCP IP by "mistake". /Bingo

@thisisme I did some tests and these are the results: Unbound will look up all configured DNS Server in parallel. So it also uses the DNS Server configured with the WAN Gateway. If I use package capture there is no traffic for port 53 on my WAN Interface. If if disable forwarding mode in unbound I pass the dns leak test. Can I assume that's still safe to use forwarding mode, because the traffic seems to be on VPN Interface only?

Issue reported on redmine: https://redmine.pfsense.org/issues/13719 Figured out what was causing the error. It seems to be caused by the pfBlockerNG-devel package. I had a second router I was setting up and checked the DHCP server functionality after every change. Everything worked fine until I installed the pfBlockerNG-devel package. Uninstalling it does not remedy the issue either. A full factory reset is required. Package specifics pfBlockerNG-devel Version: 3.1.0_11 Workaround You can reconfigure the interfaces and DHCP Servers via console to the box. Had no issues making changes via console and all of them took.

@camg If you can run your own Unbound DNS on separate machine you will not be having all these issues. I have Synology NAS and I compile and build my Unbound straight from Unbound repo. Current version 1.17. It is a solid solution is you can do this. Problem with pfsense including Unbound is that there is no way a user can update just Unbound itself. Over this year Unbound released 4 version. You are always behind if you use supplied Unbound binaries with pfsense. I have used that typo of architecture (separating Unbound DNS) for years. Never had any issues. For these people that use pfBlocker - you can do all domain blocking just using Unbound RPZ. Its easy .

@ahking19 said in PFSense DNS cannot resolve outlook.ha.office365.com properly: @tdixler Check Domain name outlook.ha.office365.com, and type as HTTPS<< HTTPS is not a valid DNS query type. Valid query types are - A, AAAA, CNAME, MX, NS, etc) Are you confusing with DNS-over-HTTPS (DoH)? Hmmm ... See: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-01#section-12.2 Right now it seems like Apple IOS > 14.x, is using this type of queries. Yddrfff .... DoH bypassing (resolver selection) https://support.opendns.com/hc/en-us/articles/360049861971-DNS-Resolver-Selection-in-iOS-14-and-macOS-11

Thanks all. So my solution is to know that my workaround was the solution :)

@crichmon I do not know how to convert. Only GUI interface.