@NickJH DNSSEC should be disabled if forwarding. See blue note here:
https://quad9dns.github.io/documentation/Setup_Guides/Open-Source_Routers/pfSense_%28Encrypted%29/

@Gertjan

Yes, it turns out a whole trip to the theater.😊
Also, it turns out that the problem is solved, the solution (in my case) is found, published. Maybe it will help someone.

Thank you very much!

As for DNSBL - perhaps I will create a new topic.

@johnpoz
I mostly do, except some university classes require we use it.
R.png

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.

@sokonomi so your running sonarr - pretty sure you can change that default 8989 port. Are you running it as docker, you can also set the docker port to be something different and leave sonarr as 8989.

As to accessing via just sonarr via some url link, you can set your box to use a search suffix so that just using host would auto do a dns query for whatever your search suffixes are, ie sonarr.yourdomain.tld

I never get why this is of concern to so many - so what if the url is http://something.domaint.tld:port - once you create the bookmark, what does it matter just click the bookmark.

Unless you were wanting to hand this off to users, and you feel the users are too stupid to understand putting the :port on the end of the url, or you concerned that port would not be available outbound from where they are at, etc.

But if you provide more details of what your trying to accomplish we can go over all the different ways to skin that specific cat.

but anything via just host name is going to be bad practice - you should always use fqdn when accessing resources.

@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 ;)

@swami_ you can setup haproxy to use your wan or you lan interface. Comes down to where the traffic is going to hit.

Even if you ha proxy listens on you wan IP, unless you open a firewall rule on the wan that would not be available to internet IPs. But your wan IP is still going to be able to be hit via your lan devices.

Comes down to where you want to point the fqdn you want to use to point to - if all your going to want it for is lan, then just use your lan IP and point all your fqdn you want to use to your pfsense lan IP.

@gertjan -After Wan is active, DNS resolver does not start automatically.

We will review your suggestions.
thank you

The way MS describes it: Windows will ask the primary DNS, if a response is not seen in a short time it asks the 2nd and so on. The DNS that responds first becomes the primary.

If you are looking a packet capture you should see some amount of time, my guess is 10's of ms, between the queries. MS never defined a "short time" when I asked about it.

However it is said to work, it seems most OSs do what you describe, hit several before the first DNS responds. The packets are small enough I don't think the developers care and are more worried about response time.

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

@the-other said in DNSBL Stops DNS Service (Solved):

