@Gertjan Thanks for the hint! I saw that I had TCode wrong, but even with the example, PCode still gets truncated: { "option-data": [ { "name": "time-offset", "data": "3600" }, { "name": "tcode", "data": "Europe/Zurich", "always-send": true }, { "code": 100, "data": "EST5EDT4,M3.2.0/02:00,M11.1.0/02:00" } ] } This is what Wireshark sees: Option: (100) PCode Length: 8 TZ PCode: EST5EDT4 Option: (101) TCode Length: 13 TZ TCode: Europe/Zurich Option: (255) End

@JonathanLee said in Doh and chat gpt: It is safe to say that that if they recommend to do this ... I found one paragraphe that I understood and agreed with : NSA recommends that an enterprise network’s DNS traffic, encrypted or not, be sent only to the designated enterprise DNS resolver. This ensures proper use of essential enterprise security controls, facilitates access to local network resources, and protects internal network information. All other DNS revolvers should be disabled and blocked. For me, this is a good advise. Let's all agree that this just is my opinion. This paragraph also explain (again : for me) why pfSense adopted unbound, and left the forwarder, (dnsmasq) as it is a resolver and it support DNSSEC. The fist paragraphe (I dismiss the intro paragraphe) : DNS translates domain names in URLs into IP addresses, making the internet easier to navigate. However, it has become a popular attack vector for malicious cyber actors. DNS shares its requests and responses in plaintext, which can be easily viewed by unauthorized third parties. Encrypted DNS is increasingly being used to prevent eavesdropping and manipulation of DNS traffic. Wasn't this partially solved a couple of years ago ? Short story : Enable DNSSEC on your web site (mail server, any resource) - activate DNSSEC on the pfSense*-unbound site and from now on the DNS info you receive can't be tampered with. Example : visit this test site : https://www.test-domaine.fr - I own this site for demonstration purposes. This domain name server is DNSSEC secured. So when our resolver unbound resolves this domain name, from top (root servers) to bottom (a domain name server), the entire revolver process will be signed and everything adds up, the answer is accepted and unbound will give it to your requesting LAN client. Afaik, initially, the US was slow in accepting DNSSEC, and I really did understand why : "There must be something better as that ?!" but years passed and nothing better was found, so, not long ago, it became mandatory for all 'official' domain names even in the US. Example www.usa.gov. If you like the visual graphs : www.usa.gov. DNSSEC doesn't hide. It's not a "don't see me watching p#rnhb.com" solution. It's a tool that makes sure that when you want to visit p#rnhb.com, you get p#rnhb.com, and not a spoofed web site. Spoofing p#rnhb.com is one thing, if your bank's domain name gets spoofed, then you will have "issues" very fast. DNSSEC promises you just one thing : "You'll get a exact answer when you do a DNS request". It will be the domain (site) you want to visit, and nothing else. The 'hiding' and 'flying below the radar' web surfing is for those who have sensible formation to hide, and this isn't valid for what ? 99 % of us. I tend to see DNSSEC as 'chain singing'. If it breaks, then sell your bitcoins right now, as they will break minutes later ^^( and post/warn us here as fast as possible, so we can sit on the front row as this will bring some economic fireworks with it ) DoH just hides the DNS traffic. Maybe not for the 3 letter agencies like the NSA ?! - It maybe just me : if the NSA advises to used DoH, what does that really mean ? After all : the NSA wants info [with the "no matter what" authorization], that is their main goal. They care way less about 'your' security' or our 'private rights', these are just optional. Btw : I'm not against their (NSA) existence, every country has one. Afaik, we need them. Edit : @netgate : really ? can some one sign that netgate.com domain please ? It's not rocket science anymore. Visit the registrar, check "Enable DNSSEC" and be done. Or do it the manual way, as I did it, if you host your own domain names (Me, running a hotel, can do it, so consider the trick as mangeable ^^) @JonathanLee said in Doh and chat gpt: but how do you make sure your clients are configured to only use that one DoH server? Afaik : there is no DHCP option (even RFC ?) yet that asks for a DoH type of DNS server. Also : 99 % of all routers out their are the crappy ISP routers. They might host a dsn forwarder, not something that hands out DoH DNS servers. This means that a device with 'some' OS might be hard locked to an existing, know upfront, probably hard-coded into its firmware, DoH server IP (and domain name !!). For what I know : If you want to use a DoH DNS solution on your system, you have to enter it by yourself. This tells me : [image: 1763656524355-ae258d6c-34e2-446d-a4bb-884f5ec876cb-image.png] that "Microsoft 11" has its own list with 'Microsoft' DoH servers - the "automatique mode", or you can enter one of yourself. By default, the Microsoft OS will obtain it's (classic) DNS IP by asking it during the DHCP lease request. @JonathanLee said in Doh and chat gpt: there is no settings on iMac or on Windows etc and or browsers to lock down to a single DoH Group some Windows Microsoft devices together, make them member of a Microsoft domain, get a domain controller, and use the Domain Policy editor (or whatever its called), and can set set whatever you want. Including mandatory DoH. No RFC needed.

