Extract from OpenWRT dependencies
Opened this issue · 5 comments
This is an interesting project. Unfortunately it seems pretty tied to OpenWRT and it's use of dnsmasq etc. at the moment.
It would be interesting to see how well this could be ported to a more generic environment.
Assume I don't use OpenWRT for example, but do run ISC dhcpv4 (for IPv4 address management) and bind9 with DDNS updates from dhcpv4. IPv6 is configured with SLAAC so what is missing of course is updating bind9 using DDNS for SLAAC (self-)assigned addresses.
I cannot see why this tool could not run on say, the bind9 recursive resolver host that every host in the network has to use and have it doing DDNS updates to bind9.
Thoughts?
All good points, and I'll let Andre weigh in. But I suspect the window to generalize the project may have passed. Since ip6neigh gets names from the DHCPv4 server, this really only works in dual-stack networks, which is not the end goal. IPv6-only networks are the end goal.
BTW, I run ISC bind9 as my main DNS server, and have been hand populating the zone file with the stable SLAAC addresses of the hosts on my network for years. I run 4 networks, including IPv6-only with DNS64/NAT64, and ISC bind9 provides the SOA for all of it.
FWIW, I have already started on this process. I have ip6neigh-svc.sh stripped back far enough to run outside of OpenWRT and it's running right now, populating a hosts file. Next step is to plumb in nsupdate. I am using /etc/ethers as my source of host-names at the moment, however it has not been lost on me to use the ISC DHCPv4 lease info as many of the hosts have host stanzas in dhcpd.conf with names.
But my eventual goal, and really the driving need to be able to have DDNS for SLAAC configured hosts is to eliminate IPv4 from my network, so DHCPv4 lease info is not really a sustainable source.
Once I have an OpenWRT-less implementation, it can be seen about how to make the core generic and plug-in different operating models. If that goal is desired here in this project. If not, I can just fork it and maintain the non-OpenWRT version of this project.
I do think more people are served by trying to make this project the canonical implementation that supports more than just OpenWRT though.
It certainly is more churny than using DHCP:
Thu Mar 10 11:26:23 EST 2022 Added host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
Thu Mar 10 11:35:37 EST 2022 Removed host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
Thu Mar 10 11:42:02 EST 2022 Added host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
Thu Mar 10 12:43:25 EST 2022 Removed host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
Thu Mar 10 12:52:53 EST 2022 Added host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
Thu Mar 10 13:05:01 EST 2022 Removed host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
Thu Mar 10 13:17:38 EST 2022 Added host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
Thu Mar 10 13:20:40 EST 2022 Removed host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
Thu Mar 10 13:20:53 EST 2022 Added host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
Thu Mar 10 13:28:44 EST 2022 Removed host: fd31:aeb1:48df:0:7dcb:adcd:a0f4:64fc
That's running on the subnet's recursive resolver. So should have it's neighbor table kept fresh as frequently as the hosts need name resolution.
But it does seem to flap a lot. I could see wanting to resolve a name while the neighbor table on the DNS server didn't have an entry for the host. I wonder if it needs some kind of "hang time" after the host disappears from the neighbor table to account for this.
Hey, that is great news. What event are you using to sniff the neighbour table? You will see hosts move to "STALE" state quite often.
I'm using the existing main_service() function to process the neighbour table and writing the hosts to a file. No plug in of nsupdate yet.
I do see hosts move to STALE, quite often indeed. Nothing seems to happen as a result of it though.
TBH, I have not had time to audit the results closely enough yet to move on to plugging in nsupdate. Too many other things are getting in the way.