Bind + ISC dhcpd integration (for intranet split-horizon, etc)

[Philip Prindeville]

Responses…


> On Dec 17, 2020, at 1:56 AM, Bjørn Mork <bjorn at mork.no> wrote:
> 
> Philip Prindeville <philipp_subx at redfish-solutions.com> writes:
> 
>> https://github.com/openwrt/packages/pull/14240
>> 
>> The previous one is a precursor for getting Bind to start before DHCPD.
> 
> 
> That makes more sense yes.
> 
> I looked at it briefly. A couple of notes without testing:
> 
> I would not have used a key named "rdnc"-anything for zone updates.
> rndc is the remote management tool for BIND, and most users will
> probably assume that a key with such a name is dedicated to restricting
> rndc access.


Okay, I’ll rename the key.  So it should be a separate key from the one that rndc uses for reloads, etc?


> And I would have defined a limited "update-policy" for each key/identity
> instead of using "allow-update".  You probably only want the DHCP server
> to modify A records in the forward zone and PTR records in the reverse
> zone.


Can you walk us through that?


> Alternatively, you might want to consider "update-policy local" since
> BIND and the DHCP server runs on the same host.


Well… maybe not necessarily.  I’m thinking about how to support distributed DHCP servers, and getting keys out to the DHCP servers so they can be authoritative for subnets that they’re responsible for, but still push updates to a single intranet DNS server.


> This has the advantage
> that only local clients are allowed to do updates.  BIND will
> automatically generate a HMAC-SHA256 session key named “local-ddns” and
> store it in /var/run/named/session.key (These defaults can be adjusted
> using session-keyfile, session-keyname, and session-keyalg options).
> Just point the DHCP server to that file and key name.


Hmmm… That seems both handy and risky at the same time.

And…

https://kb.isc.org/docs/aa-01599

Turns out it was risky.  But fixed now, so… here goes.

Please see the updated PR.

-Philip



> Bjørn