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

Philip Prindeville philipp_subx at redfish-solutions.com
Tue Dec 15 17:32:23 EST 2020



> On Dec 15, 2020, at 1:22 AM, Bjørn Mork <bjorn at mork.no> wrote:
> 
> Philip Prindeville <philipp_subx at redfish-solutions.com> writes:
> 
>> I’m trying to do the integration “glue” to allow one to operate a DNS
>> private zone inside your intranet (aka “split horizon”) and prime it
>> with both static data as well as DHCP lease information.
> 
> “split horizon” is a very bad idea, and should not be encouraged.


Can you say more about that?

I don’t see why the converse would be any better, i.e. publishing RFC-1918 addresses of NATted hosts behind a firewall, and disclosing more information than is necessary anyway…


> 
>> Ideally this could be done with a minimum of UCI configuration and canned configurations.
>> 
>> I tried to follow a couple of examples of this online:
>> 
>> https://www.talk-about-it.ca/setup-bind9-with-isc-dhcp-server-dynamic-host-registration/
>> 
>> https://docs.oracle.com/cd/E19469-01/820-6410-12/app_example_dns.html
>> 
>> But couldn’t get either to work demonstrably.  Has anyone else managed
>> to get this working, and if so, would they share the details of how
>> they did it?
>> 
>> I’ve followed the steps and I’m not seeing any errors, but I’m not
>> able to resolve the dynamic host names, either.  Some of the details
>> of what I’ve tried are here:
>> 
>> https://lists.isc.org/pipermail/bind-workers/2020-December/003530.html
>> 
>> It’s probably something trivial but I can’t put my finger on it.
> 
> You need to post your configs.


See here:

https://github.com/openwrt/packages/pull/14233

Looking for testers, if anyone is interested.

I don’t have an easy way to do 172.16.0.0/12 or 10.0.0.0/8 testing… but I might add support for those if someone can test it.

I think the problem was that neither example that I was going by included "ddns-updates on;” which obvious was the “secret sauce” missing.  Seems kind of obvious in retrospect.


