I figured it out - I should not put my authoritative server under the domain override section because unbound put it in a forward zone and expects a dns resolver. Instead, I switched to a stub zone under custom configuration, which requires an authoritative dns server and unbound will perform recursive lookup itself.

@johnpoz All I needed was a quick and dirty fix because it is not going to be the production set up. I did the fix late yesterday but it was about 10pm and if the quick and dirty was going to fix it, it was good enough for me. I only tested it this morning.

@swampland7794 I changed the DNS address to 1.1.1.1 and changed the subnet... I messed my home network and I don't have access. I'll fix it when I get home tonight and we'll see if that resolved my issue.

@ASGR71 putting a block rule to 53 just below the rule you allow 53 to pfsense IP would be a valid solution if you want to block clients on that network from talking to any normal dns on the internet.

If you are having issues with clients using dns other than pfsense. While that rule would block normal dns, it doesn't prevent clients from using doh (dns over https) or dot (dns over tls).. while dot should be easy to prevent since the standard part is 853.. And clients don't normally use dot. A forwarder would use dot to forward to some other resolver via tls.

Blocking clients from using their own dns to circumvent local dns has become an uphill battle.. Browsers deciding to use doh on their own without explicit opt-in by the user is a problem.

Blocking doh is becoming a challenge. Since it uses standard 443 port of https traffic - which is pretty much everything on the internet these days. Blocking this has come down to using lists of known doh servers and blocking the IPs.. Which can turn into a wack-a-mole game..

But if you just want to prevent some client talking to say 8.8.8.8 or quad9 or 1.1.1.1 on 53, etc.. then yeah that 2nd rule accomplishes that.

@ericafterdark I'm actually one of the authors of ctrld. If you're into fancy DNS routing, you may dig this article on how to use ctrld with pfSense, and what you can accomplish with it, especially if you use Control D as an upstream. https://github.com/Control-D-Inc/ctrld/wiki/pfSense-and-OPNsense-Operations-Guide

If it's fully standalone in Unbound that should be possible, though I don't know what kind of time frame we'd be looking at.

I haven't kept an eye on it but last I saw it required passing in the https requests from something else like an nginx proxy setup but from the look of those docs they seem to have native support now. The library they mentioned is present on pfSense and is a dependency of Unbound already (the ports option DOH is enabled) so all the backend parts appear to be present, just the GUI/PHP config code would need to be implemented.

The larger problem is that it's going to want to use port 443 which complicates GUI access and makes it trickier to use in practice.

Yup, those devices are probably not trying to resolve .local addresses using DNS servers at all. They assume they are mDNS and try to find them locally.

@mebert
Consider that you have to state the remote domain if you client uses another search domain, what I assume.

So if you want to request the remote host name is "host" and its domain is "local" you need to type "host.local" to access it.

@slo-bo-dan that picture makes no sense - are you hiding the names? And the full IP?

domain overrides would be for where you want to resolve a specific domain and all its records from a specific name server..

For host overrides they need to be fully qualified, and point to a specific address - so believe your just not showing what is fully there?

Also for clients to get the host override they need to be asking pfsense for dns.. Or the nameserver clients are asking needs to then ask pfsense..

edit: Lets do a specific example, maybe that will help you understand how host override works.

you have www.domain.tld out on the public internet that resolves to 1.2.3.4.. This is your pfsense wan IP, when you see traffic to 1.2.3.4 on port 443 you send it to 192.168.1.100 via a port forward.. This is how outside your network gets there to your website on www.domain.tld

Now internal you have some client on 192.168.1.90, and he wants to get to www.domain.tld - does his dns resolve that to 1.2.3.4 or if you setup a host override on pfsense to point www.domain.tld to 192.168.1.100

If your client on .90 resolves it to 1.2.3.4 you need to setup nat reflection. If your client is asking pfsense for dns, then a host override would tell this .90 hey just got to 192.168.1.100

But if your client is using say 8.8.8.8 or 9.9.9.9 for dns directly then no yoru host override would never work.

@johnpoz Thanks again john. Decided to by-pass the whole local network and plugged the internet straight into Wireshark. Couldn't find any DNS packets! Did a factory reset and assigned Snort to the LAN interface and all is good! Thanks for your help.

@yobyot

There is one SLAAC address that does not change. Point the DNS to that address.

@aiden21c Good! I still think that some good came out of this whole situation, though.

