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

cd /var/run

then

ls -al kea*

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

option custom-opt8-1 "";

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

@ngr2001 I don't know if this is your problem but I had a issue with my Linux clients using NetworkManager. turns out the built in DHCP client does not work with KEA. solution is to not use the built in client ("internal")

Fix is /etc/NetworkManager/NetworkManager.conf
[main]
dhcp=dhclient

@mikey_s said in Cloudflare new 1.1.1.1 for families:

I had mixed results re leaving gateway option empty, so set one to each.

Changed, testing now.
Disabled DOT btw.

EDIT:
I'm getting around 40ms to quad9's DNS servers, but decided to test it in my network.
Using 9.9.9.11 and 149.112.112.11, each one of them assigned to a different WAN.
Using DOT: dns11.quad9.net
DNSsec enabled.

Everything seems to be working perfectly so far..
Missing the adult filter.

EDIT2:
Do you guys know if Unbound in pfSense is compiled with ECS support ?

@JeanMi said in Kea DHCP 100% CPU usage / slow answer to queries:

and I'll see if everything stay up

Don't worry ^^
If :
The power is good.
You don't mess with the system.
The system hasn't shown any hardware issues errors (like drive dying).

you could; after several months, no ... more then one year ( !! ) be part of the "My pfSense is up and running for 1+ year now" elite club.
( but don't tell us, as it also means you didn't update update etc ... )

For some reason, I restart my pfSense ones in while. Mostly because I updated something. (or because I f##ked up again ;) )

@HopelessErrors said in Dynamic DNS Failing on Start:

This Netgate is powered on at the same time as the WAN device, but the WAN comes up before the Netgate is fully initialized

That's the best scenario.
During boot, ... this happens : read /etc/rc.boot
Lots of stuff is done, and wto of them are :
Interfaces are set up ...
and the DynDNS is send a signal with 'service reload dyndsall'. At that moment, the actual interfaces (normally A WAN) is copared with the last known good IP (it's cached / stored in a file).
If the cached IP and actual WAN IP are the same, nothing happens.
If they are different, an DynDNS update should take place.

I had to reboot my pfSense last week as a part of the monthy UPS / Network / whatever tests.
It rebooted at 10h15 AM.
During the boot process I saw several

<13>1 2025-01-23T10:15:53.916036+01:00 pfSense.bhf.tld check_reload_status 730 - - updating dyndns WAN_DHCP

which will trigger a dyndns sync.

These are the line that tell me dydnns was trying to :

<27>1 2025-01-23T10:15:56.615087+01:00 pfSense.bhf.tld php-fpm 629 - - /rc.dyndns.update: phpDynDNS: Not updating home.bhf.tld A record because the public IP address cannot be determined.

and 1 second later :

<27>1 2025-01-23T10:15:57.628645+01:00 pfSense.bhf.tld php-fpm 57727 - - /rc.dyndns.update: phpDynDNS: Not updating home.bhf.tld A record because the public IP address cannot be determined.

so that was a fail twice ... WAN wasn't ready yet I guess ?

But then still in the middle of the boot process (7 seconds later ):

<27>1 2025-01-23T10:16:11.802487+01:00 pfSense.bhf.tld php-fpm 629 - - /rc.dyndns.update: phpDynDNS: Not updating home.bhf.tld A record because the IP address has not changed.

Bingo !
The test was done, the IP WAN didn't changed - so there was nothing to do.
The test, it was checking with this URL :

2e256f8c-7d90-41db-b5b5-33fda8550106-image.png

Test for yourself :

http://checkip.dyndns.org
Click and see ^^

and it compared the IP from the URL with the srored, cached IP.
The dyndns cache file is here /cf/conf/ and starts with dyndns_.....
It contains your public WAN IP.
Check the file last modified date time stamp to see when the IP was modified for the last time.

I'm telling you all this, so you can do some checks on your side.

@Asmodeus666 hi, did you ever resolve this issue? I'm having the same problem and don't know how to fix this! Any help appreciated

@lohphat Probably worth you being aware of this post which is about an 11 dump of KEA on a 3100 which I've been having...

@bmeeks

👍

Another option that was needed in the past, as ISP had to (wanted to) capture all DNS traffic, aka forwarding to 'them'.
Not needed anymore these day.

@ppkwebsites-subscribe
Glad to here, it's working finally.
Yes, I had the same issue in the past, when setting up my pfSense on KVM. I had also to disable hardware checksum offloading.

Im glad that worked for you.

Are you aware that you dont need to add any DNS servers to PFS? It will do what is called resolving and ask the root servers for you. Bypassing the commercial servers you go directally to the source.

My DNS settings: Screenshot from 2025-01-21 08-21-15.png

Screenshot from 2025-01-21 08-22-09.png