pfblockerng_dev (do not know about the other one) does NOT reload a list from servers if there are noch changes.
It seems "smart" enough to recognize a change in the list.
No changed list > no download (at least that's what the log says...

I hope so, I'm not so sure.

File attributes, size, last modified time stamp etc are needed before the file gets downloaded again.
But :
/usr/local/pkg/pfblockerng/pfblockerng.inc line 3373 :

if (($fhandle = @fopen("{$file_dwn}.raw", 'w')) !== FALSE) {

The local destination file is opened for writing - so initial file size date etc are lost : CURL doesn't cache by itself : the file can only be re downloaded at this stage.

Also :
/usr/local/pkg/pfblockerng/pfblockerng.inc line 170 :

CURLOPT_FRESH_CONNECT => true

Now read Is there a way to tell curl to not use cache

edit :
I forget something : most feeds are https://..... and default TLS web server caching is : no caching.
So even if you, on the receiving side, are ok to receive a cached version, you still get the entire file again.

Btw :less used download methods like rsync are version/date/time aware.

@jeremyj said in DNS resolver - forwarding working recursive resolution not working:

it would have been more intuitive for me to show screen shots with it set for recursive mode i.e. with the forwarding mode box unchecked.

I probably not using the default settings, and I really want to help, but won't reset my pfSense to default.
But you can do so, and you see what the default settings are.

@jeremyj said in DNS resolver - forwarding working recursive resolution not working:

as if I reset I have to rebuild all the rules, the vpns, etc.

Noop.
You can retrieve 'just' the OpenVPN settings, and 'just' the firewall rules from the backup you made.

@jeremyj said in DNS resolver - forwarding working recursive resolution not working:

I am also intrigued as to why it is not working and what I am missing

Ones you have it working, make again a config backup.
Compare it with the initial backup.
The difference you'll find is the reason.

@jeremyj said in DNS resolver - forwarding working recursive resolution not working:

my outgoing NAT

Outgoing NAT ??
That makes me think : when you undo all the changes you made when setting up the OpenVPN client, DNS works ... ?

@gertjan said in How to remove old IP entry of host:

Look here Services > DNS Resolver > General Settings at the bottom of the page.
Check also Services > DHCP Server > (any LAN) at the bottom of the page : "DHCP Static Mappings for this Interface"

Thanks for the hint with the DCHP server. I totally forgot about it. I looked in both and found that there is a static DHCP lease in the DCHP server list. But it is shown no where else in the DCHP server and so I couldn't delete it. Then I remembered that this old IP is the an IP of the range of an old now disabled interface. Luckily I only disabled the interface and not deleted it. So I enabled it which created a tab in the DCHP Server menu with this interface and the static mapping of the old IP. I removed it, disabled the interface again and now I am happy!

Solved!

@mer Thanks for the reply! Your comments got me to thinking which can be dangerous ;-)

I figured out the problem. It has to do with little Windows 10 app that the commercial VPN provides. This app resides in the system tray on the right side of the task bar in Windows 10. The app is used to connect and disconnect from the VPN. With your comments, I had the thought to try to figure out what DNS server windows was using when connected to the VPN and when not connected to the VPN. With a quick google search I found the Windows 10 command prompt nslookup command. Simply entering "nslookup" in a windows command prompt will return the DNS server being used. In my case, when I wasn't connected to the VPN, it returned the ip of my pfSense router. When I was connected to the VPN it returned an ip of a DNS server that belongs to my VPN provider. It seems that everytime you connect to the VPN service using their Windows 10 app, they change your DNS server address to their DNS server. I tried manually changing it back to the ip of my pfSense router but that didn't work when connected to the VPN - in that case I broke internet access altogether and couldn't connect to anything. When connected to the VPN, Windows wasn't able to resolve the local ip of my pfSense router. The solution will have to be to stop using the app provided by the VPN provider so that the DNS server that Windows uses stays pointing to my pfSense router. I had previously setup a gateway associated wiht the commercial VPN provider in my pfSense router. My solution will be to configure pfSense to route traffic from my Windows 10 through the VPN gateway when I want to use the VPN from my Windows 10 pc. Sort of a pain b/c I will have to log in to pfSense every time I want to use (or not use) the VPN. But in this scenario I can use the https://server1name.domain_name.tld paradigm to access my local services from my Windows 10 pc whether or not its WAN traffic is being routed through the VPN. This is because my Windows 10 pc will always be configured to use pfSense for domain name resolution.

That is on the client side, simple search suffix for example.com

Now when your host does query for hosta it will really do query for hosta.example.com

example..

My host.

indows IP Configuration Host Name . . . . . . . . . . . . : I5-Win Primary Dns Suffix . . . . . . . : local.lan Node Type . . . . . . . . . . . . : Broadcast IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : local.lan

See the search suffix - now when it pings it for say some host it auto does query for the fqdn including the domain

$ ping brother Pinging brother.local.lan [192.168.2.50] with 32 bytes of data: Reply from 192.168.2.50: bytes=32 time=1ms TTL=254 Reply from 192.168.2.50: bytes=32 time=1ms TTL=254

You can see my client did a query for the fully qualified name

dns.png

If the client sends that as its hostname.. Then ok - but dhcp leases shouldn't be showing a fqdn.. It would only be showing the hostname.

If you want client amazon-random# to show up as alexa-name in your dhcp lease. The correct solution is to either have that specific client send that hostname to the dhcpd, which I don't think you can do on alexa. Or tell the dhcp server to use hostname xyz in the host name when you set a reservation.

If your setting reservations for your clients, and register that in dhcp settings - then all your dns is taken care of.

@patch said in DNS RESOLUTION BEHAVIOR:

@tiger-0 said in DNS RESOLUTION BEHAVIOR:

DNS was from 127.0.0.1 to DNS is 192.168.2.99, is this a normal

If not done explicitly by you, I suspect pfSense added the setting from you ISP when setting up your WAN

That happens when this option

0f3ad839-7508-40ce-94dd-25b9dc758aa2-image.png

is checked.
It should not be checked.

@wmheath586 you might also want to drill down further to the MAC address tables in your router. If you are using a managed switch you should be able to telnet into your router and inspect the MAC address table. This would be relevant if you are running multiple VMs and have left the MAC addresses at their defaults.

I have the SG-2220 and do not have this issue. I know this doesn't help a whole lot but someone suggested it could be hardware specific. I hadn't used my SG-2220 for about two years due to divorce and just recently got it going again which is what led me here. I did have this problem and when I did an update when it came out I still had some troubles but not this trouble. I did a factory reset twice and for whatever reason the second reset is what made everything happy. I started with all new settings and didn't restore a thing. I know this doesn't necessarily help a whole lot, but I wanted to offer additional relevant info. It isn't failing on my Netgate SG-2220. What can you do with that? I don't know exactly, but I don't think it is just the software. It might be hardware specific race conditions as another user noted.

Musste leider feststellen, dass "meine" Lösung wohl nur eine gewisse Zeit funktioniert. Irgendwann scheint es so, dass Windows den "ersten" DNS-Server nicht mehr nutzt und daher interne Namen nicht mehr auflöst.
Habe daher vorerst auf IPs umgestellt.