For one, even if your current setup works well, the ideal setup for your whole company network is still with VLANs The order of the firewall rules needs to be held in mind (PfSense processes firewall packet rules from top to bottom):
1c9cfaf5-771e-4d8c-959e-e798596807bd-image.png
Rule 3 catches all traffic filtered by rules 4, 5, 6. It needs to be last. Rules 5 and 6 have destination address "Any" instead of "LAN Address". A way that helps (me personally) to keep fw rules tidy is to add 4 separators, the top one named "GENERAL BLOCK" (for entire protocols, for example, no need to allow GRE, ESP, AH, OSFP... on a LAN with interconnected servers if there is no explicit need), a second separator named "INCOMING", a third separator named "LOCAL TO FW" and a fourth one named "OUTGOING". I also add separators named "PASS" and "BLOCK", with that order, under each main separator. Even if no further network changes seem necessary, it is best to avoid NAT. In the future, in order to reduce latencies or enable certain UDP services that cannot be NATed, you can check if the Cisco Router can do PPPoE passthrough for PfSense. Because PPPoE is a separate interface in PfSense, you can have both a PfSense-to-Cisco connection (OFFICE - 192.168.20.40/24, not as a Gateway) and a PPPoE adapter as a direct PfSense Gateway (because PPPoE is a Layer 2 protocol, doesn't use IPs, that is why its Point-To-Point, so it doesn't interfere with the 192.168.20.0/24 subnet at all) with a public IPv4 for PfSense. At some point, instead of having separate rules for each gateway and traffic type, you might want to implement Multi-WAN Load Balancing and Traffic Shaping to control which traffic type uses what Gateway. It is best to set static IPs for LAN through the DHCP server (without a dynamic address pool) and set your private IPs as Static Mappings. That way, you can use Host Overrides on Unbound, which would allow you to use hostnames (and no IPs) in your setups, and avoid unnecessary config nightmares in case, say, you want to put everything in Docker. You can just change the IPs in the Static Mappings of PfSense Unbound, add a BIND container to Docker (just to handle the inter-container IPs using the same hostnames) and be done with it.

@klinger said in DNS resolution for some hosts fails, but nslookup works:

the pfSense firewall queried our central firewall for name resolution (via packet capture).

Well then you were forwarding - or that NS is authoritative for the domain you were looking up. Out of the box pfsense is a resolver, it talks to the roots down to talk to the actual NS for whatever domain your looking for.

So no out of the box pfsense would not query some NS on your network.. Unless the roots and the gltd servers pointed you to them..

Out of the box pfsense is a resolver..

Hey roots, what is the NS for .com

Hey gltd servers what is the NS for domain.com

Hey NS for domain.com what is the IP address of www.domain.com

you can see this with a simple dig and a +trace, this is how a resolver works.. So why would it ask some upstream NS in your network?

