@aGeekhere this question gets asked all the time - what your asking is problematic without a separate cache for the views or different clients, etc..

If client ask for something that would be blocked by filter dns, but they are set to ask non filtered dns - now that is cached. If client that should be filtered then asked they would get back what is in the cache.

Bind can run multiple caches - but not sure something you can configure from the gui.

You could prob get what your wanting out of running both unbound and dnsmasq (forwarder) with them listening on different ports, and then have your clients point to say 1.1.1.3 or whatever that gets redirected to the new port unbound or forwarder is listening on to resolve your local resources, and then just forwards on to 1.1.1.3

Simpler solution to be honest would just run say pihole or something that pointed your clients you want to filter to that.. Then setup a conditional forward on it to forward to pfsense to resolve your local domain.tld resources, and if not in that domain just forward to 1.1.1.3. Thats would I would do.

@patient0 said in Dot gets added to hostname, why?:

Maybe client related

I don't think so because the "act" of making a static mapping from the DHCP Leases triggers this.

@kuchenmann said in Register Client-names in DNS KEA-DHCP?:

It seems that KEA-DHCP on pfSense does not register dynamic assigned DHCP-leases in DNS. Only static-mapped DHCP-clients.
Because in the leases I see also hostnames for dynamic assigned DHCP-clients, but I can not resolve this hostnames in DNS.
It only works for static-mapped clients.

It depends on the version of pfSense you are running. If running pfSense CE 2.7.2, then you are correct in your assessment. But if you are running pfSense Plus 24.11, then Kea does in fact perform dynamic DNS updates of the DNS Resolver in pfSense each time it issues a DHCP lease. I am running that version and now the dynamic DNS updates for DHCP leases works just fine.

Same shit in year 2025.
Why are users forced to use such crap?

@bmeeks I agree, due to budget we are going with PFsense and that's why checking the best to do with it, I got it working for now. with my above rule list and extra, I added to block the traffic to DNS IP 1.1.1.1 for port 853, from what I see Safari is using DNS over TLS port 853, with that blocked safari is blocked

@tedquade Thanks! I wish it would just get an IP, but delaying boot is the best option for now. I would thumbs up you, but don't have enough rep.

@SteveITS yeah I would highly doubt there has been much work on the forwarder (dnsmasq) in quite some time to be honest. I am surprised that anyone would still be using it to be honest.. I mean it can do some things unbound can't like forward to multiple NS as the same time, etc.

But if you can't figure out that the custom options box is what they were talking about - not sure what to tell you ;)

Now if there was 2 boxes, one labeled advanced, and the other custom - and putting it in advanced didn't work because they called out the wrong box - yeah that could be problematic.. But there is only one possible place such commands could be put into that gui form.

@Gertjan, thx very much for your awesome reply. I really appreciate it as I learned something new 👍 😎
To be honest, it's the first time I read something about the services.inc-file. Super interesting!!

Of course, I tried it and it works like a charm.

@imark77 Thanks. As it stands, you have to do lots of digging around to see if feature parity matches your needs.

Would give you an upvote if I could.

@Nimda_2025
I meant to add more info a couple of hours after I made my initial post. Sorry for the delay. I tried PIA VPN from my desktop pc, laptop on my LAN, and cell phone on my LAN and all worked fine while on VPN but wouldn't again as soon as I got off of PIA. Cellular data on my phone and laptop gave me no issues accessing QB. It's definitely something on my pfsense. I also checked my first static and gateway IP against the most common blacklists and it's fine. I don't know where to go from here.

@propeto13 said in KEA service stopping through the day:

this is the way.

Its 'a' way.
If the /tmp/kea4-ctrl-socket.lock exist, or, as seen here on the forum about kea related posts, the pid file exists when kea starts, it will not core dump, but simply refuse to start.
And it's normal that these files exist, as 'core-dumping' isn't a clean process exist, so these files remain in place = not good.
And you can't start the process kea anymore without manually deleting them.
I think there is a Netgate pfSense System patches (you have this package, right ?) patch that handles this issue.

Ones thse files are gone, you can start kea.
And then, suddenly, it core dumps .... and it's rinse-and-repaet time.

@jmedin1965

Thank so much this has solved my issue!!

@johnpoz said in Logging DNS queries:

@Octopuss if your using unbound as resolver - doesn't matter how many IPs you setup in general for dns.. It isn't going to ask those, unless you setup forwarding in unbound.

forward.jpg

Unless you set that, then the only thing that could ever use the ones you put in general would be pfsense own dns lookups. And if you left loopback in there 127.0.0.1 it should normally ask it, which would then resolve from roots and your dns servers listed in there would never be asked anything.. Unless your unbound was down and pfsense itself moved to one of the others listed.

@johnpoz
Can I use the same setting like you have in your image when i'm using "Enable Forwarding Mode"
I have been running like this for years:

Disable: "Enable DNSSEC Support"
Disable "Strict Outgoing Network Interface Binding"

System Domain Local Zone Type: "Transparent"

Outgoing Network Interface: WAN and localhost

@johnpoz said in Using one interface for Domain Overrides only?:

it wouldn't send traffic to some internal IP for google.com - unless that internal IP was also a gateway in your routing

