Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
Heads up that there’s a major change to the PR: https://github.com/openwrt/packages/pull/14240 It adds support for “cname”, “domain”, “mxhost”, and “srvhost” config sections. Thanks to Bjorn for pointing me at how to use nsupdate to do this. Calling out run-time requirements on “named” and “nsupdate” in the dependencies. Still trying to work through a start/boot problem where Bind doesn’t seem to listen on all interfaces (what’s surprising is that these aren’t even DHCP’d interfaces… even “wan” has a static address assigned). If anyone has any suggestions on how to troubleshoot this, please speak up. Looking at lib/ns/interfacemgr.c, it seems that Bind detects RTM_NEWADDR and RTM_DELADDR messages from Netlink so no external prodding should be required to handle interface changes. (Though I don’t see RTM_NEWLINK in the source code… but maybe just catching addresses is enough; I’ve not dug very deep there.) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
Responses… > On Dec 17, 2020, at 1:56 AM, Bjørn Mork wrote: > > Philip Prindeville 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 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
Philip Prindeville 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. 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. Alternatively, you might want to consider "update-policy local" since BIND and the DHCP server runs on the same host. 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. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
> On Dec 16, 2020, at 12:59 AM, Bjørn Mork wrote:
>
> Philip Prindeville writes:
>>> On Dec 15, 2020, at 1:22 AM, Bjørn Mork wrote:
>>>
>>> Philip Prindeville 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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
Philip Prindeville writes:
>> On Dec 15, 2020, at 1:22 AM, Bjørn Mork wrote:
>>
>> Philip Prindeville 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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
> On Dec 15, 2020, at 1:22 AM, Bjørn Mork wrote: > > Philip Prindeville 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@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 2020122805 > 2020121504 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 2020122805 > 2020121504 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
Re: Bind + ISC dhcpd integration (for intranet split-horizon, etc)
Philip Prindeville 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. > 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. 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@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 2020122805 2020121504 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 2020122805 2020121504 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):
