@johnsoga IF it's a documentation issue there's a Give Feedback link at the top of every page. redmine.pfsense.org is where bug reports or feature requests go. @johnsoga said in DNS Resolver Returning Unknown IP: Having to edit the config file seems a less than ideal way to handle it I get your point, but (again, assuming) I'd think most people would start with WAN and LAN, then add more NICs, and not just disable LAN and start using other interfaces instead. The other way would be to move one of your other interfaces/networks to igc0/lan...but not by reassigning opt1, by setting the subnet and moving the patch cable. It would also be confusing to document and explain <lan> is not "LAN." I just ran into the renaming because we combined two small routers with one with more interfaces, and I realized opt1 was imported as the Hurricane Electric interface, so OPT1 was opt2 internally, OPT2 was opt3, etc., and I could see that being confusing years from now. So I made HE opt10.

Still reading here. I forgot that I already have an account here.

@Zoidman If they are specific computers, and they all had dynamic DNS client software, you could allow just those dynamic DNS hostnames, via an alias in pfSense. Otherwise yes it's possible to allow IP blocks, though that allows anyone on that ISP to connect. AS for hardening, installing security updates for the DNS server is obviously paramount. You could also run Suricata, on WAN in your case since they would be connecting to the WAN IP.

Old post, but anyways I post my discoveries here. To surrpress an option the easiest way is to add it to the send options under advanced. For option 12 add host-name "", option 61 add dhcp-client-identifier ""

@JASAudiovisual Usually it's a factor of the number of leases to display/download...? FWIW I pulled up one of our data center routers which should have zero since DHCP is disabled, but has exactly one, from when I restored the config to a new router. I guess the leases file didn't get overwritten...? Anyway, it's basically instant to display the page.

@Gertjan I don't know your setup but given the bag - https://redmine.pfsense.org/issues/5413 - and many, many posts around Unbound DNS on pfsense, it is fare to say that it is not stable. Issues with restarting cache, unnecessary server restarts every time there is a client renewing IP with DHCP server and more. It has been years since the issue first was diagnosed and only recently pfsense team has resources to fix it. We all hope that this will happen soon. For me it is not an issue since I have decided from day one that from the architecture point it makes more sense for me to run Unbound on a separate box - on enterprise LAN that is what you would want to do. If needed I complie Unbound from source myself when new fixes or version is posted. Many people dont want to do that and thats fine. I like that separation on my network.

@the-other, I took at look at the documentation and found configuration mistakes which were based on a youtuber suggestion. I made those changes and saved it. During that time logged into pfsense, I notice moving from one menu to another was very very slow. I was wondering if it was my new system or it just needed rebooting after the latest update was automatically applied. So, I rebooted the system with the corrective actions on pfsense configuration instructions. Boom, problem solved. Thanks to you and all others that lent a hand on my problem.

