Quick update it seems like it's only happening in Chrome and no other browser? And it comes up with proxy negotiation as the reason. Doesn't occur on another network not configured with pfsense

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.

There you go - once that is done, and the new version becomes available downstream.. If there is just a setting to up it. Then either pfsense can add it to the gui in the form of a number you set, or as with some of the more advanced unbound stuff you can just put it in the option box.

Until that time the domain override should work for domains you run into such an issue with.

@gertjan Well, problem has been solved. My set up involved 2 unmanaged switches. The eero connected to the first switch to provide internet access to wired devices. The error: I had two cables from the first switch connecting to the second switch. When I found this to be the case, unplugging one immediately fixed the problem.

@mclaborn said in DHCP server not supplying domain search list:

(Not Windows, thank goodness.)

hahah - made me laugh.. thanks!

@cool_corona said in No route to host:

@gertjan I wont update to 2.5.1 since it has the MultiWAN issue.

Normally the same branch of releases has access to package repository

It does:

47caa037-45fc-4984-83de-f0d0db79edcf-image.png

253fccae-8203-4a5f-8cb4-d2c9f594cf36-image.png

8671c7a4-5baa-4967-a976-16f83cf0e784-image.png

Check your update path under System/Update (should be latest stable 2.5.x).

Also check your internet/DNS connectivity, as

pkg-static: https://files01.netgate.com/pfSense_v2_5_1_amd64-pfSense_v2_5_1/meta.txz: No route to host

"No route to host" clearly is an error that is local to you. Could perhaps be DNS related as the file-servers for packages are resolved via SRV records. Also check out via console:

[2.5.0-RELEASE][root@mirage.nt.ops.to]/root: pkg-static update Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date.

pkg-static update should run without problem. I assume it doesn't for you?

Cheers

@gertjan

Thanks, I didn't like using my ISP's DNS so I was trying to get it to use a one other than there's.

I was downloading a lot of stuff when I took that screen shot, but it's always worked, the update manager that is.

Under system > Package manager / available....there's loads and loads....it would take maybe 6 or 7 screen shots to list them all......

Cheers

working now.jpg

Thanks a lot Gertjan

I did as you suggested, did a factory reset and now it works perfectly.

Thanks again. 👍 😊

While unbound supports views. And you could setup local data to resolve differently depending on the source of the query, I am not aware of the ability forward to X for a view.

To do such a thing you would look to using bind.

@cyberminion said in DNS dies periodically (due to unbound crashing?):

pfBlockerNG is running for both subnets

pfBlockerNG can restart unbound regularly. Do a manual reload of pfBlockerNG and see for yourself.

This option :

3c497c02-4cf0-48c5-b677-fd5012978728-image.png

will also restart unbound when a new DHCP lease comes in.
Although, checking that option and using pfBlockerNG will make it complaining about it :

ceb9c807-4d57-4fe8-a6dc-93fdd7cc6066-image.png

That is : the Python mode doesn't 'like' this "DHCP Registration" setting, so, if set, it (pfBlockerNG ) will default to the older "unbound mode" This mode uses more resources and is slower to restart.

@cyberminion said in DNS dies periodically (due to unbound crashing?):

when needed to a pair of defined public DNS severs.

Are you sure ?
unbound should be used as a resolver. With "public DNS" you mean you're forwarding ?

@cyberminion said in DNS dies periodically (due to unbound crashing?):

When DNS service drops out, I can wait about 20 minutes for it to come back by itself

This is the real issue : it did not crash, it was just restarting, and this shouldn't take that long.
Or it does so on your system.
Bring your system back to default settings (remove or de activate pfBlockerNG and other packages) and add them back again step by step. Restart unbound with the GUI :

3bc2cdff-5f81-4157-80d9-457f7b1bfef4-image.png

and check with the unbound logs how long it took.
Do this for each step, each feed you add to pfBlockerNG.

The Firewall > pfBlockerNG > Update : Reload > All
also shows you how much time it took for unbound to restart :

19ee308d-b97a-45ac-b79b-a36072585ff3-image.png

@latency0ms
great. 👍

Apologies - I was seeing strange things and I thought it was my brand new firewall, as I am such a novice with it.

The problem resulted to be the pool of addresses given to the DHCP server inside the MikroTik. It was in another tab, so I just configured DHCP but I didn't change the pool...

I tried your solution anyway. Thanks

Updating to 21.05-RELEASE seems to have resolved this issue.

@amestag said in Replace unbound v1.13 with v1.12:

I just need to have another DNS server to forward too

There's only about a million of them. 1.1.1.1, 4.4.4.4, 8.8.8.8, your ISP...

Free and Public DNS Servers

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

Looks like moving to a port based filter on the tcpdump is now showing the proper response so I don't think this is a PfSense issue.

You can run a very nice Unbound Implementstion of pfsense, but you ask Cloudflare direktly every time you habe to resolve a Name.

Unbound with cache and prefetch is signifikant faster.