date:20220601

Re: DNSSEC transition from manually signed zone to dnssec-policy "standard" failed

2022-06-01 Thread Matthijs Mekking


Hello Mirsad,

You changed to dnssec-policy with different key algorithms than you used 
for manual signing:


Jun  1 21:46:06 domac named[46537]: keymgr: retire DNSKEY 
alu.hr/RSASHA256/46119 (ZSK)
Jun  1 21:46:06 domac named[46537]: keymgr: retire DNSKEY 
alu.hr/RSASHA256/34042 (KSK)
Jun  1 21:46:06 domac named[46537]: keymgr: DNSKEY 
alu.hr/ECDSAP256SHA256/43987 (KSK) created for policy standard
Jun  1 21:46:06 domac named[46537]: keymgr: DNSKEY 
alu.hr/ECDSAP256SHA256/3502 (ZSK) created for policy standard


You had RSHSHA256 DNSSEC keys, but you started using a DNSSEC policy 
with ECDSAP256SHA256 keys.


Since the existing keys do not match the policy, BIND started a key 
rollover.


See https://kb.isc.org/docs/dnssec-key-and-signing-policy for more 
information about migration to dnssec-policy.


Also changing from directory and file "/etc/bind/zones/alu.hr.db.signed" 
to file "/var/cache/bind/alu.hr.db" may be causing some problems.


There also seems to be a permission problem:

Jun  1 22:03:38 domac named[46537]: dns_dnssec_keylistfromrdataset: 
error reading /var/cache/bind/keys/Kalu.hr.+013+03502.private: file not 
found
Jun  1 22:03:38 domac named[46537]: dns_dnssec_keylistfromrdataset: 
error reading /var/cache/bind/keys/Kalu.hr.+013+43987.private: file not 
found


Hope these pointers help.

- Matthijs



On 01-06-2022 23:14, Mirsad Goran Todorovac wrote:

Dear All,

I have tried to switch from manually signed DNSSEC zone to dnssec-policy 
"standard", and BIND9 server started

behaving odd. Here is the manual signing conf:

include "/etc/bind/keys/domac.alu.hr-tsig.key";

zone "alu.hr" in {
     type master;
     file "/etc/bind/zones/alu.hr.db.signed";
     allow-transfer { key domac.alu.hr-key; 161.53.2.70; };
     also-notify { 31.147.205.54; 161.53.2.70; };
     forwarders {};
};

... and the automatic signing conf:

zone "alu.hr" in {
     type master;
     file "/var/cache/bind/alu.hr.db";
     allow-transfer { key domac.alu.hr-key; 161.53.2.70; };
     also-notify { 31.147.205.54; 161.53.2.70; };
     dnssec-policy "standard";
     forwarders {};
};

There was a symbolic link /var/cache/bind/alu.hr.db -> 
/etc/bind/zones/alu.hr.db .


The logfile is too long to post, so I will add link: 
https://domac.alu.hr/~mtodorov/tmp/named-20220601.log


NOTE: Fun starts when I tried to automatically sing zone in zonefile 
/etc/bind/zones/alu.hr.db, and APPARMOR denied opening file to BIND. 
Maybe that confused the good old BIND9 server?


Then I added link in /var/cache/bind, as for DDNS zones.

The the zone appeared signed, but with only NSEC records, no RRSIGs, 
with this in log:


Jun  1 21:52:42 domac named[46537]: scheduled loading new zones
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (unsigned): loaded 
serial 2022060101
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): loaded 
serial 2022060101
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): 
receive_secure_serial: unchanged
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): sending 
notifies (serial 2022060101)
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): 
reconfiguring zone keys
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): 
zone_rekey:dns_zone_getdnsseckeys failed: not found
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: keymgr: retire DNSKEY 
alu.hr/RSASHA256/46119 (ZSK)
Jun  1 21:52:42 domac named[46537]: keymgr: retire DNSKEY 
alu.hr/RSASHA256/34042 (KSK)
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: Fetching alu.hr/ECDSAP256SHA256/3502 
(ZSK) from key repository.
Jun  1 21:52:42 domac named[46537]: DNSKEY alu.hr/ECDSAP256SHA256/3502 
(ZSK) is now published
Jun  1 21:52:42 domac named[46537]: DNSKEY alu.hr/ECDSAP256SHA256/3502 
(ZSK) is now active
Jun  1 21:52:42 domac named[46537]: Fetching 
alu.hr/ECDSAP256SHA256/43987 (KSK) from key repository.
Jun  1 21:52:42 domac named[46537]: DNSKEY alu.hr/ECDSAP256SHA256/43987 
(KSK) is now published
Jun  1 21:52:42 domac named[46537]: DNSKEY alu.hr/ECDSAP256SHA256/43987 
(KSK) is now active
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attemp

