Wow... ok figured it out. The links provided in @Gertjan post put me on the right path. It seemed strange that only Ubuntu Server hosts were affected so I started digging on that. Turns out that by default in Ubuntu Server systemd-resolved is not configured to use the domains passed by DHCP (either v4 or v6) not by RDNSS. So all I had to do was to edit /etc/systemd/networks/networkd.conf to have UseDomain=true and just like that, by magic the hostname is properly registered in Unbound...

@JonathanLee said in Serving different WPADs per subnet with Unbound: for Netflix not liking the HE ipv6 tunnel That was also solved with the help of pfBlockerng : [image: 1758778353680-eca53c7f-080b-4bc2-ab1a-cf4abc9e9f38-image.png] and enter all the domain names you don't want to be resolved as AAAA, only A. In my he.net days, this worked very well.

Thanx a lot @Gertjan That was it. It was listening on port 953. Since I had not seen any configuration option in the UI I thought it was disabled.

[image: 1737050808671-685ef897-9dfa-4656-81a3-8cb04f4c40f8-image-resized.png] I am aware of the resolver interval, is there a way to bypass one url example imap.gmail.com always forward to 8.8.8.8 do not save in firewall dns namesever for reuse thus every time it gets the new ip address google has for the mail server, they change so fast the firewall can't keep up so the mail app at times says error after 5 mins it will resolve but that is unacceptable for modern use.

@JonathanLee said in IPv6 HE tunnel broker and Netflix quick fix idea: This fixed my issues 100% anyone else parse AAAA and A dns records like this? That issue is very old. Hit the search button - its just above : [image: 1721814205482-979fea0f-8b0a-4338-afa4-9be21a3aeefa-image.png] The issue has even a pfBlockerng solution made for it : [image: 1721814277228-99d7ab85-cb14-44e3-958e-e48648d7256f-image.png] Check the check box. Add all the host names that should not be resolved to AAAA. Done.

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.

@bassplayaman re: latest, see https://docs.netgate.com/pfsense/en/latest/releases/2-7-1.html#troubleshooting

@n300 der umgekehrte Fall trifft zu, das Modul hat aber auch nichts mit den Client zu tun, sondern mit Übermittlung von Domains via pfB wenn das gemeint ist.

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

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

@gessel I too have an alert from this China IP block 183.136.225.29 [image: 1697653460002-screenshot-2023-10-18-at-8.24.51-am-resized.png] https://forum.netgate.com/topic/183488/et-scan-hid-vertx-and-edge-door-controllers-discover Virus total shows it is an invasive actor. 183.136.225.31 also [image: 1697653692436-screenshot-2023-10-18-at-11.27.08-am-resized.png]

Do you have a complex Unbound config? pfBlocker with DNSBL?

@sauce I've found https://knot-resolver.readthedocs.io/en/stable/modules-refuse_nord.html How is this related to pfSense ?

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

@rvjr On pfSense unbound generally restarts. See https://redmine.pfsense.org/issues/5413

@myman said in Unbound: fatal error: Could not read config file: /unbound.conf: unbound-checkconf returns unbound-checkconf: no errors in /usr/local/etc/unbound/unbound.conf Runing " unbound-checkconf" will check the default /usr/local/etc/unbound/unbound.conf, a file that exists, but it is just a demo file. The real "unbound.conf", the one unbound for pfSense is using, is here/var/unbound/ Your unbound is restating every couple of minutes. If these restarts happen to often, then the start code can overlap with another startup. Then one of then can fail and you see the error shown. Disabling "DHCP registration" is one of the first things to try.