@Gertjan great question, I totally missed that.

Check a few things here. From your Mac terminal run nslookup xdisk.home.xyz.com <pfsense-ip> directing the query explicitly at pfSense. If that resolves correctly then your DNS config is fine and the issue is your Mac is sending queries to a different server. Second check via scutil --dns on the Mac that pfSense is the first nameserver listed and the search domain includes your local domain. Also in pfSense under System > General Setup verify the domain field matches exactly what you have in your FQDN attempts. If the resolver returns a correct answer when queried directly but the Mac still fails, the DHCP search domain option is likely not getting passed correctly to the client. Shout if you need more details.

@Gertjan Tried it with the GS308T I had around and indeed that solved the issue.

I have finally found a solution that works, even if it is not ideal. The network previously worked well in the following scenarios (external users, internal users via ISP B, VPN and DoH), whereas it did not work with internal users via ISP A (DNS rebind attack). I have forced both internal traffic to the website and DNS traffic via ISP B using the Fortinet firewall SD-WAN rules (this prevents ISP A from manipulating the DNS). Thank you

@bearhntr said in What is the 'Globe' icon for...: a 'circle with check' instead of the 'person' If you hover there's a tooltip/title. The check is an active lease, the silhouette is a static lease. A guess: do you have early DNS registration enabled? "When checked, DHCP static mappings will automatically be pre-registered with the DNS Resolver."

I already tried that option, but it does not provide much information; see below. If I try the default : "curl http://checkip.dyndns.org" location from within PFSense it gives me the correct IP address. Mar 14 15:22:38 /services_dyndns_edit.php Dynamic DNS (XXXX.bujold.ca) There was an error trying to determine the public IP for interface - wan (ix0 ). Mar 14 15:22:38 /services_dyndns_edit.php Dynamic DNS: updatedns() starting

@pfpv said in Dynamic DNS issues: lost cached IPs, taking very long to force update, updating twice etc.: I wonder if someone could look into DynDNS in more details ... I'll show it here for easy access. This file is present on every pfSense. Sure enough, not everybody uses DynDNS, but I do think that many admins that want to have a remote access for admin purposes use DyNDNS. After all, many (again) don't have a static WAN IP. This means that the code shown is executed on all the pfSense installation every time a WAN IP changes. I guess you understand what I mean : if 'dyndns.class' would file for all ? most ? some of us all the time, there would be failures all the time everywhere. People wouldn't be able to contact their pfSense anymore ... (WAN IP is wrong) and you would see thousands of 'angry' posts here on the forum per hour ( !! ) Guess what ? I saw none. Which implies that it does work. Just not for you. On the other hand, look again at the https://github.com/pfsense/pfsense/blob/master/src/etc/inc/dyndns.class page. You can see the History of that file. This file gets edited rather often, as all these dyndns operators do change their parameters ones in a while. Check the forum - this forum part. Last year, porkbun and NameCheap did change their dyndns access parameters, and they do so without informing the clients ( why should they ? It's free ^^ ). So, yes, things can break, and it won't take days before some one would post here about it. For all 3 to break at the same moment ? Hummmm .... I don't use dyndns anymore myself but the other one "RFC 2136" which is the first, 'original' dyndns as I use my own DNS name servers. What I do know : it takes mere seconds to execute, as I execute it against my own server, and I don't have to throttle this access, as all 'private' companies have to as they have to handle "millions of dyndns updates" from 'everybody. @pfpv said in Dynamic DNS issues: lost cached IPs, taking very long to force update, updating twice etc.: When I edit .... Don't forget the magic option : [image: 1773394457039-811ca33a-d286-45e1-a444-0ead63a0b35e-image.png] as you are wondering why and what takes so much time ? You've thought about asking pfSense to show you why ? with this option set, go dydns logs and see what happens when, what errors out, and how long it took. When you see an issue, you'll know why it happened. @pfpv said in Dynamic DNS issues: lost cached IPs, taking very long to force update, updating twice etc.: 3 In previous versions of pfSense It's still there. Install the Cron pfSense package. Then, go here : Services > Cron > Settings [image: 1773393013159-f3199358-8d6f-4d2f-86e0-3ad4e7117394-image.png] so every first of the month, dyndns is executed. This doesn't mean the WAN IP is updated 'no matter what'. The current WAN IP is determined with Services > Dynamic DNS > Check IP Services = http://checkip.dyndns.org - click on the link and you see what happens. If the obtained IP is the same as the cache file IP, the cache file's time stamp is updated, the IP stays unchanged. And NO remote update is performed, as this wasn't needed. The file is here : /cf/conf/, mine is called dyndns_wan_rfc2136_'home.bhf.tld'_188.x.x.x.cache. It contains the cached IP, and a time stamp. Updating IP at a dyndns supplier with a not changed IP is considered abusive, and the reaction of the dyndns supplier could be : you're blocked or banned. This seems over exaggerated, but they have good reasons to act like that. @pfpv said in Dynamic DNS issues: lost cached IPs, taking very long to force update, updating twice etc.: I feel like it was left alone I think it's one of the most executed scripts on pfSense ... ;)

