@Gertjan I'm using ISC and DHCP registration is/was desired operation. So it looks like a bug. I did chmod 644 on the dhclient.leases.igb1 file and the log is looking much more healthier. I see it is Sending HUP signal to dns daemon(75158) Wrote 0 class decls to leases file. Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 3 leases to leases file. only thing i am seeing now is unknown dhcp option value 0x64

@johnpoz Thanks

@Antibiotic just to be complete, I added my homeCA to trusted, and now it validated the cert and trusts it user@UC:/$ kdig -d @192.168.2.253 +tls-ca +tls-host=doh.home.arpa nas.home.arpa ;; DEBUG: Querying for owner(nas.home.arpa.), class(1), type(1), server(192.168.2.253), port(853), protocol(TCP) ;; DEBUG: TLS, imported 147 system certificates ;; DEBUG: TLS, received certificate hierarchy: ;; DEBUG: #1, CN=doh.home.arpa,C=US,ST=IL,L=Schaumburg,O=Home,OU=Home CA ;; DEBUG: SHA-256 PIN: 1ooj7dE/is2fHGbRskOqdnb2Cg4OFm/93Pzy0MNObLk= ;; DEBUG: TLS, skipping certificate PIN check ;; DEBUG: TLS, The certificate is trusted. ;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 1939 ;; Flags: qr aa rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR ;; PADDING: 406 B ;; QUESTION SECTION: ;; nas.home.arpa. IN A ;; ANSWER SECTION: nas.home.arpa. 3600 IN A 192.168.9.10 ;; Received 468 B ;; Time 2024-11-04 11:00:02 CST ;; From 192.168.2.253@853(TCP) in 43.8 ms user@UC:/$ Notice it listed 147 now, since I added my homeca This is how sane client doing dot or doh should function, the cert being used should match cn/san and the CA that signed/issued that cert should be trusted by the system. Off the top I am not sure if when you forward with unbound if either of those is being done.. I am not a fan of doh or dot, I have no actual use case for them.. I resolve.. Only reason I fired up unbond to be able to do doh and dot was as a learning experience.. I have a thread around here somewhere where went over how to let unbound serve up doh to your local network, etc. I don't actually use it.. but I set it up and it works. Normally clients themselves would use doh, dot is more for NS to NS.. while you can click to get dot working with unbound internally, you need to add couple custom options to have it do doh.

@TheWaterbug I loved that camera the same technology requires a monthly charge if it doesn’t send data over seas. It was sad but I sent it back with notes and data on what it was doing to Amazon and they no longer sell it for the states. I had to admit most consumers do not have the ability to understand what is going on within a network at that level. This it was up to me to communicate the issues surrounding it.

Same on 2.7.2-RELEASE (amd64) I will keep ntop disabled until I need it and see if keeping it disabled keeps kea alive.

@johnpoz [image: 1730473388648-0bc9386a-ce69-433a-a7ba-e2a44c455fc5-image.png] Should the DNSSEC option be renamed to DNSSEC Validation or Enable DNSSEC Support ----> Enable DNSSEC Validation to be more descriptive? I can add a issue on redmine if you think this is suitable.

