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.

685ef897-9dfa-4656-81a3-8cb04f4c40f8-image.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 :

979fea0f-8b0a-4338-afa4-9be21a3aeefa-image.png

The issue has even a pfBlockerng solution made for it :

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

Screenshot 2023-10-18 at 8.24.51 AM.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

Screenshot 2023-10-18 at 11.27.08 AM.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 :

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.

Log lines indicate the exact moment of the events :

@leonroy said in Unbound was killed: out of swap space:

Jan 11 13:01:33 unbound 63374 [63374:0] notice: Restart of unbound 1.12.0.

and while it's starting - 15 seconds later :

@leonroy said in Unbound was killed: out of swap space:

Jan 11 13:01:48 unbound 63374 [63374:0] info: service stopped (unbound 1.12.0).

and a small instance (< 1 second) :

Jan 11 13:01:48 unbound 63374 [63374:0] notice: Restart of unbound 1.12.0.

To make a long story, go to the Unbound / Resolver settings page and uncheck this :

ffec4b58-bccf-4e36-8b6e-dc41c1cea202-image.png

Stick a post-it on the pfSense box that says :
"Check the resolver logs again after 48 hours and see how many stops/restarts happened the last 48 hours".
If you find "a couple" or even less : issue solved.

You do not need to create a nat - but if your policy routing, then yes you need a rule above that policy route rule that allows where your trying to go before you policy route out a vpn.

https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html#bypassing-policy-routing