@Gertjan In my last packet capture I used another device, therefore the mac address difference. The Lease is denied upon entering bound looked weird to me, as the .53 is the PXE server and it should not be responding to any DHCP request since the gateway .1 has to. What we did next is made sure I block inbound port 67 on the .53 (PXE server). Then packet capture looked liked this: 10:33:09.366450 a8:2b:dd:6b:80:5f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 389: (tos 0x0, ttl 64, id 57999, offset 0, flags [none], proto UDP (17), length 375) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from a8:2b:dd:6b:80:5f, length 347, xid 0x8463ff2, Flags [Broadcast] (0x8000) Client-Ethernet-Address a8:2b:dd:6b:80:5f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Discover MSZ (57), length 2: 1472 Parameter-Request (55), length 35: Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4) IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13) Domain-Name (15), RP (17), EP (18), RSZ (22) TTL (23), BR (28), YD (40), YS (41) NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51) Server-ID (54), RN (58), RB (59), Vendor-Class (60) TFTP (66), BF (67), GUID (97), Unknown (128) Unknown (129), Unknown (130), Unknown (131), Unknown (132) Unknown (133), Unknown (134), Unknown (135) GUID (97), length 17: 0.0.158.211.19.126.180.240.17.128.191.159.198.84.14.38.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 10:33:09.369504 90:ec:77:94:34:37 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 357: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 343) xxx.xxx.xxx.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 315, xid 0x8463ff2, Flags [Broadcast] (0x8000) Your-IP xxx.xxx.xxx.30 Server-IP xxx.xxx.xxx.53 Client-Ethernet-Address a8:2b:dd:6b:80:5f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Offer Subnet-Mask (1), length 4: 255.255.255.0 Default-Gateway (3), length 4: xxx.xxx.xxx.1 Domain-Name-Server (6), length 4: xxx.xxx.xxx.7 Domain-Name (15), length 6: "mydomain" Lease-Time (51), length 4: 7200 Server-ID (54), length 4: xxx.xxx.xxx.1 BF (67), length 31: "\boot\efiboot\amd64\bootx64.efi" 10:33:09.373175 00:0c:29:e0:55:2c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 322: (tos 0x0, ttl 128, id 45651, offset 0, flags [none], proto UDP (17), length 308) xxx.xxx.xxx.53.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 280, xid 0x8463ff2, Flags [Broadcast] (0x8000) Server-IP xxx.xxx.xxx.53 Client-Ethernet-Address a8:2b:dd:6b:80:5f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Offer GUID (97), length 17: 0.0.158.211.19.126.180.240.17.128.191.159.198.84.14.38.0 Vendor-Class (60), length 9: "PXEClient" Server-ID (54), length 4: xxx.xxx.xxx.53 10:33:12.693431 a8:2b:dd:6b:80:5f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 395: (tos 0x0, ttl 64, id 58000, offset 0, flags [none], proto UDP (17), length 381) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from a8:2b:dd:6b:80:5f, length 353, xid 0x8463ff2, Flags [Broadcast] (0x8000) Client-Ethernet-Address a8:2b:dd:6b:80:5f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Request Server-ID (54), length 4: xxx.xxx.xxx.53 MSZ (57), length 2: 65280 Parameter-Request (55), length 35: Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4) IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13) Domain-Name (15), RP (17), EP (18), RSZ (22) TTL (23), BR (28), YD (40), YS (41) NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51) Server-ID (54), RN (58), RB (59), Vendor-Class (60) TFTP (66), BF (67), GUID (97), Unknown (128) Unknown (129), Unknown (130), Unknown (131), Unknown (132) Unknown (133), Unknown (134), Unknown (135) GUID (97), length 17: 0.0.158.211.19.126.180.240.17.128.191.159.198.84.14.38.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 10:33:12.698998 00:0c:29:e0:55:2c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 406: (tos 0x0, ttl 128, id 45652, offset 0, flags [none], proto UDP (17), length 392) xxx.xxx.xxx.53.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 364, xid 0x8463ff2, Flags [Broadcast] (0x8000) Server-IP xxx.xxx.xxx.53 Client-Ethernet-Address a8:2b:dd:6b:80:5f file "a8-2b-dd-6b-80-5f\boot\efiboot\amd64\bootx64.efi" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: ACK GUID (97), length 17: 0.0.158.211.19.126.180.240.17.128.191.159.198.84.14.38.0 Vendor-Class (60), length 9: "PXEClient" Server-ID (54), length 4: xxx.xxx.xxx.53 Unknown (200), length 4: 1669485411 Unknown (201), length 46: 360,29812,28730,12079,25456,29541,29302,25970,11873,27757,25976,24878,27759,25441,27706,13616,13104,12131,26991,29540,25968,27759,30976 Unknown (202), length 28: 795240812,1702047585,1886415977,1667331177,1869492079,1935958892,1768255092 10:33:12.699037 a8:2b:dd:6b:80:5f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 329: (tos 0x0, ttl 64, id 58001, offset 0, flags [none], proto UDP (17), length 315) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from a8:2b:dd:6b:80:5f, length 287, xid 0x8463ff2, Flags [Broadcast] (0x8000) Client-Ethernet-Address a8:2b:dd:6b:80:5f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Decline Server-ID (54), length 4: xxx.xxx.xxx.53 MSG (56), length 35: "Lease is denied upon entering bound" That much with this theory. Since it was already urgent and we had to make it work, what we did next was go to Firewall --> DHCP server --> (Click on our VLAN) --> and check the box next to Do not record a unique identifier (UID) in client lease data if present in the client DHCP request, then Status --> Services --> Restart kea-dhcp4 service Now everything works as it should, here is a packet capture from a working PXE boot: 10:48:13.603483 a8:2b:dd:6b:80:5f > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 401: (tos 0x0, ttl 64, id 25450, offset 0, flags [none], proto UDP (17), length 387) 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from a8:2b:dd:6b:80:5f, length 359, xid 0x27ce53d9, Flags [Broadcast] (0x8000) Client-Ethernet-Address a8:2b:dd:6b:80:5f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: Request Server-ID (54), length 4: xxx.xxx.xxx.1 Requested-IP (50), length 4: xxx.xxx.xxx.30 MSZ (57), length 2: 65280 Parameter-Request (55), length 35: Subnet-Mask (1), Time-Zone (2), Default-Gateway (3), Time-Server (4) IEN-Name-Server (5), Domain-Name-Server (6), Hostname (12), BS (13) Domain-Name (15), RP (17), EP (18), RSZ (22) TTL (23), BR (28), YD (40), YS (41) NTP (42), Vendor-Option (43), Requested-IP (50), Lease-Time (51) Server-ID (54), RN (58), RB (59), Vendor-Class (60) TFTP (66), BF (67), GUID (97), Unknown (128) Unknown (129), Unknown (130), Unknown (131), Unknown (132) Unknown (133), Unknown (134), Unknown (135) GUID (97), length 17: 0.0.158.211.19.126.180.240.17.128.191.159.198.84.14.38.0 NDI (94), length 3: 1.3.16 ARCH (93), length 2: 7 Vendor-Class (60), length 32: "PXEClient:Arch:00007:UNDI:003016" 10:48:13.610271 90:ec:77:94:34:37 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 357: (tos 0x10, ttl 128, id 0, offset 0, flags [DF], proto UDP (17), length 343) xxx.xxx.xxx.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 315, xid 0x27ce53d9, Flags [Broadcast] (0x8000) Your-IP xxx.xxx.xxx.30 Server-IP xxx.xxx.xxx.53 Client-Ethernet-Address a8:2b:dd:6b:80:5f Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: ACK Subnet-Mask (1), length 4: 255.255.255.0 Default-Gateway (3), length 4: xxx.xxx.xxx.1 Domain-Name-Server (6), length 4: xxx.xxx.xxx.7 Domain-Name (15), length 6: "mydomain" Lease-Time (51), length 4: 7200 Server-ID (54), length 4: xxx.xxx.xxx.1 BF (67), length 31: "\boot\efiboot\amd64\bootx64.efi" 10:48:13.620307 00:0c:29:e0:55:2c > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 406: (tos 0x0, ttl 128, id 45659, offset 0, flags [none], proto UDP (17), length 392) xxx.xxx.xxx.53.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 364, xid 0x27ce53d9, Flags [Broadcast] (0x8000) Server-IP xxx.xxx.xxx.53 Client-Ethernet-Address a8:2b:dd:6b:80:5f file "a8-2b-dd-6b-80-5f\boot\efiboot\amd64\bootx64.efi" Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message (53), length 1: ACK GUID (97), length 17: 0.0.158.211.19.126.180.240.17.128.191.159.198.84.14.38.0 Vendor-Class (60), length 9: "PXEClient" Server-ID (54), length 4: xxx.xxx.xxx.53 Unknown (200), length 4: 1669485411 Unknown (201), length 46: 360,29812,28730,12079,25456,29541,29302,25970,11873,27757,25976,24878,27759,25441,27706,13616,13104,12131,26991,29540,25968,27759,30976 Unknown (202), length 28: 795240812,1702047585,1886415977,1667331177,1869492079,1935958892,1768255092 Regarding the IP addresses, yes they are RFC1918 (but I have to sanitize the output either way, story for another time). Any explanation as to why this may happen? Possibly a bug with KEA DHCP?