@remi_imer Where are the (DHCP) logs ? ( I know, they are in your pfSense, I'm not sure if some one can come over) Here : System > Advanced > Networking and check [image: 1691671657720-30ad5fdc-c67f-484d-976c-22a033b66d85-image.png] Now, redo your connection. Look at the DHCP logs. The interesting ones are from dhcp6c where c stand for client (the one who lives on the WAN) : Example : [image: 1691671736744-74df70cf-b858-4706-a949-916f2d7b5a9a-image.png]

Sorry for necroing an old thread but I have the same exact issue now but this time with a totally different ISP. What the hell is wrong with this. As long as the connection is CGNAT, unbound resolving intermittently works. I'm really tired of troubleshooting this. @johnpoz do you still have any ideas?

@Denada said in DNS: When I try with nslookup on cmd It cannot pass traffic to 10.1.0.1 Are you saying this box can not lookup fqdn in your internal.company.com? How would pfsense know what dns to ask for these records. If you want pfsense to lookup something off an internal dns, you would need to setup a domain override to tell unbound where to go ask.

@johnpoz We've managed to get some more IP addresses so our plan is to stop using CNAMEs on public addresses. Hopefully that will change things for the better. Thanks.

@johnpoz said in pfsense unifi dhcp problem DHCPREQUEST / DHCPACK vs DHCPDISCOVER / DHCPOFFER: Ah -- you prob need to switch to the legacy interface to change the network name. Ha! Yes. I flipped back to legacy, made the change and then found my way back to the new interface. Now it's the way I want it. Thanks! [image: 1691074732933-networks2.png] SOLVED! --- Lobanz

@johnpoz said in Buggy DNS behavior: There is a big difference in the diagnostic gui dns lookup, and a client only asking unbound.. Yes I agree and that is why I already earlier wrote that it seems like expected behavior, but even so, it keeps surprising me DNS Resolution Behavior is set to what you show: Use Local DNS (127.0.0.1), ignore remote DNS Servers. Forcing the use of the Resolver that is configured for DoT. I would personally use the dns lookup in diagnostic to also check my dns setup in general (packet capture, see if there are leaks or issues). It's just strange to see the unexpected regular dns packets and even more because the diagnostic tool is most likely generating them, but not even using them for dns (as told in my previous post). The packets show the DNS request for what was entered. Anyway, I will focus on clients connecting to unbound for now and make sure everything there is as expected, for whatever reason this is a choice pfSense made and is just confusing me (but I also might be easily confused).

@macj72x Also, this issue could exist with version 2.6.0 ..... which is outdated as 2.7.0 was made available last month. Hit upgrade and the issue will auto resolve ;)

@luquinhasdainfra said in DNS Resolver security implications: But why do i have to disable DNSSEC when forwarding? A clean, short and precise anwer exists already on this forum, here in the DNS forum. The most smallest answer (more a declarartion) is : When you forward, DNSSEC is not for you. DNSSEC needs the resolver (the function you out sourced) to resolve from top to bottom. A bit longer : Consider a DNSSEC enabled domain : https://dnsviz.net/d/test-domaine.fr/dnssec/ (I 'own' that domain name, as the used domain name servers). At the top is the current DNSSEC root key. the one with the id=20326. This root certicate signs the root servers. The root servers will give you the TLD '.fr.'in this case. The TLD's are signed by the root servers. The TLD will give you the two (my own) domain name servers. These have records signed by the TLD server. In parallel with the classic record A (or AAAA) resolving, the DS key info is also resolved. The certificate chain has to match all the way. If it works out, a flag indicates that the DNS answer 'rock solid'. dig test-domaine.fr +trace +dnssec Btw : 1.1.1.1 does DNSSEC checking. You 'only' have to trust that they didn't 'lie' to you when they answered you. Doing your own DNSSEC tests in parallel yourself (by unbound) removes completely the one and only advantage they offer : an answer a bit faster.

@TampertK Thanks, I'll check them out. I had already googled and found quite a few threads, but they were all a couple years old referencing earlier versions. And the possible fixes in them didn't apply to me other than installing Watchdog. I thought maybe it could be due to an update, but I installed 2.7.0 because I was having issues with losing internet here and there overnight. I didn't realize it was the Resolver crashing until after the update, so I'm not sure if it was the same culprit prior to 2.7.0.

@larslindnilsson said in Default DNS not sent in DHCP packages to client: I just did a new install of pfSense and in the Wizard step "DNS Server Override" was checked. So it's me miss understanding /conf.default/config.xml : <?xml version="1.0"?> <pfsense> <version>22.2</version> <lastchange/> <system> <optimization>normal</optimization> <hostname>pfSense</hostname> <domain>home.arpa</domain> <dnsserver/> <dnsallowoverride/> The last line actually means : the option is checked (active) When I check it myself : <dnsallowoverride><dnsallowoverride/> When unchecked, there is no "dnsallowoverride" present in the config.xml file Not sure if this default config xml actually gets used, as using option 4 "Reset to factory defaults " in the console/SSH downloads a pfSense package that probably also contains a default config. Anyway : when resolving, the DNS given to pfSense from the upstream ISP router, or ISP itself :=> don't care ^^

@Xorfora-0 Disregard. I recreated my API token, and it resolved the issue. Strange, but it's resolved.