@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.. [image: 1738261987008-query-resized.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 : [image: 1737972611688-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: [image: 1737477077570-screenshot-from-2025-01-21-08-21-15.png] [image: 1737477095794-screenshot-from-2025-01-21-08-22-09.png]

@Gertjan Unfortunately, there is a problem with this set-up. If it is set up as shown in the pictures so it's work fine. [image: 1737459756182-pics.png] A solution was found .Pics

@pika It's in the DNS Resolver settings. But as mentioned, maybe it's not there and hence not supported, since you've enabled KEA.

@bmeeks I did try that previously but I found the latency to from nextdns to be better, thank you for all your inputs, I will look into this further for some other alternatives

Can confirm iorx's "workaround" works. It seems the tld needs to be added as a domain override pointing to itself when a subdomain of that tld is used for local resolution and another subdomain is used for remote resolution via domain override. In my case my local network uses main.lan and the remote site uses remote.lan Only adding remote.lan as domain override to the remote site's DNS server made it work for less than a minute after flushing unbound's cache. Adding "lan" as domain override pointing to 127.0.0.1 made DNS resolution to remote.lan stable. configured Domain Overrides [image: 1737316909220-screenshot-2025-01-19-at-20.55.04.png] pfsense version: 2.7.2

Thank you for the reply. Yes I can provide. Should I message you it to you?