@ChrisJenk well the more complex a setup you make, yeah the more work it is to maintain ;) You could just take the simple route and allow anything local to resolve your local resources - if you don't want guest to talk to them, easy enough in don't allow via your firewall rule.. My tinfoil hat just isn't that tight, that I could care that some guest on my network resolves a local domain host to an IP, that it can't even talk to in the first place ;) Also wonder why some guest would go looking for some fqdn it doesn't even know in the first place. Or for that matter be doing a ptr scan of networks, again that why would it even know these other networks exist? Not sure why I would ever run a local ns with a public zone in it, forward or reverse unless the NS was the authoritative ns (soa), but in this day an age makes little sense to do that when there are plenty of places to host public dns that is going to be far more robust, global cdn with anycast, etc. Many times free. If its public host it public. 1 place to update.. If you want to point local resources to a local IP vs the public ones - simple host override. Now my domains don't get millions of queries a day or anything - but cloudflare provides free dns.. Not sure if there is some limit to how many domains you can host for free or how many queries you can have? But they provide pretty much every possible record type or dns thing you can do. But there are also paid solutions. That vs cost and complexity of running your public authoritative NS local would be well worth the cost. But again, its your network - you do you.

I linked to where I went over how to do this in and old thread, and I even put in quick how to with the details in this thread.. So at a loss to why you are asking @ChrisJenk how he did it.. Its not difficult access-control-view: 192.168.3.0/24 Block view: name: "Block" local-zone: "home.arpa" static local-zone: "168.192.in-addr.arpa." static Put in your own domain and network(s) etc..