@vgauthier said in DDNS update issue with ISC DHCP and Bind9: no error in bind log about ddns updates Ok, great. But 'nothing' doesn't always means 'good news'. My "RFC2136" : [image: 1730471729848-74d2b9d6-8b70-4dac-9674-eea758f8871e-image.png] Whne I hit Save and Force update I see this 01-Nov-2024 15:32:56.327 update-security: client @0x7f3fdc3c9cd0 82.127.26.108#64128/key secretkey: signer "secretkey" approved 01-Nov-2024 15:32:56.327 update: client @0x7f3fdc3c9cd0 82.127.26.108#64128/key secretkey: updating zone 'bxxxx-hxxxx-fxxxx.fr/IN': deleting rrset at 'home.bxxxx-hxxxx-fxxxx.fr' A 01-Nov-2024 15:32:56.327 update: client @0x7f3fdc3c9cd0 82.127.26.108#64128/key secretkey: updating zone 'bxxxx-hxxxx-fxxxx.fr/IN': adding an RR at 'home.bxxxx-hxxxx-fxxxx.fr' A 82.127.26.y d in the bind (debug) log. @vgauthier said in DDNS update issue with ISC DHCP and Bind9: No error in dhcp log at all The tool nsupdate used to handle rfc2136 against bind is probably created by ISC DHCP, but it isnt' DHCP server that is doing the work. Btw : dhcp server can also register IP/hostnames in an (upstream) bind DNS server, but as my LANs are all RFC1918 it doesn't make sense to create records for those dhcp6 is another story. @vgauthier said in DDNS update issue with ISC DHCP and Bind9: My new dns server just don't seems to receive any forward IPv4 nsupdates As I showed above, mine does. That side, again, you probably have to filter and logs these, as default, there are not logged (maybe). The end of my /etc/bind/named.conf.options file : ogging { category "lame-servers" { lame; }; channel "lame" { file "/var/log/bind9/lame.log" versions 10 size 5m; print-time yes; print-category yes; severity dynamic; }; category "default" { "debug"; }; category "database" { "debug"; }; category "security" { "debug"; }; category "config" { "debug"; }; category "resolver" { "debug"; }; category "client" { "debug"; }; category "unmatched" { "debug"; }; category "network" { "debug"; }; category "update" { "debug"; }; category "dispatch" { "debug"; }; channel "debug" { file "/var/log/bind9/debug.log" versions 10 size 5m; print-time yes; print-category yes; severity dynamic; }; category "dnssec" { "dnssec"; }; channel "dnssec" { file "/var/log/bind9/dnssec.log" versions 10 size 5m; print-time yes; print-category yes; severity dynamic; }; channel "xfer" { file "/var/log/bind9/xfer.log" versions 10 size 5m; print-time yes; print-category yes; severity debug; }; category "xfer-in" { "xfer"; }; category "xfer-out" { "xfer"; }; category "notify" { "xfer"; }; channel "general" { file "/var/log/bind9/general.log" versions 10 size 5m; print-time yes; print-category yes; severity dynamic; }; category "general" { "general"; }; channel "b_query" { file "/var/log/bind9/query.log" versions 10 size 5m; print-time yes; print-category yes; severity dynamic; }; category "queries" { "b_query"; }; }; @vgauthier said in DDNS update issue with ISC DHCP and Bind9: instead my former dns server still receive the IPv4 forward nsupdate..... That's the answer to your own question

@ben_p static mappings can seem like they are working when the client already has the lease, and is just renewing it. Or hasn't renewed yet.. Keep in mind its "preview" its quite possible that even something that should work doesn't work how it should, etc. That it doesn't support options, could include dhcp reservations depending how you take that. Here is the thing with it being preview, I wouldn't count on it to function 100% even on something that it should do, etc. Why its a preview ;) All I can tell you from when I tested it when it first dropped, was yeah it hands out an IP.. Other that I switched back to isc very quickly - for one I use options, and static registration.

@johnpoz Yes, there is a perimeter Firewall behind FC modem. At the LAN Interface are the clients, WLAN, upnp ... Further there are two Datacenter Firewalls for DC1 and DC2 for HA. The ClientLAN 10.1.10 there are some Clients everything is virtualisesed (bhyve, BSD UNIX) on 3 little quad-core celerons and a old QNAP I don't need this really, it is only for playing around and understanding virtualization, ZFS, SDN networking, routing, network security and also standard systems as apache Webserver, tomcat, SQL Database, LDAP, on premise cloud ... everything HA clustered and all the other crazy things... ... so I have some more servers (4 native, 20 virtual) as I have clients (3) cheers Thorsten