Interesting. Right now it is set up as a WAN-type interface. I guess I did it for NAT etc. but I can have that without being a WAN-type interface... Thanks John! Makes sense if I think about it. 🤦

@PVuchetich2 said in KEA DHCP continuously rebooting with error message after 24.11 upgrade and switch from ISC:

COMMAND_SOCKET_ACCEPT_FAIL Failed to accept incoming connection on command socket -1: Bad file descriptor

Here : https://kea.readthedocs.io/en/kea-2.1.7/kea-messages.html

A socket is just some kind of special file. Its created at kea starts, no big deal. Every process, like ngins, (web GUI) unbound (resolver) create these.

COMMAND_SOCKET_ACCEPT_FAIL

Failed to accept incoming connection on command socket %1: %2

This error indicates that the server detected incoming connection and executed accept system call on said socket, but this call returned an error. Additional information may be provided by the system as second parameter.

Try this :
In the GUI, stop all kea server services.
Then use the console or (better) SSH, menu option 8.

then

Normally, there should be no files anymore that starts with "kea".
If there are, remove them all.

Now, start the kea server(s) again.
Check again the content of the directory, there should be a new kea-ctrl-socket file again (and a lock file).

Other checks :
Systems processes like unbound, the web GUI and kea gets restarted when there is an up down interface. This happens when an interfaces goes down for a moment. You don't have these ?

@johnpoz Ahhhhhhhh. Gotcha. great point. Will have a re-think.

Thanks for sticking with me. Not sure what I'm doing is pointless, but hadn't really considered that, had tunnel vision.

@bmeeks

Exact.

a6b0b7c8-83da-4505-833b-f1f56f899c66-image.png

@frankz so I know this thread is a bit old.. And I still don't see the point of trying to hide your domain from devices on your network. But I have found a use case for not handing out any domain to iot type devices..

Seems these iot devices now add the domain they get as a search suffix, especially when what they try and resolve does not resolve, like in the case of blocking with pihole or something.

I noticed it on my alexas first, but then noticed my firesticks where doing it too - not sure if something changed in their software, or I just never noticed it before.. But I had recently updated the rasbian on my pi from bulleye to bookworm - and I had to reinstall some stuff. pihole being one of them.. So I was paying more attention to what was being queried, and returned, what was being blocked, etc. Just making sure my new install of pihole was working the way I wanted, etc.

So the alexas were doing a query for something.a2z.com - which wasn't blocked, but they were also seen doing querys for that same fqdn with just my home.arpa added to it... Maybe the original query just failed for some reason, even if I wan't blocking it. So something.a2z.com.home.arpa - which is never going to resolve to anything. But it was just a bunch of log spam in pihole query log..

query.jpg

At first I just stopped it from being listed as a top domain on the dashboard.. But then I thought why is alexa adding that search suffix? It sure is never going to resolve that in home.arpa - and to be honest they would have zero reason to ever resolve anything that even does exist in my home.arpa domain, and if they did it would resolve if was a fqdn query for say something.home.arpa.. But if I could figure out a way to prevent alexa and my firesticks from using home.arpa as a search suffix that would for sure remove the extra dns queries these devices seemed to be doing.

So I figured hey if I don't hand the domain to these devices, they wouldn't be able to add that as a search suffix, so they wouldn't be able to do a query for something.a2z.com.home.arpa

So solution I found is if you set a custom option for the domain (dhcp option 15) and just leave it blank, then they don't get anything. I sniffed the dhcp traffic and no domain (option 15) is sent..

This is what gets put into the dhcpd.conf

I then went and rebooted all my alexas - and have not seen a single query for something.com with home.arpa added to it from them. So log spam stopped.

Since their should be no way that they can even learn about this home.arpa domain now - there should be no way they should ever do a query with that suffix tacked onto the end.

This seems to be a way to accomplish what you were after without having to edit the services file for dhcpd, and don't have to worry about upgrades overwriting your change, etc.

This really has nothing to do with security of the device knowing the domain, its about reducing useless dns queries that only amount to log spam.

@bmeeks I think with not being to be on site and no help on the other end, I am not going to be able to perform this type of configuration, especially for my first time and cross my fingers it just works. That might be something to entertain down the road if I was ever to have a visit, unfortunately I don't think this is something to attempt while not there. Overall the 6100 has been working fine for their basic needs but I would like to implement this in the future.

@blackburd

@johnpoz said in Dynamic DNS with Cloudflare does not work, change my mind:

so there is no inbound traffic to 100.64-127.x.x.. This is cgnat space.. It doesn't route on the public internet..

Which means that nobody from the Internet can reach your installation.
You're safe !! Your local firewall doesn't have to keep the nasty people out, as they can't reach your routers/firewalls.
You, your traffic can go outside, you can go where ever you want, no issues what so ever.

True, if you want to make something from your LAN accessible from the Internet, like a camera, then that's something that your ISP connection must 'offer'. You have to pick your ISP with this functionality in mind.
More and more people will have an Internet connection using cgnat. Because there are no more free IPv4 left to attribute to everyone.
If your ISP is modern enough, you also have working IPv6. You could also use that. cgnat isn't needed for IPv6, as everybody o earth can have 1 million IPv6 addresses for the next 1000 centuries or so ( 2^64 = huge).