@Gertjan it’s the kea2fib6 process that generates the log outputs. Think I introduced confusion by capturing the Unbound pushes. To your point; I don’t need them DNS registering and have disabled the function. Issue still persists. How is no one else hitting this issue bar me..? 100 IOT devices isn’t outlandish to utilise against a kea dhcp6 server.

@SteveITS I use U6 as access point with 2 SSID, one VLAN on each. Since the configuration is right on the pfSense, I will try to change/reset the AP

@bschapendonk said in NANOG 96 You Don't Need The DNS Root Server System: maybe privay to a degree) Privacy? What privacy? So your upstream doesn't know you asked for the ns of .com domain? When in the next few miliseconds you gonna ask a .com ns for the ns of say.. pornhub As for load, caching is almost always there with a very high hit rate, so not much to gain here too. Redundancy? Really? If root ns go down globally, local copy will be the least of your problems. And if everybody downloads the root ns file very often, the load to root servers could be even higher. On the other hand, maintaining yet another file isn't a good idea. Things will not go wrong, and then the file is corrupted , just because, and there you go.

Just a quick update to say I did a bit more testing, in case it was something odd specific to the specific combination of FreeMyIP and the new PPPoE driver. After doing some testing with deSEC it also seems to be affected by the same issue. When using the new PPPoE driver it is also unable to update the Dynamic DNS record, with the log showing a timeout. Additionally curl requests using the --interface parameter to deSEC.io time out. As with FreeMyIP, deSEC also works fine when disabling 'Use if_pppoe kernel module for PPPoE client' so it looks like the new PPPoE driver is doing something odd with packets originating from the firewall itself causing some web requests via curl to fail/timeout, thus stopping Dynamic DNS updates from working. Hopefully the above is useful if anyone else comes across the same issue in the future.