@liquidity so take it pfsense is being used as your dns for a client.. so just do say a ping to pfsense fqdn, mine is sg4860.home.arpa See how it resolves to pfsense IP 192.168.9.253 $ ping sg4860.home.arpa Pinging sg4860.home.arpa [192.168.9.253] with 32 bytes of data: Reply from 192.168.9.253: bytes=32 time<1ms TTL=64 Reply from 192.168.9.253: bytes=32 time<1ms TTL=64 does that work for say www.google.com? if so then there is noting wrong with unbound resolving? Can you ping the ip of whatever fqdn your browser is complaining about.. For all we know your browser is using doh, without even asking you if it should/could - they like to do that of late. if your ping test to www.google.com does not come back with an IP, then yeah dns failed for some reason - go on pfsense via console or ssh and do a dig fqdn +trace example [24.03-RELEASE][admin@sg4860.home.arpa]/root: dig forum.netgate.com +trace ; <<>> DiG 9.18.20 <<>> forum.netgate.com +trace ;; global options: +cmd . 78700 IN NS l.root-servers.net. . 78700 IN NS j.root-servers.net. . 78700 IN NS f.root-servers.net. . 78700 IN NS h.root-servers.net. . 78700 IN NS d.root-servers.net. . 78700 IN NS b.root-servers.net. . 78700 IN NS k.root-servers.net. . 78700 IN NS i.root-servers.net. . 78700 IN NS m.root-servers.net. . 78700 IN NS e.root-servers.net. . 78700 IN NS g.root-servers.net. . 78700 IN NS c.root-servers.net. . 78700 IN NS a.root-servers.net. . 78700 IN RRSIG NS 8 0 518400 20241113050000 20241031040000 61050 . fYDbt3f4fnJ+NYpXj7e4NknpuMSoZl4H/OwQ5am4UdyvtpW8xIFMwMgW ZLps0HOzJ8Ia6pz3Y6cGOVSw455vKosRIGzeuBaek7mRdkVP2fDHUWQp 5VJ6v6oOGY5r3/rJc0qexe93wR1Lcb8RL3ksG1FudNUStJTdwNpsG7Pz qQ8t7xxNnVxoY9tb5oDtb7Rn9M7NFYf0pwj8h8TwhXeIpoIOiLuysYAD KGP7258lZ67w1VtwC6OkNht0cJ+3zhGhzR5Kdj6kj0Ke4MRonodv+Y33 6BWOMwB9jibUrIL4MXgYhfWpXKsNtpE1CMhg4rV5aw1kVi+TdFmsef7m bkH4rQ== ;; Received 525 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms com. 172800 IN NS l.gtld-servers.net. com. 172800 IN NS a.gtld-servers.net. com. 172800 IN NS d.gtld-servers.net. com. 172800 IN NS f.gtld-servers.net. com. 172800 IN NS c.gtld-servers.net. com. 172800 IN NS h.gtld-servers.net. com. 172800 IN NS g.gtld-servers.net. com. 172800 IN NS b.gtld-servers.net. com. 172800 IN NS k.gtld-servers.net. com. 172800 IN NS e.gtld-servers.net. com. 172800 IN NS j.gtld-servers.net. com. 172800 IN NS i.gtld-servers.net. com. 172800 IN NS m.gtld-servers.net. com. 86400 IN DS 19718 13 2 8ACBB0CD28F41250A80A491389424D341522D946B0DA0C0291F2D3D7 71D7805A com. 86400 IN RRSIG DS 8 1 86400 20241113170000 20241031160000 61050 . mRj9l6Xf3a0fx1R0RnAfMzy4ymu95VpVcLvMfbA006on5PzkIJKRVC4w qDScV8eIDF1SdhuARDTKLPk7e+kgWYa76xtUkiDEUaXYC/F3qHTKO9rU yo+zGRQSE7NCloBO76VCgtDhBS1gz0L3M2oYVxShOO947odr9uZBqfW0 PaW9pmQHAGrp1/HWvHDOZwDhOI5tjXgjz4ISIWMKpDCcj6DStSr4WQ85 9i2PjFd3RmIcCx3KqtnJO7CGBcBSD07aqR3/HLoFPIu24WuIUekJwZfG s10AxohnbwGVugPWdhvQmRckA+RQUl/3Q8kMv4x5XCZ4e7F3KpFrt0L4 9uybzQ== ;; Received 1180 bytes from 2001:dc3::35#53(m.root-servers.net) in 58 ms netgate.com. 172800 IN NS ns1.netgate.com. netgate.com. 172800 IN NS ns2.netgate.com. netgate.com. 172800 IN NS ns3.netgate.com. CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN NSEC3 1 1 0 - CK0Q3UDG8CEKKAE7RUKPGCT1DVSSH8LL NS SOA RRSIG DNSKEY NSEC3PARAM CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 900 IN RRSIG NSEC3 13 2 900 20241104002556 20241027231556 29942 com. 91X1yPcVakmmDBB4610js+PlS6tsWXkckWFbTVELLHTxMPp59zhHBr4l tmpQNcq+1jif9HVX3wzuMqzt562zlw== 2U53SUOKS8OJJV178M90A8BMNI9USDVJ.com. 900 IN NSEC3 1 1 0 - 2U54JL908MKCE6VDBRTOBQM3A838AA3F NS DS RRSIG 2U53SUOKS8OJJV178M90A8BMNI9USDVJ.com. 900 IN RRSIG NSEC3 13 2 900 20241105001627 20241028230627 29942 com. zRD7EMzYCFXLTHZWndVPumbBCIUgEj0be9sO7TyvDfqv7xbP0dv6Kh91 4GmdyBNMLHG6/zZURPkF8WWEExk8+g== ;; Received 589 bytes from 2001:503:d2d::30#53(k.gtld-servers.net) in 15 ms forum.netgate.com. 60 IN A 208.123.73.77 netgate.com. 3600 IN NS ns3.netgate.com. netgate.com. 3600 IN NS ns1.netgate.com. netgate.com. 3600 IN NS ns2.netgate.com. ;; Received 276 bytes from 34.197.184.5#53(ns3.netgate.com) in 36 ms [24.03-RELEASE][admin@sg4860.home.arpa]/root: This will show you how something is resolved, and where it is failing - if it is. or you can do from gui [image: 1730398279843-diag.jpg]

