@lcbbcl said in Unbound make requests to 53 port: I was curious to understand how/who send the requests to port 53 If you have servers listed in general other than loopback, pfsense can and will depending use those for its own lookups.. Which would not use dot, they would just be normal queries to 53. There is currently a redmine to change this behavior if so desired. https://redmine.pfsense.org/issues/10931 If you only want pfsense, even for its own look ups - when it checks for updates, when you grab package list, if you click resolve some IP in the firewall log, etc. Anything that pfsense might try and resolve on its own. Aliases for example.. Then you would set the option to only put loopback (127.0.0.1) in resolv.conf

found it, I had to make a rule in Firewall-Nat-Outbound

I had precisely the same problem. It occurred to me that /var/ was 100% full. A simple reboot cleared out /var/ and after that I could save and apply DNS Resolver again.

Some more information.... I relinquished my IP and took out my mac spoof on the WAN connection. I did a release/renew and couldn't get a new IP address. I was able to get a tcpdump file of this off the WAN interface. The weird thing is that when I released the IP, it would blank everything out. When I renewed it and it timed out, it would show the Gateway IPv4 address and the status was 'up', but the IPv4 Address was not properly displayed. I can't recall if it was just 0.0.0.0 or wasn't even displaying. In order to get a new IP, I had to relinquish and release the WAN interface, issue a restart command of the cable modem through the Xfinity app on my phone, wait a few minutes, then finally renew the IP.

i'm not the one in trouble here, it was an example for @justice41 or am i misunderstanding something?

Pfsense does rebind protection, if you forward or resolve it will not return rfc1918 space. Clients like some windows will not do this, doesn't care.. But not good practice to have rfc1918 in public domains. You saying if you point client to 8.8.8.8 you can resolve some fqdn to rfc1918 points to bad idea!! As already mentioned you can allow pfsense (unbound or even dnsmasq, different setting) to resolve rfc1918 from something you forward to or resolve with like the above private domain setting. Or you could turn off rebind protection completely in pfsense. https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html

@kiokoman So, the reverse records have not been created as I suspected. I have just added the same line to the reverse zone using the GUI to the bond update policy (same as done before with the forward zone): grant "rndc-key" zonesub ANY; With the “; “ after the last command, and it’s also working, reverse records are also being automatically registered from Pfsense DHCP.

So there's no way to do a domain override on one vlan and not others?

Thanks @johnpoz, I really appreciate this complete and thorough answer! Thanks so much I'll work on getting things switched over to home.arpa.

Unbound the cache is shared... But if your cache is actually different in bind.. Then you should be fine. I would suggest you thoroughly test this to make sure.. Good info you linked to - thanks..

Yeah its quite possible they use to be default, I do remember dhcp being enabled for sure - because of all the posts about unbound restarting.. It being off is prob a good default - but now will start seeing posts like this one ;)

You can point that one server to pfSense, but if you want that server to be able to resolve other LAN hosts, then you will use the domain overrride option in DNS Resolver on pfSense. You would put your domain name in the override section and then point to your AD Controller/DNS server for resolution. So really not much different than just letting that one server talk to the AD controller in the first place. With the domain override, whenever the "exception server" queries something such as some_server.my_AD_domain.lan (or whatever your AD domain name is), the DNS Resolver on pfSense will query your AD controller/DNS server for that host instead of traversing down from the Internet root DNS servers. That's what a domain override does. It points the resolver to a customized authoritative server for that domain. So in your case, the unbound process on pfSense would query your AD controller DNS server for the record, and then return the IP to the "exception server" that asked for it.

For anybody else trying to get this to work, follow this guide: https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html And then if you're using systemd-resolved (Ubuntu, Arch Linux etc.), then modify /etc/systemd/resolved.conf by changing: #DNSOverTLS= To: DNSOverTLS=opportunistic Using opportunistic is the only time when I saw port 853 getting requests on the firewall. After setting it up this way, I no longer saw any requests on port 53. I tried using Stubby but was unable to get it working. The Arch Linux wiki says you're supposed to also set DNS={{ router_ip }}#router.domain.name. However, I got it working without specifying this. It may be because I used ACME to get a certificate. The hostname/domain you're using with ACME should probably match the information provided in General Setup. @jimp said in How to Use DNS Over TLS Server Option: https://docs.netgate.com/pfsense/en/latest/recipes/dns-over-tls.html

@maverickws said in Issues with DNS Resolver: however I feel it would be interesting to have the possibility to add more than one dns servers to the domain override option. It's on you. You may add further servers even for the same domain. Unbound then use the second if the first does not respond.

Unbound not really meant to be authoritative - but you can for sure answer with authoritative responses, ie SOA and create pretty much any record you want. But your not going to be able to create those records in the gui. Why do you think you need a full blown authoritative NS? What exactly are you trying to do - if all you want is to respond for some MX records... Just do that in the custom option box

@parry The thing is, that's an entirely valid configuration. In fact, with IPv6 it's common. For example, my WAN IPv6 address is a /128, the IPv6 equivalent of a /32. You just have to know when a /32 is appropriate.

Hi, Your used a NAT rule for IPv4. NAT doesn't exist for IPv6 - that is, pfSense does not permit us to configure a NAT/PAT rule for IPv6 (yet).