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

[Bjørn Mork]

Philip Prindeville <philipp_subx at redfish-solutions.com> writes:
>> 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?

It breaks the basic DNS premise: There is one distributed database.

The fallout is broken DNSSEC, lame delegations, failing services, broken
caches etc.  Most of these are results of the added operational
complexity.  Feeble attempts to simplify split DNS also often involve
breaking best practices, like having authoritative servers in more than
one AS.

All this might have been acceptable if it solved a real problem.  It
doesn't.

> I don’t see why the converse would be any better, i.e. publishing
> RFC-1918 addresses of NATted hosts behind a firewall,

This is not a problem.  There is nothing special about RFC 1918, or any
other, addresses in DNS. DNS replies comes without any guarantee about
firewalls, routing or provided public services. Software which assumes
otherwise is buggy, with very few exceptions.

The classic example of such bugs is the claimed "rebind protection" in
dnsmasq.  Which
 a) breaks valid configurations
 b) doesn't do rebind protection

> and disclosing more information than is necessary anyway…

I realize this is important to some.  But split DNS will not protect
this information.  You should not put anything you don't want to
disclose in DNS.

> See here:
>
> https://github.com/openwrt/packages/pull/14233

Huh? Can't find anything related to dynamic DNS in either BIND or ISC
dhcp there?

> 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.

My manual says

            ddns-update-style style;

            The style parameter must be one of standard, 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.




The "standard" style was introduced in commit d7d9c0c7c36d ("-n [master]
Add code to support the standards version of DDNS") in 2013. It was
released with version 4.3 in 2014.



Bjørn