Re: BIND9 TSIG from Windows Server 2016 DNS Server Zone

2022-05-27 Thread Bob Harold 
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 {

Re: BIND9 TSIG from Windows Server 2016 DNS Server Zone

2022-05-27 Thread Mirsad Goran Todorovac 

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; };
   

Re: Primary zone not fully maintained by BIND

2022-05-27 Thread Matthijs Mekking 

Nick,

On 27-05-2022 10:27, Nick Tait via bind-users wrote:

On 26/05/22 20:34, Matthijs Mekking wrote:
What version are you using? We had a bug with dnssec-policy and views 
(#2463), but that has been fixed.


Since 9.16.18 you should not be able to set the same key-directory for 
the same zone in different views. 


Hi Matthijs.

You got me worried just then because for several years I have been using 
a split DNS set-up, with the same zone defined in two different views 
which share a common keys directory. And then about a month ago I 
upgraded from 9.16.something to 9.18.1.


But I've managed to find the release note that I think you're referring 
to. From 
https://downloads.isc.org/isc/bind9/9.16.29/doc/arm/html/notes.html#id24 :


Zones which are configured in multiple views, with different values
set for |dnssec-policy| and with identical values set for
|key-directory|, are now detected and treated as a configuration
error. *[GL #2463]*


So based on this it would seem that it is OK for two views to define the 
same DNSSEC zone and share the same keys directory, *as long as they are 
using the same dnssec-policy*?


That is correct. Since key files don't have views in their name, each 
key in the key-directory corresponds to all zones with the same name, 
regardless the view. Having a *different* policy causes continuously 
mismatches between what keys are in use for a certain zone and what is 
expected according to its policy.


Having the same policy for each zone per view should work fine*.

Best regards,
  Matthijs


*With Sandro's case being investigated at the moment.




Please advise if I've got that wrong?

Thanks,

Nick.



--
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

Re: Primary zone not fully maintained by BIND

2022-05-27 Thread Matthijs Mekking 

Hi,

Sorry for not replying earlier (traveling).

Yes, I would recommend key separation (that is use a different 
key-directory per view).


I am going to investigate your configuration more next week, to see if 
there is a hidden bug.


Best regards,

Matthijs


On 26-05-2022 14:33, Sandro wrote:

On 26-05-2022 12:00, Sandro wrote:

Thank you, Matthijs, for pointing out the bug. Do you have any 
suggestion for what to try first, key separation or policy separation?


Well, I went for key separation. Let's see if it sticks. Last time I 
restarted BIND everything seemed fine in the beginning as well.


Of course, the question remains if there's still a bug hiding here 
somewhere. I'd be happy providing more information and performing tests 
to gather information.


What's been throwing me of balance over and over is the fact the zone 
file on disk can be outdated for quite some time, while the answers 
provided querying BIND with dig are already updated. But that's probably 
me getting acquainted with BIND being in charge of the zone.


-- Sandro

--
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

Re: Primary zone not fully maintained by BIND

2022-05-27 Thread Nick Tait via bind-users 

On 26/05/22 20:34, Matthijs Mekking wrote:
What version are you using? We had a bug with dnssec-policy and views 
(#2463), but that has been fixed.


Since 9.16.18 you should not be able to set the same key-directory for 
the same zone in different views. 


Hi Matthijs.

You got me worried just then because for several years I have been using 
a split DNS set-up, with the same zone defined in two different views 
which share a common keys directory. And then about a month ago I 
upgraded from 9.16.something to 9.18.1.


But I've managed to find the release note that I think you're referring 
to. From 
https://downloads.isc.org/isc/bind9/9.16.29/doc/arm/html/notes.html#id24 :


   Zones which are configured in multiple views, with different values
   set for |dnssec-policy| and with identical values set for
   |key-directory|, are now detected and treated as a configuration
   error. *[GL #2463]*
   

So based on this it would seem that it is OK for two views to define the 
same DNSSEC zone and share the same keys directory, *as long as they are 
using the same dnssec-policy*?


Please advise if I've got that wrong?

Thanks,

Nick.
-- 
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

Possible bug. Bind 9.18 blocking on dnstap

2022-05-27 Thread Borja Marcos 
Hi,

I just stumbled upon a problem. It happened on FreeBSD 13.1-RC (going to update 
to 13.1 today).

I am running bind 9.18.3 with dnstap using a Unix socket. 

Once the socket has been opened by bind, if the process serving the Unix socket 
blocks and you try to 
kill named, it fails to stop, stays blocked on the dnstap socket until it is 
closed.


How to reproduce:

- I started bind 9.18.3

- Started dnstap, the Go program from https://github.com/dnstap/golang-dnstap. 
(dnstap -u /var/tmp…)

- I suspended the dnstap program (kill -STOP)

- Sent some queries to bind

- Tried to stop bind (either rndc stop or kill -TERM)

It won’t really exit unless I resume the dnstop process or I kill it.

Is it expected behavior? I am not sure there should be such a strong contract 
to deliver dnstap
messages to a blocked process. At least there should be a reasonable timeout 
maybe?

I haven’t opened a ticket because I am not sure it is considered a bug.


Cheers,






Borja.




-- 
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