Re: Bugfix: missing line in message.c

2022-06-01 Thread Mark Andrews

Thanks.

INDENT is being addressed.

Can you add an issue on https://gitlab.isc.org/ for the view name in dnstap?

Mark

> On 2 Jun 2022, at 07:26, Peter  wrote:
> 
> Hi,
> 
>  this is broken in 916 (and apparently 918 also).
> Consequentially, output from dnstap gets unreadable (invalid YAML)
> when using dynamic zone updates. 
> 
>  PATCH 
> --- lib/dns/message.c.orig  2022-05-10 11:02:21.0 +0200
> +++ lib/dns/message.c   2022-05-30 04:02:40.568222000 +0200
> @@ -4296,6 +4296,7 @@
>INDENT(style);
>ADD_STRING(target, "QUESTION: ");
>} else {
> +   INDENT(style);
>ADD_STRING(target, "ZONE: ");
>}
>snprintf(buf, sizeof(buf), "%1u",
>  PATCH 
> 
> And when You'ra at it:
> I would very much appreciate when we could get the *view name* into the
> dnstap output.
> 
> I am running my nameservers as
> * authoritative to the public,
> * authoritative for the LAN,
> * recursing for the LAN (for DNSSEC to work some useful DANE things),
> * authoritative as root slave,
> * recursing as root slave (for DNSSEC to get 'AD' instead of 'AA'),
> * plus a couple of in-between cases,
> all in a single process. :)
> 
> Obviousely that needs lots of views. I found dnstap to be the perfect
> and long desired solution for debugging and understanding what
> actually happens, to become even able to create more fancy setups.
> 
> But then the view name is needed in the messages. There is an option 
> 'dnstap-identity (  | none | hostname );'
> and putting that into the views would be the natural solution - but
> that doesn't work, it gets rejected as a syntax error (for no reason
> obvious to me). I tried 918, it gets rejected there also.
> 
> So for now I hacked it with a simple approach (because I know my
> version anyway, I need only the identity of an instance and the view)
> and that works for now:
> -   dm->d.version.data = env->version.base;
> -   dm->d.version.len = env->version.length;
> +   dm->d.version.data = (uint8_t *)(view->name);
> +   dm->d.version.len = strlen(view->name);
> 
> But this is ugly as it computes strlen() on every call. I could do it
> nicer, but then I think the beforementioned option should be made
> working instead.
> 
> 
> -- PMc
> -- 
> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Bugfix: missing line in message.c

2022-06-01 Thread Peter

Hi,

  this is broken in 916 (and apparently 918 also).
Consequentially, output from dnstap gets unreadable (invalid YAML)
when using dynamic zone updates. 

 PATCH 
--- lib/dns/message.c.orig  2022-05-10 11:02:21.0 +0200
+++ lib/dns/message.c   2022-05-30 04:02:40.568222000 +0200
@@ -4296,6 +4296,7 @@
INDENT(style);
ADD_STRING(target, "QUESTION: ");
} else {
+   INDENT(style);
ADD_STRING(target, "ZONE: ");
}
snprintf(buf, sizeof(buf), "%1u",
 PATCH 

And when You'ra at it:
I would very much appreciate when we could get the *view name* into the
dnstap output.

I am running my nameservers as
 * authoritative to the public,
 * authoritative for the LAN,
 * recursing for the LAN (for DNSSEC to work some useful DANE things),
 * authoritative as root slave,
 * recursing as root slave (for DNSSEC to get 'AD' instead of 'AA'),
 * plus a couple of in-between cases,
all in a single process. :)

Obviousely that needs lots of views. I found dnstap to be the perfect
and long desired solution for debugging and understanding what
actually happens, to become even able to create more fancy setups.

But then the view name is needed in the messages. There is an option 
'dnstap-identity (  | none | hostname );'
and putting that into the views would be the natural solution - but
that doesn't work, it gets rejected as a syntax error (for no reason
obvious to me). I tried 918, it gets rejected there also.

So for now I hacked it with a simple approach (because I know my
version anyway, I need only the identity of an instance and the view)
and that works for now:
-   dm->d.version.data = env->version.base;
-   dm->d.version.len = env->version.length;
+   dm->d.version.data = (uint8_t *)(view->name);
+   dm->d.version.len = strlen(view->name);

