BIND9 TSIG from Windows Server 2016 DNS Server Zone
Mirsad Goran Todorovac
mirsad.todorovac at alu.unizg.hr
Fri May 27 19:28:58 UTC 2022
Hi Crist,
1. Actually, I am running dynamic updates with BIND9 and ISC DHCP server
for about a half a year and I am frankly very happy with the way it
works. This is at the Academy. So, I am familiar with the dynamic (DDNS)
updates. Though there had been some tricky stuff with sub-/24 reverse
PTR zone, the thing went rather smooth and it is working well.
At the Faculty, former administrator chose Windows Server 2016 for AD,
DHCP and DNS for the organisation. Sad to hear that there doesn't seem a
way for TSIG zone xfer on AD-managed DDNS - BIND9 secondary combination.
2. Now please take a coffee, because this became more complex than when
I started it, though it is a very simple thing.
I have recently tried views. What would be useful was a way to transfer
internal zone to the secondary (or politically incorrect speaking,
"slave" server).
WHAT IS REQUIRED:
server PRIMARY: SECONDARY:
view
internal grf.hr.internal.db grf.hr.internal.db
external grf.hr.db grf.hr.db
I can't seem to find a way to mirror the internal copy of primary view
"internal" to the secondary server?
I will post an excerpt from the configuration of the questionable zone
on primary ("master"):
include "/etc/bind/keys/grf.hr-tsig.key";
view "internal" {
match-clients { 161.53.83.0/24; 31.147.204.47; 31.147.204.52;
31.147.204.129; 31.147.204.172; localhost; };
recursion yes;
include "/etc/bind/named.conf.default-zones";
zone "grf.hr" in {
type master;
file "/etc/bind/zones/grf.hr.internal";
allow-transfer { key grf.hr-tsig; };
also-notify { 161.53.83.3; };
forwarders {};
};
...
};
view "universe" {
match-clients { any; };
recursion no;
zone "grf.hr" in {
type master;
file "/etc/bind/zones/grf.hr";
allow-transfer { 161.53.2.70; };
also-notify { 161.53.2.70; 161.53.83.3; };
forwarders {};
};
...
};
So, the internal secondary DNS 161.53.x.3 should get the internal copy
of "grf.hr" zone for its own, and external copy of "grf.hr" zone for the
view "universe". This is the current configuration, and the secondary
server gets the external view, because it is the only copy with that
zone name (the external and internal "grf.hr" are homonymous):
view "internal" {
match-clients { 161.53.83.0/24; 10.0.0.0/16; 31.147.204.224;
localhost; };
recursion yes;
zone "grf.hr" in {
type secondary;
file "/var/cache/bind/grf.hr.db";
masters { 31.147.204.224; };
allow-transfer { 31.147.204.224; };
forwarders {};
};
...
};
view "universe" {
match-clients { any; };
recursion no;
zone "grf.hr" in {
in-view "internal";
};
...
};
There doesn't seem to be a semantic way to refer to grf.hr from view
"internal" as opposed to grf.hr from view "universe" from the
secondary's point of view.
I can't seem a way to work around this.
I have Googled, but the reference for view doesn't seem to cover it:
https://bind9.readthedocs.io/en/v9_18_2/reference.html?highlight=view#view-statement-definition-and-usage
There didn't seem to be a way to mirror the configuration with internal
and external view to the secondary server. Or I did not see it.
I am running BIND 9.16.27 on Debian 10/11 Linux systems.
I would be grateful for any pointer or idea. I know there must be a
catch, for it seems so simple. There must be something I can't see. But
probably I need to make some distance from the problem ... and wait to
sleep over it.
Also, it would be useful if there is way to refer to a zone by alias.
So, I could then have zone "grf.hr.internal" on primary, transfer that,
and have an alias zone i.e.
PRIMARY:
view "internal" {
match-clients { 161.53.83.0/24; 31.147.204.47; 31.147.204.52;
31.147.204.129; 31.147.204.172; localhost; };
recursion yes;
include "/etc/bind/named.conf.default-zones";
zone "grf.hr.internal" in { // workaround zone to get a zone xfer
to secondary
type master;
file "/etc/bind/zones/grf.hr.internal";
allow-transfer { key grf.hr-tsig; };
also-notify { 161.53.83.3; };
forwarders {};
};
zone "grf.hr" in { // real internal zone name with the same data
zone-alias-for "grf.hr.internal";
};
...
};
view "universe" {
match-clients { any; };
recursion no;
zone "grf.hr" in {
type master;
file "/etc/bind/zones/grf.hr"; // database for the external view
allow-transfer { 161.53.2.70; };
also-notify { 161.53.2.70; 161.53.83.3; };
forwarders {};
};
...
};
SECONDARY:
view "internal" {
match-clients { 161.53.83.0/24; 10.0.0.0/16; 31.147.204.224;
localhost; };
recursion yes;
zone "grf.hr.internal" in {
type secondary;
file "/var/cache/bind/grf.hr.internal.db";
masters { 31.147.204.224; };
allow-transfer { none; };
forwarders {};
};
* zone "grf.hr" in {**
** zone-alias-for "grf.hr.internal";**
** };**
*
...
};
view "universe" {
match-clients { any; };
recursion no;
zone "grf.hr" in {
in-view "internal";
};
...
};
Because that's what I really need, for the same zone to have internal
and external variant of data, equal on both primary and secondary server.
(Of course, this is not a suggestion for a change in BIND9 configuration
syntax, just a semantic example of what is semantically required.)
Thank you.
Kind regards,
Mirsad
On 26. 05. 2022. 08:07, Crist Clark wrote:
> As far as I know, GSS-TSIG is only used for DNS updates, not zone
> transfers.
>
> https://bind9.readthedocs.io/en/v9_16_5/advanced.html#dynamic-update
>
> Sorry, don't know what capabilities AD has for securing zone transfers
> beyond IP ACLs, which of course is not much security at all. I've
> never had luck getting AD admins to offer anything better. I'm
> definitely no AD expert myself.
>
> One possibility of course is to secure at the IP layer, a.k.a. IPsec.
> You could secure all traffic between the servers with transport mode
> AH. That would probably blow some minds in your organization. There
> are many who only know IPsec as encrypted tunnels, i.e. VPNs.
>
> On Wed, May 25, 2022 at 3:38 PM Mirsad Goran Todorovac
> <mirsad.todorovac at alu.unizg.hr> wrote:
>
> Dear all,
>
> I have a zone local.grf.hr <http://local.grf.hr> administered by
> AD, DHCP and DDNS ran by
> Windows Server 2016
> (not by my architectural choice). However, since Windows Server
> 2016 had
> round-robin
> strategy of inquiring the forwarders, it performed worse than
> BIND9 on
> old Debian server.
>
> So, I had the BIND9 as the secondary server ("slave" is somewhat
> politically incorrect) and I
> wanted to secure transactions with TSIG HMAC-SHA256 or stronger, as
> between Debian
> BIND9 servers.
>
> I've been Googling around, and they say it cannot be done, because
> Windows Server uses
> special proprietary GSS-TSIG. The article was for an earlier
> version of WS.
>
> Has there been some improvement in the meantime?
>
> We are thinking about moving DHCP server to Linux, but it is a
> huge job
> to convert the
> reservations, so it may not be done in the next couple of months.
>
> I would like to secure DNS xfers from zone poisoning in the meantime,
> considering the recent
> surge of cyber attacks since the recent war started, and our country
> voted support for the
> defending party.
>
> Frankly, I am not in deep with Microsoft DNS, and I guess there
> can be
> some tweaking with
> the PowerShell, and maybe even some undocumented features, but
> right now
> I am presented
> with a problem I can't seem to solve because it is not an open system.
>
> Thanks for any help.
>
> Kind regards,
> Mirsad Todorovac
>
> --
> Mirsad Goran Todorovac
> CARNet sistem inženjer
> Grafički fakultet | Akademija likovnih umjetnosti
> Sveučilište u Zagrebu
>
> --
> CARNet system engineer
> Faculty of Graphic Arts | Academy of Fine Arts
> University of Zagreb, Republic of Croatia
> tel. +385 (0)1 3711 451
> mob. +385 91 57 88 355
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Mirsad Goran Todorovac
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
--
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
tel. +385 (0)1 3711 451
mob. +385 91 57 88 355
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220527/c408d390/attachment-0001.htm>
More information about the bind-users
mailing list