> 
> Missing those, I tried to look at the examples you point to.   The first
> one doesn't resolve due to serious errors in the DNS configuration, so I
> will assume that ANY advice you found there is plain wrong (I guess
> someone here is unable to spell DNS):
> 
> 
> bjorn at miraculix:~$ dig www.talk-about-it.ca +trace
> 
> ; <<>> DiG 9.16.8-Debian <<>> www.talk-about-it.ca +trace
> ;; global options: +cmd
> .                       516931  IN      NS      f.root-servers.net.
> .                       516931  IN      NS      g.root-servers.net.
> .                       516931  IN      NS      h.root-servers.net.
> .                       516931  IN      NS      i.root-servers.net.
> .                       516931  IN      NS      j.root-servers.net.
> .                       516931  IN      NS      k.root-servers.net.
> .                       516931  IN      NS      l.root-servers.net.
> .                       516931  IN      NS      m.root-servers.net.
> .                       516931  IN      NS      a.root-servers.net.
> .                       516931  IN      NS      b.root-servers.net.
> .                       516931  IN      NS      c.root-servers.net.
> .                       516931  IN      NS      d.root-servers.net.
> .                       516931  IN      NS      e.root-servers.net.
> .                       516931  IN      RRSIG   NS 8 0 518400 20201228050000 20201215040000 26116 . FhG5WBLPhzoCY01sZlB76cBR5OyhyjACLV1V3QrwUISVBRhucfjtm+0K rfw857zJ39mEX/oV7uTat3WjavPIjDqL+6YIRq18FqE9BX+vaYzUUDgU fZgLF/4MM9kQjsYIIiX+HUZGxT2IdYfP8YLO5q+2I5B53PS4iw9lK1aT 66FIx+OEKGVdEwVAFTOgH3GQB2R0A52VByfbMYotj0YxbdnQ6g+OVfwD Xzud5Cf3imyqb4PY7P4mBvgZszLET/uUbfHje4eyesjK0cFwoW8txAEA 7Pu/Bs13/s79r76pk5jFtbKwDgXAWPj+60jdk7bZPEoxU9x+6P+jtfAq BK4ZQQ==
> ;; Received 1125 bytes from 148.122.16.253#53(148.122.16.253) in 248 ms
> 
> ca.                     172800  IN      NS      c.ca-servers.ca.
> ca.                     172800  IN      NS      j.ca-servers.ca.
> ca.                     172800  IN      NS      x.ca-servers.ca.
> ca.                     172800  IN      NS      any.ca-servers.ca.
> ca.                     86400   IN      DS      2134 8 2 4B8475C0C0FE2AFDFEE1A71A237C91059098D12FC18265B290EDB238 A5F63582
> ca.                     86400   IN      RRSIG   DS 8 1 86400 20201228050000 20201215040000 26116 . bNnIysh6MYhpbK6KBAuQt24vxB+wU838f07IxOCAjbnru4IHyLrcjCF+ 3zz2ctSrUJ/5EQOHdi+rbDdOiCsQg3eOhLO/xqFDjy8M+yapBZxolhNJ pvcIKcfOVfuIgPTq8ZcvxYV+/M7i5dD89yDaJ2X7DcHauMryaNjO+xb5 +LchwPmUsGtWKH/gABBSPy7U+W3OM5fgDEVVTh1SjHqU5CH1+Mpf6W0Y y6JIsXQheb1feNdPZT1H+LkJEyeXsuKe9eUFFqHwlSGezlPQkkbHCObT k+S+RoN6XrH8qn9ysU3FDCdSPiVPhC6WOM2fFNJTT6nZLmtZf/KYujRb H8sxQw==
> ;; Received 637 bytes from 2001:503:ba3e::2:30#53(a.root-servers.net) in 80 ms
> 
> talk-about-it.ca.       86400   IN      NS      dn1.p01.nsone.net.
> talk-about-it.ca.       86400   IN      NS      dn2.p01.nsone.net.
> talk-about-it.ca.       86400   IN      NS      dn3.p01.nsone.net.
> talk-about-it.ca.       86400   IN      NS      dn4.p01.nsone.net.
> talk-about-it.ca.       86400   IN      DS      2371 13 2 253C2AD76C9E6D92292A83811BA64FEB4EC70C1ED30115B4E897A885 6E92E167
> talk-about-it.ca.       86400   IN      RRSIG   DS 8 2 86400 20201220003013 20201212163855 43854 ca. pG4pnP1GYocjqaTXiR6b/BHFZDHmiCDkPxrSi/R7oCyTXI+2l2Ka+8Gb oM4wkvYF6EIOldwWn/MJLfP3CDgYzF3WPe6OWbdvwAyUZn87GDQWCUj6 DcGybJHeLFKbZye01tMz+l0CnLCTwL9abXysYTM9FRBZa349eUxlqz8E GFU=
> couldn't get address for 'dn1.p01.nsone.net': not found
> couldn't get address for 'dn2.p01.nsone.net': not found
> couldn't get address for 'dn3.p01.nsone.net': not found
> couldn't get address for 'dn4.p01.nsone.net': not found
> dig: couldn't get address for 'dn1.p01.nsone.net': no more
> 
> 
> 
> The other example is from Oracle, which I personally trust about as far
> as I can throw them. And it doesn't. It's not difficult to find problems
> with it.  Quotiong from dhcpd.conf(5):
> 
> 
>  New installations should use the standard option. Older installations
>  may want to continue using the interim option for backwards
>  compatibility with the DNS database until the database can be updated.
> 
> 
> Use the man pages, not random google searches. I am pretty sure that
> most of the advice you can find on this subject is from someone who did
> not read the docs.


Well, doing an RTFM I see:

  The ddns-update-style parameter

  ddns-update-style style;

    The style parameter must be one of ad-hoc, interim or none. The ddns-update-style statement is only meaningful in the outer scope - it is evaluated once after reading the dhcpd.conf file, rather than each time a client is assigned an IP address, so there is no way to use different DNS update styles for different clients. The default is none.

And have to admit that’s not very insightful.  We’re told here that ad-hoc doesn’t work:

https://kb.isc.org/docs/isc-dhcp-41-manual-pages-dhcpdconf#THE%20AD-HOC%20DNS%20UPDATE%20SCHEME

And “none” seems to suggest no updates at all, and indeed that’s the behavior I observed when this line was omitted.

So what are you suggesting should be used?


> 
> The ddns stuff is pretty well documented in dhcpd.conf(5).  The BIND
> side of things is like any dynamic zone in BIND. You can validate that
> it works with nsupdate on the command line.


I think “well documented” is a relative term.  "One man’s treasure” and all that.  ;-)


> 
> But tell us what you are doing, and you might get some answers...


Feel free to review the PR above.

Thanks!

-Philip


> 
> 
> Bjørn




More information about the openwrt-devel mailing list