Thank you John

@johnpoz It works like a charm. Thanks a lot

@mkcharlie said in Cannot resolve one specific host: actauni.com nslookup on my pfSEnse : [22.05-RELEASE][root@pfSense.local.net]/root: nslookup actauni.com Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: actauni.com Address: 185.45.67.217 nslookup on a PC : C:\Users\Gertjan>nslookup actauni.com Serveur : pfSense.local.net Address: 192.168.1.1 Réponse ne faisant pas autorité : Nom : actauni.com Address: 185.45.67.217 Btw : 192.168.1.1 is the IP of my pfSense.

@kjemison1966 FYI : It's mostly found in WIFI controlled Network same hostname of devices: Reason: Large no of IP blocks like (10.0.0.0/16) Your firewall not running in all day (open and close in office timings) due to this IP leases is not cleared properly. Solution: Use Subnetted IP as per requirements 2.Make your DHCP lease expire in a short time duration These solution is for dynamic DHCP leases only. Thanks

@johnpoz That was it! Thanks for the help!

@deanfourie hey there, the "downside" is exactly what you mentioned: cannot see what's being queried, so no dns-based filtering of let's say advertisement, porn, known malicious sites...no pihole, no pfblocker dns-filtering... And that's a bummer for many users (including me). :)

@johnpoz said in Cloudflare "reserved IP" records not resolving on pfSense DNS server: are you using the opaque app as well for spice console access No, I'm just using the normal vnc via the proxmox app. @johnpoz said in Cloudflare "reserved IP" records not resolving on pfSense DNS server: using just a full browser on my PC Connecting to a console via a browser on a PC works fine with or without a certificate. The app requires that you turn on SSL validation to connect to a console via the app itself. I've resolved this issue by using a DNS override.

@johnpoz Thanks for the information. I'll use resolver, I mostly get what you're getting at. I'll have to do more studying on networking perhaps to understand some of these things better. The help is appreciated!

@coyote1abe said in DNS over TLS Not Working?: could you please be a little more specific about the change you made to system Somewhere in the past, he changed the IP settings of his device ( a Windows PC ) from the default DHCP settings to a static setting. Like this : [image: 1659682406226-d3577074-a66d-4dc6-9d2a-47fe70abc2e1-image.png] which means this windows device doesn't use pfSense at all for DNS .... because he asked 1.2.3.4 to be used. He has undone that, and now all is well.

@jrather said in Unable to resolve kali.download: it referred enabling DNSSEC when using the root servers directly If your are forwarding to anywhere on pfsense, then yeah dnssec shouldn't be enabled - where you forward either does dnssec or it doesn't. That setting really only has any real use if your actually resolving, ie talking to roots. If your forwarding then that setting is more likely to cause issues than anything else. Both those records are not dnssec signed anyway, and I use dnssec since I resolve.. And not having any issues resolving it.

@falassion j'ai aussi le même problème, est ce normal que le service DHCP s'arrête à chaque fois?

@tyler-0 said in DNS is sporadic: DNS seems to get funky. I haven't put any DNS options within PFSense, Good ! Oh ... wait : @tyler-0 said in DNS is sporadic: On the Interface itself, I left the DNS Options blank. I've also tried 8.8.8.8, 8.8.4.4 and the Open DNS Ips. Still seem to have the same issue. What about : Do not change any Unbound resolver settings - like None. And keep this list empty : [image: 1659335396688-b2ea5076-d10e-4e7c-b5d7-e3b842c8d9ac-image.png] Now you have a default working setup. Keep in mind : Netgate wouldn't chose a default installation that doesn't work. Also check on your LAN devices what DNS is actually used. Like : C:\Users\A-PC>ipconfig /all .... Serveurs DNS. . . . . . . . . . . . . : 192.168.1.1 2001:470:1faa:5c0:2::1 .... Now I know that 192.168.1.1 and 2001:470:1faa:5c0:2::1 are the LAN IP of my pfSense. On pfSEnse, unbound listens on that LAN interface, and handles everything from teher. Works great for me for the last 10 years. It would stop working if Internet's DNS system goes down. That never happened as up to 2022. You will only see issues if your uplink (ISP) is 'bad'. Mine isn't - or very rarely.

I have a very strange update to this, which I cannot explain. I decided to create a test custom DynDNS entry and pointed its URL to my local web server. First I served just a text file with my IP and in the Result Match field I put %IP%. It worked and I got phpDynDNS (): (Success) IP Address Updated Successfully! Then I started to add some text, kept the hard-typed IP and placed the same text and %IP% instead of the IP into the Result Match field. It all worked. I came to the point where I put the exact Namecheap string into the file served by the web server, the one that never matched. But it matched this time. Then I went to the real DynDNS entry that never worked, put the same string into the Result Match field and it matched the Namecheap response this time. It's weird. I compared the response to the old one that was still sitting in my opened browser and they were exactly the same including headers. I usually don't type what I can copy/paste, so I don't think it was typing error.

@bmeeks No problem, I hope my changes will help all users to have access to those new features asap. In France we must use raw-options to get IPv6 and some people prefer to use OpnSense instead of pfSense because of that. At least, developpers should consider to update this package if its not my PR. https://github.com/pfsense/FreeBSD-ports/pull/1181

I suppose a workaround would be to make a DHCP pool with one IP address and limit that pool's use to MSI's mac address? In this way, MSI wouldn't have a static DHCP mapping, but it would always get the same address, correct?