Glue for exporting DHCP provisioning into Bind

[Philip Prindeville]

Inline...

> On Apr 14, 2018, at 12:47 AM, Lars-Johan Liman <liman at netnod.se> wrote:
> 
> Hi!
> 
> philipp_subx at redfish-solutions.com:
>> I’m the maintainer of the ISC-DHCP package for OpenWrt, and I’m
>> working on some glue scripts to take statically provisioned DHCP
>> leases and prime those into Bind as well (assuming this changes
>> infrequently and doing it at the next reboot is adequate).
> 
> (Depending on the software you're using, you might be able to rely on
> existing functionality. See below.)
> 
>> It mostly works but doesn’t entirely support partial in-addr.arpa zone
>> delegation via RFC-2317.
> 
> RFC 2317 is an "Interesting Hack(TM)". It's not rocket science, though,
> and it should be quite possible to make this work - even using DynUpd.


Well, I think I have it right.  If you have time, download:

https://www.redfish-solutions.com/misc/named.tar.gz

That’s my /tmp/bind tree.  Because I’m not using templating, I’ve avoided using the $GENERATE directive.

I tried to go with the subnet-base-slash-prefix method described in RFC-2317 (section 4) as it seemed the most flexible, at least for RFC-1918 addresses.

I guess I need to tune my scripting to handling RFC-1918 addresses differently from the rest… or maybe not.  See below.

I’ll need to think about that.  The scripting (almost all in shell) is straightforward enough, and I’ll probably put that up on GitHub soon.

I’m thinking about the case where we might have:

ns.acme.com — the top-level name server for all hosts inside of acme.com (and their reverse bindings)

router1.acme.com — the router with the DHCP pools on 192.168.1.0/24 and 192.168.2.0/24

router2.acme.com — the router with the DHCP pools on 192.168.3.0/24 and 192.168.4.0/24

Now it’s easy enough to make router1 and router2 be authoritative for their own reverse domains.

It’s also easy to point them ns.acme.com for everything else inside of 168.192.in-addr.arpa.

And it’s easy to have delegation records for 1.168.192.in-addr.arpa pointing at router1, etc.

What’s hard is having both router1 and router2 having leaves directly under acme.com that they are authoritative for… unless we just push that data directly into ns.acme.com from router1 and router2.

Right now I’m using this in the SoHo scenario where there’s no other router2, and there’s no ns.acme.com … router1.acme.com is authoritative for the entire domain (and the rDNS as well).

But I would like to do this right.

I’d also like to handle the case of split-horizon and non-RFC 1918 addresses, assuming there’s some difference there that I’m not aware of (other than not leaking the addresses out any queries arriving on public interfaces for the routers if they’re also firewalls… i.e. doing split horizon so that we can resolve hosts that are on the 192.168.x.x networks for other internal hosts, but not for queries arriving on the public interfaces).


> 
>> Adding dynamic updates would allow for near-realtime changes in the
>> provisioning, and that would be nice. Since it’s local, I could do it
>> on localhost:53 trusted without having to mess with key management,
>> etc.
> 
>> Adding dynamic updates would also help with unprovisioned hosts that
>> take dynamic leases from the unassigned pool.
> 
> This doesn't sound like rocket science. Should be doable.
> 
>> Does anyone have experience doing this previously?
> 
> Yes.
> 
> If you're using ISC's DHCP system and BIND, I'd say this works out of
> the box. Everything You Need Is There(TM). It's just a matter of
> configuring it. OK, that was a bold statement ... ;-) I don't really
> know what you need, but there are lots of tools to deal with this in
> place already in ISC's stuff.


It’s possible that there’s stuff I’ve overlooked, or just don’t yet grok how it would be used in my scenario.

What’s of potential interest or inspiration?


> 
>> The last time I banged on Bind was 4.9.3 so it’s been a while… no,
>> that’s not a typo.
> 
> Yikes! That was a _WHILE_ ago ... ;-) I _SHURE_ hope that BIND 4 is not
> what's running inside WRT ... ;-)


Nope.  9.11.2-P1.


> 
>> The work is going to be on GitHub if anyone wants to look at it and
>> offer suggestions.
> 
> I might be willing to throw a glance at it. Concact me off-line.
> 
> 				Best regards,
> 				  /Lars-Johan Liman


Thanks, will do after I post it.  Trying to clean it up enough that it’s not horrendous.

-Philip