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.todoro...@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@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
--
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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
