<div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br></div></div></div></div></div></div></div><div class="gmail_quote" style=""><div dir="ltr" class="gmail_attr">On Fri, May 27, 2022 at 3:29 PM Mirsad Goran Todorovac <<a href="mailto:mirsad.todorovac@alu.unizg.hr">mirsad.todorovac@alu.unizg.hr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi Crist,</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>2. Now please take a coffee, because this became more complex
than when I started it, though it is a very simple thing.</p>
<p>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).</p>
<p>WHAT IS REQUIRED:</p>
<p><font face="monospace">server
PRIMARY:
SECONDARY:</font></p>
<p><font face="monospace">view<br>
</font></p>
<p><font face="monospace">internal
grf.hr.internal.db
grf.hr.internal.db<br>
external
grf.hr.db
grf.hr.db</font></p>
<p>I can't seem to find a way to mirror the internal copy of primary
view "internal" to the secondary server?</p>
<p>I will post an excerpt from the configuration of the questionable
zone on primary ("master"):</p>
<p><font face="monospace">include "/etc/bind/keys/grf.hr-tsig.key";
<br>
</font><br>
<font face="monospace">view "internal" { <br>
<br>
match-clients { <a href="http://161.53.83.0/24" target="_blank">161.53.83.0/24</a>; 31.147.204.47;
31.147.204.52; 31.147.204.129; 31.147.204.172; localhost; }; <br>
<br>
recursion yes; <br>
<br>
include "/etc/bind/named.conf.default-zones"; <br>
<br>
zone "<a href="http://grf.hr" target="_blank">grf.hr</a>" in { <br>
type master; <br>
file "/etc/bind/zones/grf.hr.internal"; <br>
allow-transfer { key grf.hr-tsig; }; <br>
also-notify { 161.53.83.3; }; <br>
forwarders {}; <br>
};</font></p>
<p><font face="monospace"> ...<br>
</font></p>
<p><font face="monospace">};</font></p>
<p><font face="monospace">view "universe" { <br>
<br>
match-clients { any; }; <br>
<br>
recursion no; <br>
<br>
zone "<a href="http://grf.hr" target="_blank">grf.hr</a>" in { <br>
type master; <br>
file "/etc/bind/zones/<a href="http://grf.hr" target="_blank">grf.hr</a>"; <br>
allow-transfer { 161.53.2.70; }; <br>
also-notify { 161.53.2.70; 161.53.83.3; }; <br>
forwarders {}; <br>
}; <br>
</font></p>
<p><font face="monospace"> ...<br>
<br>
};</font></p>
<p>So, the internal secondary DNS 161.53.x.3 should get the internal
copy of "<a href="http://grf.hr" target="_blank">grf.hr</a>" zone for its own, and external copy of "<a href="http://grf.hr" target="_blank">grf.hr</a>"
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 "<a href="http://grf.hr" target="_blank">grf.hr</a>"
are homonymous):</p>
<p><font face="monospace">view "internal" { <br>
<br>
match-clients { <a href="http://161.53.83.0/24" target="_blank">161.53.83.0/24</a>; <a href="http://10.0.0.0/16" target="_blank">10.0.0.0/16</a>; 31.147.204.224;
localhost; }; <br>
<br>
recursion yes; <br>
<br>
zone "<a href="http://grf.hr" target="_blank">grf.hr</a>" in { <br>
type secondary; <br>
file "/var/cache/bind/grf.hr.db"; <br>
masters { 31.147.204.224; }; <br>
allow-transfer { 31.147.204.224; }; <br>
forwarders {}; <br>
}; <br>
<br>
...</font></p>
<p><font face="monospace">};</font></p>
<p><font face="monospace">view "universe" { <br>
<br>
match-clients { any; }; <br>
<br>
recursion no; <br>
<br>
zone "<a href="http://grf.hr" target="_blank">grf.hr</a>" in { <br>
in-view "internal"; <br>
}; <br>
</font></p>
<p><font face="monospace"> ...</font></p>
<p><font face="monospace">};</font><br>
</p>
<p>There doesn't seem to be a semantic way to refer to <a href="http://grf.hr" target="_blank">grf.hr</a> from
view "internal" as opposed to <a href="http://grf.hr" target="_blank">grf.hr</a> from view "universe" from the
secondary's point of view.</p>
<p>I can't seem a way to work around this.</p>
<p>I have Googled, but the reference for view doesn't seem to cover
it:</p>
<p><a href="https://bind9.readthedocs.io/en/v9_18_2/reference.html?highlight=view#view-statement-definition-and-usage" target="_blank">https://bind9.readthedocs.io/en/v9_18_2/reference.html?highlight=view#view-statement-definition-and-usage</a></p>
<p>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.</p>
<p>I am running BIND 9.16.27 on Debian 10/11 Linux systems.<br>
</p>
<p>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.</p>
<p>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.</p>
<p>PRIMARY:</p>
<p><font face="monospace">view "internal" { <br>
<br>
match-clients { <a href="http://161.53.83.0/24" target="_blank">161.53.83.0/24</a>; 31.147.204.47;
31.147.204.52; 31.147.204.129; 31.147.204.172; localhost; }; <br>
<br>
recursion yes; <br>
<br>
include "/etc/bind/named.conf.default-zones"; <br>
<br>
zone "grf.hr.internal" in { // workaround zone to get a zone
xfer to secondary<br>
type master;<br>
file "/etc/bind/zones/grf.hr.internal"; <br>
allow-transfer { key grf.hr-tsig; }; <br>
also-notify { 161.53.83.3; }; <br>
forwarders {}; <br>
};</font></p>
<p><font face="monospace"> zone "<a href="http://grf.hr" target="_blank">grf.hr</a>" in { // real internal
zone name with the same data<br>
zone-alias-for "grf.hr.internal";<br>
}; <br>
<br>
...
</font></p>
<p><font face="monospace">};</font></p>
<p><font face="monospace">view "universe" { <br>
</font></p>
<p><font face="monospace">
<br>
match-clients { any; }; <br>
<br>
recursion no; <br>
<br>
zone "<a href="http://grf.hr" target="_blank">grf.hr</a>" in {<br>
type master; <br>
file "/etc/bind/zones/<a href="http://grf.hr" target="_blank">grf.hr</a>"; // database for the
external view<br>
allow-transfer { 161.53.2.70; }; <br>
also-notify { 161.53.2.70; 161.53.83.3; }; <br>
forwarders {}; <br>
}; <br>
</font>
</p>
<font face="monospace"> ...<br>
</font>
<p><font face="monospace">
};</font></p>
<p>SECONDARY:</p>
<p><font face="monospace">view "internal" { <br>
<br>
match-clients { <a href="http://161.53.83.0/24" target="_blank">161.53.83.0/24</a>; <a href="http://10.0.0.0/16" target="_blank">10.0.0.0/16</a>; 31.147.204.224;
localhost; }; <br>
<br>
recursion yes; <br>
<br>
zone "grf.hr.internal" in { <br>
type secondary; <br>
file "/var/cache/bind/grf.hr.internal.db"; <br>
masters { 31.147.204.224; }; <br>
allow-transfer { none; }; <br>
forwarders {}; <br>
};</font></p>
<p><font face="monospace"><font color="#ff002c"><b> zone "<a href="http://grf.hr" target="_blank">grf.hr</a>"
in {</b><b><br>
</b><b> zone-alias-for "grf.hr.internal";</b><b><br>
</b><b> };</b><b><br>
</b></font> <br>
...</font></p>
<font face="monospace">
</font>
<p><font face="monospace">};</font></p>
<font face="monospace">
</font>
<p><font face="monospace">view "universe" { <br>
<br>
match-clients { any; }; <br>
<br>
recursion no; <br>
<br>
zone "<a href="http://grf.hr" target="_blank">grf.hr</a>" in {<br>
in-view "internal"; <br>
}; <br>
</font>
</p>
<font face="monospace">
</font>
<p><font face="monospace"> ...</font></p>
<font face="monospace">
</font>
<p><font face="monospace">};<br>
</font>
</p>
<font face="monospace">
</font>
<p>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.</p>
<p>(Of course, this is not a suggestion for a change in BIND9
configuration syntax, just a semantic example of what is
semantically required.)<br>
</p>
<p>Thank you.</p>
<p>Kind regards,<br>
Mirsad<br>
</p>
<div>On 26. 05. 2022. 08:07, Crist Clark
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">As far as I know, GSS-TSIG is only used for DNS
updates, not zone transfers.
<div><br>
</div>
<div><a href="https://bind9.readthedocs.io/en/v9_16_5/advanced.html#dynamic-update" target="_blank">https://bind9.readthedocs.io/en/v9_16_5/advanced.html#dynamic-update</a><br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, May 25, 2022 at 3:38
PM Mirsad Goran Todorovac <<a href="mailto:mirsad.todorovac@alu.unizg.hr" target="_blank">mirsad.todorovac@alu.unizg.hr</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear
all,<br>
<br>
I have a zone <a href="http://local.grf.hr" rel="noreferrer" target="_blank">local.grf.hr</a>
administered by AD, DHCP and DDNS ran by <br>
Windows Server 2016<br>
(not by my architectural choice). However, since Windows
Server 2016 had <br>
round-robin<br>
strategy of inquiring the forwarders, it performed worse than
BIND9 on <br>
old Debian server.<br>
<br>
So, I had the BIND9 as the secondary server ("slave" is
somewhat <br>
politically incorrect) and I<br>
wanted to secure transactions with TSIG HMAC-SHA256 or
stronger, as <br>
between Debian<br>
BIND9 servers.<br>
<br>
I've been Googling around, and they say it cannot be done,
because <br>
Windows Server uses<br>
special proprietary GSS-TSIG. The article was for an earlier
version of WS.<br>
<br>
Has there been some improvement in the meantime?<br>
<br>
We are thinking about moving DHCP server to Linux, but it is a
huge job <br>
to convert the<br>
reservations, so it may not be done in the next couple of
months.<br>
<br>
I would like to secure DNS xfers from zone poisoning in the
meantime, <br>
considering the recent<br>
surge of cyber attacks since the recent war started, and our
country <br>
voted support for the<br>
defending party.<br>
<br>
Frankly, I am not in deep with Microsoft DNS, and I guess
there can be <br>
some tweaking with<br>
the PowerShell, and maybe even some undocumented features, but
right now <br>
I am presented<br>
with a problem I can't seem to solve because it is not an open
system.<br>
<br>
Thanks for any help.<br>
<br>
Kind regards,<br>
Mirsad Todorovac<br>
<br>
--<br>
Mirsad Goran Todorovac<br>
CARNet sistem inženjer<br>
Grafički fakultet | Akademija likovnih umjetnosti<br>
Sveučilište u Zagrebu<br>
<br>
-- <br>
CARNet system engineer<br>
Faculty of Graphic Arts | Academy of Fine Arts<br>
University of Zagreb, Republic of Croatia<br>
tel. +385 (0)1 3711 451<br>
mob. +385 91 57 88 355<br>
<br>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a>
to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support
subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a>
for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
<br>
</blockquote>
</div>
</blockquote>
<pre cols="72">--
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</pre>
</div><br></blockquote><div><br></div><div>See </div><div><a href="https://kb.isc.org/docs/aa-00851">https://kb.isc.org/docs/aa-00851</a></div><div>the standard solution is to use TSIG keys to direct the notify messages and zone transfers to the correct views.</div><div><br></div><div>-- </div><div>Bob Harold</div><div> </div></div><input name="virtru-metadata" type="hidden" value="{"email-policy":{"state":"closed","expirationUnit":"days","disableCopyPaste":false,"disablePrint":false,"disableForwarding":false,"enableNoauth":false,"persistentProtection":false,"expandedWatermarking":false,"expires":false,"isManaged":false},"attachments":{},"compose-id":"5","compose-window":{"secure":false}}"></div>