[23.01-RELEASE][admin@sg4860.local.lan]/root: dig www.netgate.com +trace ; <<>> DiG 9.18.8 <<>> www.netgate.com +trace ;; global options: +cmd . 21987 IN NS d.root-servers.net. . 21987 IN NS e.root-servers.net. . 21987 IN NS f.root-servers.net. . 21987 IN NS g.root-servers.net. . 21987 IN NS h.root-servers.net. . 21987 IN NS i.root-servers.net. . 21987 IN NS j.root-servers.net. . 21987 IN NS k.root-servers.net. . 21987 IN NS l.root-servers.net. . 21987 IN NS m.root-servers.net. . 21987 IN NS a.root-servers.net. . 21987 IN NS b.root-servers.net. . 21987 IN NS c.root-servers.net. . 21987 IN RRSIG NS 8 0 518400 20230322050000 20230309040000 951 . TN/9VuM2Q8uI9vNqRDfX/si09GNyq8dHFQdBJPG7CE935u/HbanonU99 Z/mZRM2xIt9zJd8kuvWDi9t0TTLYdFaoJ4XMcQyOQZeeZM/XfLUNBkX0 YdJqjDZD3joFSHNUpKHRF/aIZhoKwRxuAqQsiK04HXrKt3SyaGnVsUy5 kXQU05Z5HEgP8ZK3ziqLD+0bRX9uYAegL+JgEEDx421apR1xN4FY6ngF VONOKheKbl6LhSp91jfkR5LhiEyAT3PMXwfQEntHAmCyBgfw05rbSZB6 vALXQDZBcWCs/pW9VEpPx4J1DpGYhgKAa7ojk8ZDgnY3kfl/H6LplGFi qme5AQ== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766 com. 86400 IN RRSIG DS 8 1 86400 20230323050000 20230310040000 951 . ENL8WPFbxOqXipIZr0gi73LXISv1Oc5VREINA+nwZ4SdXg72++HZvKPt q7Rlv/Zy/z8U0xsV8drSfktoc3L/vOT97I/xvBiqGBKfmcI9fZ+OI+rp aql8fl7ep0KxSsCW2snOapFvf3LeDcPop5OJtCOv0h0g6CYnLugbWdRR qiF6FDg38bx/QwpQZL0BKxD3E6/qjFOrBPuTbHkWk5P+B5SdEF9cWcsK pVy+N3wxKCvKALzxQzQ/zPja/P+8plxGzOYeiaZCFDN4wxa6433zkluG lLSTABiU6mnsmOl+0mVQWzsF0s6QgLemrtyQlGT9HJw/kZhsX8N7WnlJ sPBQ6w== ;; Received 1175 bytes from 198.97.190.53#53(h.root-servers.net) in 33 ms netgate.com. 172800 IN NS ns1.netgate.com. netgate.com. 172800 IN NS ns2.netgate.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q2D6NI4I7EQH8NA30NS61O48UL8G5 NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20230315042256 20230308041256 36739 com. VHsDr23lP03/xPxRbNUFC+UkSrUZ/Qr3JYHjhz7DYNOLPnzixRL+Hjv/ +kjbNiKVHYy2iGqU38XGJ4sPbvyRx8qygeTX3E7NnS4SdjnN2PKkTMAQ 42Vjxkq928qpoKPOwyn4zgcGSCZffTlNbY5IKVZacivEishoJ1j3BnVJ 1p2/N0gsLcS2GjIob2YGe7j4Lz8Aa5Rrj0s+DwlyP+BlCQ== 2U53SUOKS8OJJV178M90A8BMNI9USDVJ.com. 86400 IN NSEC3 1 1 0 - 2U54DC5VA9HQSV9DBV1IK3JD7KR4L61T NS DS RRSIG 2U53SUOKS8OJJV178M90A8BMNI9USDVJ.com. 86400 IN RRSIG NSEC3 8 2 86400 20230316045937 20230309044937 36739 com. JLAYnUTWdSkzhgKse8Qoyz0cdweJTibB9d0fQmTG1iDubISe0e/HhhBK SAdDEjqsOyV6x6bwtCVi+7HfoawJpsUgDNfYXEcgQfaXRk6TEOofhKnO mK+fVRHYsGbrBkyAfogu6KbQUAgleU65xfCmjKNaeYCDLe1Tq4FBcBLQ GstvOhDuAH5by0b1UBv+5k40jxuut/dlWfd+fxiwaxEO9A== ;; Received 717 bytes from 2001:502:1ca1::30#53(e.gtld-servers.net) in 36 ms www.netgate.com. 60 IN CNAME 1826203.group3.sites.hubspot.net. ;; Received 124 bytes from 208.123.73.90#53(ns2.netgate.com) in 37 ms [23.01-RELEASE][admin@sg4860.local.lan]/root:

@tikiyetti for starters you should really update pfsense, that version is quite dated.

If you want to do your own dnssec, then yes you should just resolve which is what unbound does out of the box. Or if your wanting to forward then just pick a dns that does it already and uncheck dnssec in unbound.

I am not aware of any of the major dns providers that do not do dnssec out of the box - some of them have special IPs you can point to that don't do it - like the 9.9.9.10 IP for quad9, etc.. But pretty much any of the major players are doing it out of the box. So there is little point to having unbound try and do it if your forwarding - more likely than not just going to cause you possible issues at some point or another. Its just extra work for something that is already being done.

If you order a cheeseburger, do you scrape off the cheese when you get it an put your own cheese on?

If you want to control putting cheese on your burger, just order it plain (resolve) and then do your own thing for the cheese ;)

@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.

@qbhatti said in Pihole as secondary dns:

blocks some google ads so it means I cant click on shopping items or sponsored items when searching.

Seems like a problem of the ad blocking list your are using in Pihole.
You could try a safe one like OISD Basic that has no false positives.

Sieht du denn Anfragen von der Fritz kommen?
Du kannst ja einfach ein Capture erstellen mit der IP der Fritz als Filter, dann hast du recht wenig anderes Zeugs drin.