On Fri, May 27, 2022 at 3:29 PM Mirsad Goran Todorovac <
mirsad.todoro...@alu.unizg.hr> wrote:
> 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 <http://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 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
>
>
>
See
https://kb.isc.org/docs/aa-00851
the standard solution is to use TSIG keys to direct the notify messages and
zone transfers to the correct views.
--
Bob Harold
--
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
