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

[Philip Prindeville]

> On Dec 16, 2020, at 12:59 AM, Bjørn Mork <bjorn at mork.no> wrote:
> 
> 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.


I don’t know how concrete that premise is: why would Bind have ‘views’ if there was a single, global version of the 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.


This is for the SoHo scenario where the firewall provides both DNS, DNS forwarding, DHCP, and connectivity.  If that device fails, everything does anyway.


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


That’s not my concern.  I don’t want to admit the existence of devices which aren’t reachable to begin with, if (a) they have unroutable addresses and (b) there is no port-forwarding to reach them.

Disclosing information about internal resources… possibly critical or sensitive resources… without any need to do so is a mistake.  Why give potential attackers additional information with which to prepare an attack?


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


Sure it protects it.  The name server that contains this information about my hosts also serves that information to the only hosts that need it.  It’s configured as:

options {
...
	allow-query {
		localhost;
		192.168.1.0/24;
		192.168.2.0/24;
		192.168.3.0/24;
	};
...
};


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


Doh.  Wrong PR:

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

The previous one is a precursor for getting Bind to start before DHCPD.


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


Serves me right for looking at the Ubuntu 18.04 LTS man page…

Okay, fixed to use “standard”.

Thanks for that.

-Philip


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