@patient0 said in DuckDNS IPv6 update URL ?: e the 'Custom (v6)' template Thanks a lot for your post. I was trying to get IPv4 and IPv6 to work all on the same line. for future me to set this up again: Make two Dynamic DNS Clients, one for IPv4 and another for IPv6. Service Type = Custom (v6) Interface to monitor = WAN HTTP API DNS option = check Force IPv4 DNS Resolution Update URL = notes above Results Match = OK Without checking the HTTP API DNS option I would get an error in the system logs saying. I'm embarrassed how long it took me to figure out what was going on. 'ERROR [phpDynDNS] Curl error occurred: Could not resolve host: www.duckdns.org '

Ah this one's on me. I had some json buried in a static mapping in that subnet that I was trying to use to disable the hostname from being sent out. Obviously kea didn't like that. It would've been really helpful to see the contents of the file that was actually being used by kea when it failed to launch. It seems that as soon as it fails, pfsense reverts the file and restarts.

@johnpoz said in Resolver oddity: that is has nothing to do with the update to 26.03 though Yeah.. I didn't think so because it has been working flawlessly up till now.. Thanks for digging. Ill give them a call.

That's how one typically settles for kludge, sure.

@RianKellyIT said in DNS resolution issues after 26.03 update: Under Services > DNS Resolver, there's a Forward Zones section ?? The only 7 instances of "forward" on the page are under "DNS Query Forwarding"...

The UNKNOWN class in that allocation failure is the key clue. KEA uses client classification to control which pool an address comes from. When a client shows as UNKNOWN in the allocation failure message, it usually means either the pool has a require-client-classification directive that this client does not satisfy, or there is a client-class restriction on the pool that excludes clients in the UNKNOWN class. Check your kea-dhcp4.conf - if any of your pools have client-class or require-client-classification set, that is likely why this client is being rejected. Also worth checking: is the MAC 90:72:40:02:ec:47 appearing from the expected interface? If that device is somehow arriving on a different VLAN or interface than where the pool is bound, KEA might not be matching it to the right subnet/pool definition at all.

Further clarification. DDNS is working fine for the IPV4 version of route53.

@markster @markster said in Unbound control port config: I thought by default the config file would be read. And you were / are correct. Be aware of this : if you didn’t supply the path of unbound config file when you use unbound-control, the default file and 'place' will be used : [26.03-RC][root@pfSense.bhf.tld]/root: ll /usr/local/etc/unbound/unbound.conf -rw-r--r-- 1 root wheel 57194 Feb 3 09:31 /usr/local/etc/unbound/unbound.conf The thing is : this is a default file, not used by pfSense (and unbound). The real unbound config file is here : /var/unbound/unbound.conf Use unbound-control -c /var/unbound/unbound.conf ...... Btw : make live way easier : use the console or SSH access

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