But this is ugly as it computes strlen() on every call. I could do it
nicer, but then I think the beforementioned option should be made
working instead.


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

DNSSEC transition from manually signed zone to dnssec-policy "standard" failed

2022-06-01 Thread Mirsad Goran Todorovac


Dear All,

I have tried to switch from manually signed DNSSEC zone to dnssec-policy 
"standard", and BIND9 server started

behaving odd. Here is the manual signing conf:

include "/etc/bind/keys/domac.alu.hr-tsig.key";

zone "alu.hr" in {
    type master;
    file "/etc/bind/zones/alu.hr.db.signed";
    allow-transfer { key domac.alu.hr-key; 161.53.2.70; };
    also-notify { 31.147.205.54; 161.53.2.70; };
    forwarders {};
};

... and the automatic signing conf:

zone "alu.hr" in {
    type master;
    file "/var/cache/bind/alu.hr.db";
    allow-transfer { key domac.alu.hr-key; 161.53.2.70; };
    also-notify { 31.147.205.54; 161.53.2.70; };
    dnssec-policy "standard";
    forwarders {};
};

There was a symbolic link /var/cache/bind/alu.hr.db -> 
/etc/bind/zones/alu.hr.db .


The logfile is too long to post, so I will add link: 
https://domac.alu.hr/~mtodorov/tmp/named-20220601.log


NOTE: Fun starts when I tried to automatically sing zone in zonefile 
/etc/bind/zones/alu.hr.db, and APPARMOR denied opening file to BIND. 
Maybe that confused the good old BIND9 server?


Then I added link in /var/cache/bind, as for DDNS zones.

The the zone appeared signed, but with only NSEC records, no RRSIGs, 
with this in log:


Jun  1 21:52:42 domac named[46537]: scheduled loading new zones
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (unsigned): loaded 
serial 2022060101
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): loaded 
serial 2022060101
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): 
receive_secure_serial: unchanged
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): sending 
notifies (serial 2022060101)
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): 
reconfiguring zone keys
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): 
zone_rekey:dns_zone_getdnsseckeys failed: not found
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: keymgr: retire DNSKEY 
alu.hr/RSASHA256/46119 (ZSK)
Jun  1 21:52:42 domac named[46537]: keymgr: retire DNSKEY 
alu.hr/RSASHA256/34042 (KSK)
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: Fetching alu.hr/ECDSAP256SHA256/3502 
(ZSK) from key repository.
Jun  1 21:52:42 domac named[46537]: DNSKEY alu.hr/ECDSAP256SHA256/3502 
(ZSK) is now published
Jun  1 21:52:42 domac named[46537]: DNSKEY alu.hr/ECDSAP256SHA256/3502 
(ZSK) is now active
Jun  1 21:52:42 domac named[46537]: Fetching 
alu.hr/ECDSAP256SHA256/43987 (KSK) from key repository.
Jun  1 21:52:42 domac named[46537]: DNSKEY alu.hr/ECDSAP256SHA256/43987 
(KSK) is now published
Jun  1 21:52:42 domac named[46537]: DNSKEY alu.hr/ECDSAP256SHA256/43987 
(KSK) is now active
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): next key 
event: 01-Jun-2022 23:46:06.043
Jun  1 21:52:42 domac named[46537]: any newly configured zones are now 
loaded

Jun  1 21:52:42 domac named[46537]: running
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: zone alu.hr/IN (signed): attempt to 
lock key files, but no key file lock available, abort


I couldn't Google out any such message.

However, the BIND server started acting like a runaway, displying lines 
like this in the log:


Jun  1 22:06:55 domac named[43715]: validating arpa/DS: no valid 
signature found
Jun  1 22:06:55 domac named[43715]: validating arpa/DS: no valid 
signature found
Jun  1 22:06:56 domac named[43715]: validating arpa/DS: no valid 
signature found
Jun  1 22:06:56 domac named[43715]: validating arpa/DS: no valid 
signature found
Jun  1 22:06:56 domac named[43715]: validating arpa/DS: no valid 
signature found
Jun  1 22:06:56 domac named[43715]: validating arpa/DS: no valid 
signature found
Jun  1 22:06:56 domac named[43715]: validating arpa/DS: no valid 
signature found
Jun  1 22:06:56 domac named[43715]: valida

Re: Probably stupid simple question...

2022-06-01 Thread Bruce Johnson via bind-users

Thanks!

