Thank you for adding this! I never knew what it was for.
Please add a filled out image as an example (filed-out example is better than not). I’ll finish reviewing a little later today.
Done. Please let me know if the text is understandable. I omitted some detail, like the fact that the message format is similar to that of a standard DNS query but contains additional fields and semantics to indicate that it’s an update rather than a query. Therefore it is sent through an UDP protocol.
@cfusco, Thx for your description.
But I can’t find a explanation about the relation of RFC2125, unbound-leases-bridge, dhcpd and unbound.
Especially how reaches the ‘secret key’ from dhcpd config the unbound component?
That is also the part that I do not understand. The key it is saved in /var/ipfire/dhcp/dhcpd.conf but I cannot find where it is saved on Unbound. It should be preshared between the two services.
EDIT: from what I can gather, unbound-dhcp-leases-bridge is involved. unbound-dhcp-leases-bridge would monitor the DHCP leases from dhcpd and ensure that unbound is made aware of any DNS changes due to dynamic IP address assignments. This bridge allows for dynamic DNS functionality even when unbound itself doesn’t natively support DNS UPDATE as described in RFC 2136.
After some search I find a convincing evidence that Unbound does not support RFC2136.
Reference: Unbound GitHub Features
No TSIG support at this time. No SIG0 support at this time.
The unbound-dhcp-leases-bridge, as far as I understand, lacks a mechanism to facilitate communication between DHCPD and Unbound using a preshared key. It appears this feature is inoperative with Unbound. It may function with a resolver like bind but won’t integrate with Unbound. If we can get developer confirmation, we should update the wiki for user clarity.
It all looks good. Thank you
I am not so sure. Unless I am very wrong, this feature’s activation disables DHCP DNS registration entirely. If we can confirm this, we should add a sentence stating that this feature, at least for now, should be used only in conjunction with another DNS system - upstream to Unbound - capable of handling RFC2136 signed messages.
I did not review this “technically” since I know little to nothing about DNS Update. I hate to say this but I rely on the Author for that part.
If you feel it doesn’t work as intended, then someone needs to test and document a bug. Or add a “may not work as intended” type note to the wiki
I am guessing the Core Devs are very busy with the next version and don’t have time to review unless it is a bug.
Of course. I’m confident in the accuracy of the provided information. However, there should be a warning indicating that enabling DNS update with Unbound will result in the complete deactivation of DHCP DNS registration.
@jon and the rest of the community, I added the following sentence. Please review the change.
It’s essential to note that Unbound itself does not directly support RFC2136. As such, DNS registration is managed behind the scenes by the bridge script using a different method. Activating the DNS Update feature without redirecting updates to a different name server that supports RFC2136 will disable this capability.