@jbariyo said in DHCP Lease Pool Exhausted and Disabled Leases not deleted: 9-5 environment you can give 8 hours and 9 hours respectively i configured this today The default is 2 hours - what did you have it set to before.. You understand you could set it to 30 minutes or something if you wanted to.. If a client is still on they will just renew it. There is little need to set it for length of the work day. If your scope is oversubscribed - ie more clients than you have IPs then you going to have a bad day if more clients are trying to be on at same time than you have IPs. How many clients do you have total.. You should prob setup your network to have more IPs than that. Be it you increase the scope size out of your network, or increase the network size by increasing the mask from say a /24 to a /23 or even a /22 Are these wireless clients? If clients are changing their macs on you - then yeah you could run through a more IPs via dhcp than you actually need. If so would make a short lease so that if client rotates their mac the old lease expires quickly so it could be re-used. Do you have idiot users? (this is a given normally) where they have both wired and wireless at the same time - that are in the same network? edit: As @Gertjan mentioned maybe the client is borked - I would look into a specific client when they complain this is happening. Are you really out of leases, is the client getting a 169.254? This is what a client will normally give itself when its set for dhcp and can not get a lease. Are you getting clients with duplicate IPs? I would look into the details of a specific failure so you better understand what is happening. Is there currently a lease for that client and it just not renewing and using up new leases, etc. What dhcpd are you using isc or kea? Maybe there is an issue with reusing expired leases? More info on what is actually going on is always helpful.. But yeah if you are oversubscribed you either need allow for more IPs, or use really short lease times.. And just actually hope you never have more clients on at the same time than you could possible supply ips for.

@johnpoz said in Custom options in unbound (dns resolver) cause syntax error: include wouldn't be part of it Oops. I corrected my post.

@pftdm007 not quite - if you are not in forwarder mode, unbound resolves what was asks from the roots down.. It doesn't send the query anywhere - it resolves vs forwards. And not so much pfsense passes it to unbound, unbound is listening on 53, and as long as your firewall rules allow it - unbound will get the query directly. When you resolve - you don't need anything in the general setup at all. If pfsense itself needs to resolve something it will ask itself (unbound) via the loopback address 127.0.0.1 the only time something like 8.8.8.8 would be used if you have it in general is if pfsense itself wanted to lookup something and unbound wasn't answering. Or you were in forwarding mode, be that either native (just 53) or in dot mode (853 with encryption of the connection via tls) Now that you know normal dns works - you could go back to forwarding if you want. I personally not fan, but sure if you want to forward forward.. Only thing I would suggest if you forward is uncheck to do dnssec. It can only be problematic if you forward - where you forward either does dnssec already or it doesn't, if it doesn't telling unbound to do dnssec is just going to cause extra queries, and could cause problems. Also forwarding to different services can be problematic as well - especially if they do filtering, and the filtering could be different. Since you don't really know which one will be forwarded to when you have more than 1 service.. You are not sure which filtering you would get.. Its best if you forward to pick 1.

@TonyB972-0 said in WAN seems to be getting next hop IP address, not public IP address: 192.83.xxx.1 address that was not. 192.83 is public IP. Your maybe thinking of 192.168 which is rfc1918 btw - not sure where your using some 208.93.xxx.xxx, because your not talking to pfsense with that IP, nor does your history ever show you connecting with an IP that starts with those 2 octets.

@ayansaari Check your ACL configuration to see what IP Ranges are allowed to use the resolver service [image: 1762934081170-8c991ce8-5581-4d2f-9fa3-a9b88e14c490-image.png]