On Jun 1, 2022, at 1:48 PM, Sandro 
mailto:li...@penguinpee.nl>> wrote:

On 01-06-2022 20:07, Bruce Johnson via bind-users wrote:

I am migrating our BIND system to a new server/BIND version, and have
a question about dynamically updated zone files (we have one dynamic
zone). I am just copying all the configuration and zone files to the
new server, do I need to run rndc freeze before shutting down bind
and moving them or will just stopping the bind service properly deal
with updating the zone file? Also do I need to copy over the .jnl
file when I do this or will a new one get generated as needed?

Not a stupid question, but an easy answer (man 8 rndc):

This command stops the server, making sure any recent changes made through 
dynamic update or IXFR are first saved to the master files of the updated zones.

So as long as you stop named with 'rndc stop', the zone file will be up to 
date. That also makes the journal file obsolete. So, you don't need to move 
that over. But it doesn't hurt if you do.

Before starting named on the new system, assuming your main configuration file 
is 'etc/named.conf', use:

named-checkconf -z /etc/named.conf

This will check your configuration and all your zones and tell you if anything 
is wrong.

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

--
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

-- 
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: Probably stupid simple question...

2022-06-01 Thread Sandro


On 01-06-2022 20:07, Bruce Johnson via bind-users wrote:


I am migrating our BIND system to a new server/BIND version, and have
a question about dynamically updated zone files (we have one dynamic
zone). I am just copying all the configuration and zone files to the
new server, do I need to run rndc freeze before shutting down bind
and moving them or will just stopping the bind service properly deal
with updating the zone file? Also do I need to copy over the .jnl
file when I do this or will a new one get generated as needed?


Not a stupid question, but an easy answer (man 8 rndc):

This command stops the server, making sure any recent changes made 
through dynamic update or IXFR are first saved to the master files of 
the updated zones.


So as long as you stop named with 'rndc stop', the zone file will be up 
to date. That also makes the journal file obsolete. So, you don't need 
to move that over. But it doesn't hurt if you do.


Before starting named on the new system, assuming your main 
configuration file is 'etc/named.conf', use:


named-checkconf -z /etc/named.conf

This will check your configuration and all your zones and tell you if 
anything is wrong.


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

Probably stupid simple question...

2022-06-01 Thread Bruce Johnson via bind-users

 I am migrating our BIND system to a new server/BIND version, and have a 
question about dynamically updated zone files (we have one dynamic zone). I am 
just copying all the configuration and zone files to the new server, do I need 
to run rndc freeze before shutting down bind and moving them or will just 
stopping the bind service properly deal with updating the zone file? Also do I 
need to copy over the .jnl file when I do this or will a new one get generated 
as needed? 



-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

-- 
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: Parsing named.conf in PyParsing Python3 and JSON now available

2022-06-01 Thread Petr Špaček

On 29. 05. 22 22:37, S Egbert wrote:

oops

make that this link https://github.com/egberts/bind9_parser

On May 29, 2022, at 4:28 PM, S Egbert wrote:

Just a short blurb that I now make parsing named.conf easier in
Pyhton3 using PyParsing module.

Through a pythonized variable, one can also generate JSON string.

The end-use should be obvious to those who need one, but one of my
case is a large library of named.conf in pythonized form with
capability to change IP, port, and topology on the fly.

MIT License

Enjoy.

https://github.con/egberts/bind9_parser

Very interesting piece of work, thank you for sharing!

Accidentally I was working on something similar, so far limited to
parsing named.conf and rndc.conf grammars.

Very-much-work-in-progress can be seen here:
https://gitlab.isc.org/isc-projects/bind9/-/blob/pspacek/arm-utils/doc/misc/parsegrammar.py

I think it is a good idea to generalize the code to consume
https://gitlab.isc.org/isc-projects/bind9/-/blob/pspacek/arm-utils/doc/misc/options
files as much as possible because the grammar _is_ changing, albeit
slowly. It becomes more pressing when migrating between versions etc.

Feel free to approach me if you want to exchange ideas and code!

--
Petr Špaček @ Internet Systems Consortium
--
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: DNSSEC transition from manually signed zone to dnssec-policy "standard" failed

Re: Bugfix: missing line in message.c

Bugfix: missing line in message.c

DNSSEC transition from manually signed zone to dnssec-policy "standard" failed

Re: Probably stupid simple question...

Re: Probably stupid simple question...

Probably stupid simple question...

Re: Parsing named.conf in PyParsing Python3 and JSON now available

8 matches

Site Navigation

Mail list logo

Footer information