@Michael-Semugabi How is your WAN Interface configured? Is it blocking bogon networks?

@Wherewolf I personally not a fan of forwarding to start with, but yeah if its working, its working. And there are a few things you can do in dnsmasq that you can't in unbound in forwarder mode. Like query all the forwarders at once, and then there are other things you can do with unbound in forward mode that you can't in dnsmasq. but yeah you don't fix what isn't broke ;)

Thanks for the confirmation; the switch back to ISC was flawless, and everything is working fine.

@socrateberserk Glad to hear you got thinks working!

@juanzelli For what it's worth, I've activated 0x20 support since the day it became available : [image: 1729336277959-29582690-ecdf-4948-b623-99b1b3300c64-image.png] Btw : I'm resolving, and doing DNSSEC when available, I'm not using any commercial DNS solutions. Never had any DNS issues.

@wschvex I recapped this, click => unbound set SRV correctly ? You don't need the forwarder (dnsmasq), unbound can handle everything, and more. Keep in mind that the GUI page Services > DNS Resolver > General Settings and the advanced settings page only coberscobers the basic DNS needs. The rest ( you saw the rest ? ) are rarely used. That's why this : [image: 1729336093210-935c9e85-3ee1-4544-be0b-3ecb4e353dca-image.png] exist. Keep in mind : syntax errors are not allowed !

@Gertjan Still ISC.

I wonder if a raspberry pi zero could do it???