@SteveITS so finally noticed the error I was thinking in isc about lease too early.. when a client asks for renew Feb 6 18:06:26 dhcpd 94617 reuse_lease: lease age 19813 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.2.212 Just more info to throw out there - where you could consider this as log spam from possible bad acting clients. I am seeing this from a few different clients Feb 3 13:31:51 dhcpd 26941 reuse_lease: lease age 18375 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.203 Feb 3 13:31:48 dhcpd 26941 reuse_lease: lease age 18372 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.4.203 It's possible I introduced this - this thread got me looking at my dhcp log, and noticed was seeing log about duplicate leases on a few devices, etc. stuff was working but seemed to have some old leases handing around where a client had 2 different leases.. I think this related to how I will bring a client up on normal dhcp, and then set a reservation.. Going forward when I bring up a new client going to set a reservation will make sure delete their old lease. In going over my dhcp server I also noticed some of my scopes had lower lease time than I like. So I had adjusted them, so client would not have known this. So possible when I raised the min lease time, clients trying to renew their old lease time didn't match up to the new lease time? Also could be just wireless clients going off net and then back on or something - will have to look into the IPs seeing these to early log entries. And when they come back on they try a renew even though lease has not gotten to the 50% mark as of yet. I know that 203 is my wifes iphone (old one) and 212 is one of the new iphones (not sure which one yet) since both me and the wife upgraded our phones yesterday. I need to setup their reservations ;) My point is more to yeah you will almost always have some sort of log entries that seem like spam to you. I do believe if you can reduce it all the better, or at least understand it. Entries in a log that are of no use to you just make it harder to spot stuff you are interested in. And yeah you can have bad acting clients, and stuff not quite sure what it is can send you on a wild goose chase sometimes if trying to solve a problem. If kea is logging stuff about some subnet, as long as the client is getting an IP. Maybe with all the fancy stuff you can do with kea logging you can get it to stop logging what amounts to spam if the client is actually getting an IP, etc. edit: Ok I am just an idiot for not looking in redmine first, there is already a bug listing for this https://redmine.pfsense.org/issues/16684 So that explains it ;) And there seems to be a fix for it https://redmine.pfsense.org/issues/16682 Now have to try it out.

I figured my issue out... and it's a funny goof and even after fighting this for 5 DAYS now... I just have to laugh at myself... on the i350-T2, One port I have it set as a VLAN port (igb0.125) as I'm expecting my IoT to go throughout the house, and the other is just a port that serves an IP (using dumb APs/switches on this port).. well I goofed and accidentally had set my Guest port in my assignments to igb0 and not igb1.... SOB.. 5 days.. hahaha I realized when I started to try to troubleshoot this more and realized in Packet Capture, looking at the capture options that both LANs referenced igb0... Thanks guys.. my issue was me... Vin

@user_not_found said in /services_dyndns_edit.php: Curl error occurred: Could not resolve host: route53.amazonaws.com: Java On a router ? For some minor GUI stuff, maybe. pfSense using for the vast majority PHP, some shell scripts, some python stuff. Years ago, some one (he knows who he is) said that the entire thing should have to be rewritten in Python ... Maybe Rust these days. I still vote for Ansi C. @user_not_found said in /services_dyndns_edit.php: Curl error occurred: Could not resolve host: route53.amazonaws.com: VSCode What's wrong with Notepad++ ?