@mcfly9 said in ipv6 compatible checkip service?: I traced the code further, then I found the problem: dyndnsCheckIP returns false if the gateway is marked as down. My gateways don't respond to pings, hence pfsense marked them as down. As soon as I disabled gateway monitoring, it all started working. @Gertjan, @WN1X, thanks for the help! Change your gateway monitoring to something further upstream that pfSense can ping. Problem solved!

@helviojr said in Can pfSense's DHCP server update Microsoft DNS?: I miss the custom DHCP options that would be very helpful. I could do it hard-coded in the config generation script, but I'm sure it will be available in GUI soon enough. Which DHCP option ? Read again the page where ISC announced they stopped the famous 'dhcp' project, and restarted form scratch, rebuilding the DHCP server again. On the non-official page you'll find the reason : over the years, options were added. thousands of them. Some were written, debugged, and stable since. Some were changing all the time. Hardware vendors didn't stop adding and modifying them .... It had became a software-maintenance hell. ( a bit like the openvpn project, or have a look at the absolute champion : postfix - or the black angel, freeradius : that one is just frighting). So, they created a framework and a manual, and left it up to 'us' the user (a very special user : it's us, the admin users, so we need to admin stuff ones in a while, and this includes type in stuff) to know what option data is needed, and place it in a nice JSON format (yet another text file format with a very precis syntax, probably more strict as XML), test it ... and forget it. Believe me : it isn't that hard .... A (pfSense) GUI facility for every option would be best, of course, but I don't think Netgate will fall in this rabbit hole. Writing a GUI (pfSense or not) that handles all the DHCP option ? (and does all the verification and checking of consistency etc ..) ... you might be waiting a long time. Right now, imho, the kea v4 and v6 pfSense implementation is rock solid. Some support for DNS registration, static leases and even HA is possible. The option I needed were - surprise - asked in pfSense redmine, and examples were proposed. From there on, as I sa working examples, I made some of my own. Anyway, I know, I'm rambling a bit. Just saying : you can do it ^^

Agree That bug really does make alias much less useful. Two example I currently use aliases for which will fail with this bug White list for remote access to work server from periheral sites. The laptops will roam between sites Peripheral site DDNS FQDN Peripheral site relatively static IPv4 addresses Laptop 1 DDNS FQDN Laptop 1 DDNS FQDN White list from a VoIP supplier with redundant servers in multiple cities. During fault conditions the supplier redirects traffic to better functioning servers in another city city1.Voipsuppler.com city2.Voipsuppler.com city3.Voipsuppler.com city4.Voipsuppler.com city5.Voipsuppler.com city6.Voipsuppler.com city7.Voipsuppler.com city8.Voipsuppler.com Imo The variable FQDN component of an alias should be completely recalculated from scratch then combined with the constant (explicitly specified) IPs each time. After which only changes from the current IP addressees written to filterdns to update the firewall filtering.

Wow... ok figured it out. The links provided in @Gertjan post put me on the right path. It seemed strange that only Ubuntu Server hosts were affected so I started digging on that. Turns out that by default in Ubuntu Server systemd-resolved is not configured to use the domains passed by DHCP (either v4 or v6) not by RDNSS. So all I had to do was to edit /etc/systemd/networks/networkd.conf to have UseDomain=true and just like that, by magic the hostname is properly registered in Unbound...

.... or zap the legacy 127.0.0.1 and embrase the future : ::1 ** ** some restrictions may apply.

Hi again, @Gertjan Quick update, looks like the following config will do what I want: 'loggers' => [ [ 'name' => 'kea-dhcp4', 'output_options' => [[ 'output' => 'syslog' ]], 'severity' => config_get_path('kea/loglevel', 'INFO') ], [ 'name' => 'kea-dhcp4.leases', 'output_options' => [[ 'output' => '/var/log/kea-dhcp4.log', 'maxsize' => 512000, 'maxver' => 7 ]], 'severity' => config_get_path('kea/loglevel', 'INFO') ] ], Thanks again for your help! :)

Looks like this works now with KEA in 25.07.1 .

@McMurphy No - I am still using it, not a fan of current logging in kea.. And isc still works, there are not any security issues that would warrant switching. They have just stopped development of it is all. I have no need for the dhcp registration, etc. So just no point to me to switch at this time and more than likely cause my self grief when isc currently works exactly how I like it, etc.