Re: [KASP] Key rollover

[Matthijs Mekking]

Hi Adrien,

Without any logs or key **state** files, I can't really tell what is 
going on.


My only gut feeling is that you have never signaled BIND 9 that the DS 
has been published. You can run 'rndc dnssec -checkds -key 12345 
published example.com' or set up parental-agents to do it for you.


Best regards,

Matthijs

On 1/17/23 09:38, adrien sipasseuth wrote:

Hello,

I put the management of DNSSEC with KASP, the zone is well functional. 
(dig with "AD" flag etc)


On the other hand, I can't see when the key rollover period for my KSK 
is over (2 KSKs with a dig DNSKEY...)


Without KASP, it was easy because I generated the second KSK key but 
with KASP, it is managed automatically.


So, I have to adapt my scripts to check that there is :
  - a used KSK key and a next KSK key
  - Or only one KSK key used (if we are not in rollover phase)

Except that with my current policy, I never see 2 KSKs via a "dig 
DNSKEY...".

here is my policy :

dnssec-policy "test" {
     keys {
         ksk lifetime P7D algorithm ecdsa256;
         zsk lifetime P3D algorithm ecdsa256;
     };
     purge-keys 1d;
     publish-safety 3d;
     retire-safety 3d;
};

I see either my KSK in use or my next KSK (via "dig DNSKEY...") but 
never both at the same time.


Is this a normal behavior or am I doing it wrong?

Regards, Adrien


--
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: [KASP] Key rollover

[Matthijs Mekking]

Hi Adrien,

I don't think it is fine yet. I see in your state file the following line:

> DSState: hidden

This means the DS is not published according to BIND.

> From my understanding, the second KSK should appear because I put the 
> parameter "publish-safety 3d;" that is to say 3 days before the

> expiration ("retired") of the key in use. is that right?

In addition to the DNSKEY TTL yes. The successor KSK should be 
pre-published the sum of dnskey-ttl, publish-safety, and 
zone-propagation-delay, prior to its retirement.


Best regards,

Matthijs

On 1/24/23 09:08, adrien sipasseuth wrote:

Hello Matthijs,

Indeed I had not published the DS at my registar because I thought that 
the second KSK would have appeared anyway at the time of the rollover.


I published the DS yesterday and I reported to BIND with the command you 
gave me. I didn't find any error in the logs so everything must have 
been fine!


here is the state file of the KSK in use :
; This is the state of key 46358, for ***.
Algorithm: 13
Length: 256
Lifetime: 604800
Predecessor: 28887
KSK: yes
ZSK: no
Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent

 From my understanding, the second KSK should appear because I put the 
parameter "publish-safety 3d;" that is to say 3 days before the 
expiration ("retired") of the key in use. is that right?


that is to say tonight at 7pm, I will see tomorrow if this one appears.

regards, Adrien



Le jeu. 19 janv. 2023 à 09:13, Matthijs Mekking <mailto:matth...@isc.org>> a écrit :


Hi Adrien,

Without any logs or key **state** files, I can't really tell what is
going on.

My only gut feeling is that you have never signaled BIND 9 that the DS
has been published. You can run 'rndc dnssec -checkds -key 12345
published example.com <http://example.com>' or set up
parental-agents to do it for you.

Best regards,

Matthijs

On 1/17/23 09:38, adrien sipasseuth wrote:
 > Hello,
 >
 > I put the management of DNSSEC with KASP, the zone is well
functional.
 > (dig with "AD" flag etc)
 >
 > On the other hand, I can't see when the key rollover period for
my KSK
 > is over (2 KSKs with a dig DNSKEY...)
 >
 > Without KASP, it was easy because I generated the second KSK key but
 > with KASP, it is managed automatically.
 >
 > So, I have to adapt my scripts to check that there is :
 >   - a used KSK key and a next KSK key
 >   - Or only one KSK key used (if we are not in rollover phase)
 >
 > Except that with my current policy, I never see 2 KSKs via a "dig
 > DNSKEY...".
 > here is my policy :
 >
 > dnssec-policy "test" {
 >      keys {
 >          ksk lifetime P7D algorithm ecdsa256;
 >          zsk lifetime P3D algorithm ecdsa256;
 >      };
 >      purge-keys 1d;
 >      publish-safety 3d;
 >      retire-safety 3d;
 > };
 >
 > I see either my KSK in use or my next KSK (via "dig DNSKEY...") but
 > never both at the same time.
 >
 > Is this a normal behavior or am I doing it wrong?
 >
 > Regards, Adrien
 >
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users

<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/
<https://www.isc.org/contact/> for more information.


bind-users mailing list
bind-users@lists.isc.org <mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
<https://lists.isc.org/mailman/listinfo/bind-users>



--
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: [KASP] Key rollover

[Matthijs Mekking]

On 1/24/23 15:18, adrien sipasseuth wrote:

Hello,

I don't why DSState: hidden, it's ok with some online check tools like :
- https://dnssec-analyzer.verisignlabs.com/ 
<https://dnssec-analyzer.verisignlabs.com/>

- https://zonemaster.net/fr/run-test <https://zonemaster.net/fr/run-test>


DSState: hidden is what BIND thinks. Note that it does not query yet to 
determine the DSState.





my master is hidden, it can be related ? How i can debug this DSState: 
hidden ?


It has nothing to do with hidden primaries.



I found this command to check actual status : rndc dnssec -status **
This is the output :

key: 46358 (ECDSAP256SHA256), KSK
   published:      yes - since Tue Jan 17 17:55:03 2023
   key signing:    yes - since Tue Jan 17 17:55:03 2023

   Next rollover scheduled on Tue Jan 24 17:55:03 2023
   - goal:           omnipresent
   - dnskey:         omnipresent
   - ds:             hidden
   - key rrsig:      omnipresent


It is hard to determine why your DS is hidden. If all other elements are 
omnipresent, the DS should be rumoured (because you may submit it to the 
parent).


I have a feeling this is because your publish-safety is 3 days. It takes 
an additional 3 days before continuing with the rollover, thus also with 
"making the DS known to the world". In other words, I think BIND does 
not yet think it is safe to publish the DS, hence DS is hidden.


I understand this may not reflect the real world, and perhaps it is a 
bug. If someone issues a "rndc dnssec -checkds published" command", we 
probably should force move the DS state from "hidden" to "rumoured".


Best regards,

Matthijs





...

Regards Adrien

Le mar. 24 janv. 2023 à 09:27, Matthijs Mekking <mailto:matth...@isc.org>> a écrit :


Hi Adrien,

I don't think it is fine yet. I see in your state file the following
line:

  > DSState: hidden

This means the DS is not published according to BIND.

  > From my understanding, the second KSK should appear because I
put the
  > parameter "publish-safety 3d;" that is to say 3 days before the
  > expiration ("retired") of the key in use. is that right?

In addition to the DNSKEY TTL yes. The successor KSK should be
pre-published the sum of dnskey-ttl, publish-safety, and
zone-propagation-delay, prior to its retirement.

Best regards,

Matthijs

On 1/24/23 09:08, adrien sipasseuth wrote:
 > Hello Matthijs,
 >
 > Indeed I had not published the DS at my registar because I
thought that
 > the second KSK would have appeared anyway at the time of the
rollover.
 >
 > I published the DS yesterday and I reported to BIND with the
command you
 > gave me. I didn't find any error in the logs so everything must have
 > been fine!
 >
 > here is the state file of the KSK in use :
 > ; This is the state of key 46358, for ***.
 > Algorithm: 13
 > Length: 256
 > Lifetime: 604800
 > Predecessor: 28887
 > KSK: yes
 > ZSK: no
 > Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
 > Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
 > Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
 > Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
 > Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
 > DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
 > PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
 > DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
 > KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
 > DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
 > DNSKEYState: omnipresent
 > KRRSIGState: omnipresent
 > DSState: hidden
 > GoalState: omnipresent
 >
 >  From my understanding, the second KSK should appear because I
put the
 > parameter "publish-safety 3d;" that is to say 3 days before the
 > expiration ("retired") of the key in use. is that right?
 >
 > that is to say tonight at 7pm, I will see tomorrow if this one
appears.
 >
 > regards, Adrien
 >
 >
 >
 > Le jeu. 19 janv. 2023 à 09:13, Matthijs Mekking mailto:matth...@isc.org>
 > <mailto:matth...@isc.org <mailto:matth...@isc.org>>> a écrit :
 >
 >     Hi Adrien,
 >
 >     Without any logs or key **state** files, I can't really tell
what is
 >     going on.
 >
 >     My only gut feeling is that you have never signaled BIND 9
that the DS
 >     has been published. You can run 'rndc dnssec -checkds -key 12345
 >     published example.com <http://example.com>
<http://examp

Re: isc stork agent and named chroot

[Matthijs Mekking]

Hi Vladimir,

I bet it is something about stork looking for the named.conf file in a 
specific location, but you may want to resend your message to stork-users:


https://lists.isc.org/mailman/listinfo/stork-users

Best regards,

Matthijs

On 1/27/23 13:51, Vladimir Nikolic via bind-users wrote:

Hi,

Looks like stork agent doesn't work in a named chroot environment.
On one of my systems, it complains about non-existing config file:

stork-agent[129190]: time="2023-01-27 04:47:07" level="warning" 
msg="cannot parse BIND 9 config file /etc/named.conf: exit status 1; 
/etc/named.conf:8: open: /etc/named.conf.inc: file not found\n" file=" 
  bind9.go:398  "


Although /var/named/chroot/etc/named.conf.inc file exists and named is 
working without issues.

OS is CentOS 7 and bind-chroot rpm version is 9.11.4-26.P2.el7_9.10.

Regards,
Vladimir

--
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: (use-)alt-transfer-source deprecated

[Matthijs Mekking]

Hi,

On 2/1/23 09:57, Gasoo wrote:

Hello

I recently updated to 9.18.x and noticed the deprecation warning in the 
logs for the option use-alt-transfer-source.
After reading the manual and checking my configuration, I am confused on 
how this is going to work in future releases.


My configuration includes the following statements:

options {
   listen-on { 1.1.1.1; 2.2.2.2; 3.3.3.3; };
   transfer-source  3.3.3.3;
   query-source  3.3.3.3;
   notify-source  3.3.3.3;
   use-alt-transfer-source no;
   ...
}


Looking at your configuration, you actually don't use 
alt-transfer-source: there is no such option in your example and 
'use-alt-transfer-source' is set to no anyway.


1.1.1.1 and 2.2.2.2 are only used for incoming DNS queries from clients 
and can not be used for zone transfers.
If I remove the option use-alt-transfer-source, in some cases (e.g. 
SERVFAIL from primary), additional zone transfers are tried via 
0.0.0.0#0, which the OS then sends via the best matching interface / IP 
address. >

For this reason the option use-alt-transfer-source is in my configuration.



 From the manual.

use-alt-transfer-source:
This indicates whether the alternate transfer sources should be used. If 
views are specified, this defaults to no; otherwise, it defaults to yes.

alt-transfer-source:
This indicates an alternate transfer source if the one listed in 
transfer-source fails and use-alt-transfer-source is set.



How will this be handled in future releases, if transfer-source is 
specified, no views are defined and an error occurs?

Is there any other solution to disable transfers from 0.0.0.0#0 in my case?


I guess in your 9.18 configuration if you don't set 
'use-alt-transfer-source', it defaults to yes. Since 
'alt-transfer-source' defaults to 0.0.0.0#0', you still need the 
configuration despite it is being deprecated.


From 9.20.0 the feature will be gone, the options 
'use-alt-transfer-source' and 'alt-transfer-source' will no longer 
exist, and thus alternate transfer source will no longer be tried.


In other words, from 9.20.0 it will be as if 'use-alt-transfer-source' 
was set to 'no'.


Best regards,

Matthijs





Kind Regards
Stephan


--
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: Determine parental-agents automatically

[Matthijs Mekking]

Consider your feature request applied ;)

https://gitlab.isc.org/isc-projects/bind9/-/issues/3901

On 2/27/23 11:01, Bernd Meisner wrote:

Hello list,

I am currently playing with dnssec-policy and parental-agents...
  
I'm pretty sure that I miss something but wouldn't it be a good idea to

have something like:
  
parental-agents auto;


which would be the same as looking up the NS of the parent zone and
creating something like

parental-agents {
   1st NS of parent zone;
   2nd NS of parent zone;
   3rd NS of parent zone;
   ...
};

on the fly?

Thanks and regards.

--
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: KASP: sharing policy and keys between views

[Matthijs Mekking]

Hi Carsten,

We did have some bugs in the past when it comes to sharing keys with 
dnssec-policy among different views. But the last one is from a year ago 
(fixed in 9.16.19).


So while I don't have experience myself with a similar setup, we did 
have some bug reports that used dnssec-policy and views that have been 
resolved and it has been quiet when it comes to "dnssec-policy with 
views" related bug reports.


Now that doesn't mean there are none, but hopefully adds a bit of 
confidence.


Best regards,
  Matthijs


On 3/17/23 11:46, Carsten Strotmann via bind-users wrote:

Hi,

(please do not start a discussion on the usefulness of views. I'm not
in favor of views, but sometimes I have to work with them).

I have a client that runs a split horizon (internal / external view
of the same domain namespace) setup with BIND 9 on Linux.

Both the internal and external views of the domain are DNSSEC
signed.

In the past, the setup was using "auto-dnssec maintain;" on a common,
shared key directory with manually created keys. Both zones in both
views fetched the keys and did the signing. This setup was stable and
working fine.

Because "auto-dnssec maintain;" is deprecated, we're evaluating to
change the setup to use a shared DNSSEC KASP definition, pointing to
the same key directory (using shared keys and a shared state file).

The test setup runs without issues for one month now and has
successfully done 3 ZSK rollovers in the time (KSK rollovers are
manual). So it *seems* like a working configuration. We have not seen
errors or race-conditions (but we might have been lucky).

Does anyone here has experience with a similar setup, or deeper
insight into the code and can tell me if this is a possible solution
to operate a DNSSEC signed split horizon setup?

Greetings

Carsten Strotmann



--
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: Fully automated DNSSEC with BIND 9.16

[Matthijs Mekking]

Hello David,

On 4/11/23 12:02, David Carvalho via bind-users wrote:

Hello, hope everyone is fine.

So it seems that going to Bind version 9.16 was the right call as it 
simplifies DNSSEC a lot.


Nevertheless, I would like to clarify some things because our 
organization has a parent domain and I host my own e-mail servers. I 
know they had problems while implementing DNSSEC on the top domain, and 
some configurations had to be made to let subdomain e-mail servers to 
still work after DNSSEC.


Following RedHat tutorial, all I had to do was add “*dnssec-policy 
default;”* into one of my zones for testing purposes. I’m not testing 
Reverse zones yet.


After this, 3 files “Kmy.domain***” were created:

“.key”

“.private”

“.state”.

Three  files regarding my zone were also created:

My.domain.signed

And the following 2, which I’m not sure what their purpose is

*My.domain*.*jbk* and*my.domain.signed.jnl*


The .jnl files are journal files and are created when a zone uses 
dynamic update to store changes that are made to zone files.


The .jbk files are truly temporary files and should be removed again 
when writing the contents of the zone to file.



There are also “managed-keys.bind” and “managed-keys.bind.jnl”


These are trust anchor files, and store the state of those keys. These 
will be updated on a restart.




My questions:

 1. Everytime I restart the service, it seems all these files are
recreated.  Does this mean that every time I make a change in the
host zone, I need resend the public key to my top domain?


No, the key files (.key, .private, .state) should also not be recreated 
upon restart (a bug that would recreate key files every keymgr run was 
fixed in 9.16.30).




 2. Do Parental Agents help with this?


Not in this case, because there is no need to send the public key to the 
parent domain. Parental agents only help to automatically detect if the 
corresponding DS has been published.


Without parental agents configured you need to use 'rndc dnssec 
-checkds' to tell BIND that a certain DS has been published/withdrawn in 
order to continue key rollover.




 3. Which format should I use when providing the key to the top level
domain? 


* dnssec-dsfromkey /var/named/K/example.com.+013+61141/.key*

or

* grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/


I assume you are submitting the public key to your registrar and it 
depends on what format your registrar accepts.



Best regards,

Matthijs

--
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: Fully automated DNSSEC with BIND 9.16

[Matthijs Mekking]

On 4/11/23 13:14, David Carvalho wrote:

Hello and thank you so much for your help. Regarding question 1, My
version is 9.16-9.1623-0.9.el8...so I got the bug. No update
available from Oracle Linux yet, so I'll create a folder and maintain
a copy of those files there.

In which situation should I be required to resend my key to the top
domain? I'll have to read more about ZSK, KSK and CSK rollovers. All
of this is new to me so far.


I think it would be useful to read this knowledge base article if all is 
new to you:


https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy

Basically in the following two scenarios you need to publish the public 
key to the parent domain:


1. Enabling DNSSEC
2. KSK rollover

With the default policy, KSK rollover is not scheduled, so only after 
you manually roll the key you need to publish (and withdraw) the DS 
records from the parent.


When exactly? You can check with 'rndc dnssec -status '. If the DS 
state is rumoured it is safe to submit the DS to the parent.


Best regards,

Matthijs





Thanks! David Carvalho



-Original Message- From: bind-users
 On Behalf Of Matthijs Mekking 
Sent: 11 April 2023 11:16 To: bind-users@lists.isc.org Subject: Re:

Fully automated DNSSEC with BIND 9.16

Hello David,

On 4/11/23 12:02, David Carvalho via bind-users wrote:

Hello, hope everyone is fine.

So it seems that going to Bind version 9.16 was the right call as
it simplifies DNSSEC a lot.

Nevertheless, I would like to clarify some things because our 
organization has a parent domain and I host my own e-mail servers.

I know they had problems while implementing DNSSEC on the top
domain, and some configurations had to be made to let subdomain
e-mail servers to still work after DNSSEC.

Following RedHat tutorial, all I had to do was add “*dnssec-policy 
default;”* into one of my zones for testing purposes. I’m not

testing Reverse zones yet.

After this, 3 files “Kmy.domain***” were created:

“.key”

“.private”

“.state”.

Three  files regarding my zone were also created:

My.domain.signed

And the following 2, which I’m not sure what their purpose is

*My.domain*.*jbk* and*my.domain.signed.jnl*


The .jnl files are journal files and are created when a zone uses
dynamic update to store changes that are made to zone files.

The .jbk files are truly temporary files and should be removed again
when writing the contents of the zone to file.


There are also “managed-keys.bind” and “managed-keys.bind.jnl”


These are trust anchor files, and store the state of those keys.
These will be updated on a restart.



My questions:

1. Everytime I restart the service, it seems all these files are 
recreated.  Does this mean that every time I make a change in the 
host zone, I need resend the public key to my top domain?


No, the key files (.key, .private, .state) should also not be
recreated upon restart (a bug that would recreate key files every
keymgr run was fixed in 9.16.30).



2. Do Parental Agents help with this?


Not in this case, because there is no need to send the public key to
the parent domain. Parental agents only help to automatically detect
if the corresponding DS has been published.

Without parental agents configured you need to use 'rndc dnssec
-checkds' to tell BIND that a certain DS has been published/withdrawn
in order to continue key rollover.



3. Which format should I use when providing the key to the top
level domain?

* dnssec-dsfromkey
/var/named/K/example.com.+013+61141/.key*

or

* grep DNSKEY /var/named/K*/*example.com.+013+61141.key*/


I assume you are submitting the public key to your registrar and it
depends on what format your registrar accepts.


Best regards,

Matthijs


--
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: Piggybacking on a zone’s dnssec-policy using auto-dnssec: How can one do this after Bind 9.19?

[Matthijs Mekking]

Hello Andrej,

On 4/16/23 23:08, Andrej Podzimek via bind-users wrote:

Hi bind-users,

I have asked this question on GitLab, but hijacking a closed issue to 
ask questions is bad practice (often rewarded with silence), so I’m 
re-posting the question here. 
https://gitlab.isc.org/isc-projects/bind9/-/issues/3769#note_356577


Sorry, I have missed the earlier comment on GitLab, but you are right, 
the bind-users list is a better place for such questions.



My DNS server serves multiple views that share zones but resolve their 
(mostly multi-homed) hosts to different addresses, depending on the view.


The easiest (?) way to make DNSSEC work in all views has been to keep a 
dnssec-policy for zones in *one* of the views (to generate and maintain 
keys) and then passively refer to the keys from the zones’ counterparts 
in other views using auto-dnssec. \o/


Now a log warning message is telling me that auto-dnssec will be 
removed. /o\


As outlined in the GitLab comment, I have been trying to find a 
dnssec-policy equivalent of auto-dnssec. Could it be something like this?


  dnssec-policy "ReuseKeysFromTheMainView" {
    keys {
      ksk key-directory lifetime unlimited algorithm 
ecdsap384sha384;
      zsk key-directory lifetime unlimited algorithm 
	;

    };
    nsec3param salt-length 16;
    publish-safety P1D;
    retire-safety P1D;
  };


When looking for the dnssec-policy equivalent of auto-dnssec, you will 
need to look at your current zone signing settings to determine the policy.


Look at your current keys and check their algorithm and key length. From 
your policy excerpt from above it looks like you are using a KSK/ZSK 
strategy with algorithm ECDSAP384SHA384 (14).


Key rollovers were done outside of BIND9, either manually or scripted. 
So "lifetime unlimited" makes sense here.


I assume your zone uses NSEC3. If the current salt length is 16, the 
NSEC3 chain should be maintained.


Furthermore:
- "sig-validity-interval":
  Specifies the number of days a signature is valid. The second optional
  value is the refresh interval. This equivalent of this option are
  the dnssec-policy options "signatures-validity" and "signatures-
  refresh".

- "dnskey-sig-validity": This equivalent of this option is the
  dnssec-policy option "signatures-validity-dnskey".

Other dnssec-policy options are related to key timings when doing key 
rollovers.





There are at least two concerns:

(1) Will the dependent “unlimited lifetime” views automatically pick up 
the key updates made by the main “limited lifetime” view (instead of 
blindly expecting the key files to never change)?


Sorry, I fail to understand what dependent "unlimited lifetime" views 
are, and what the main "limited lifetime" view is.


Are you perhaps asking how to initiate a key rollover with dnssec-policy?


(2) Which of the additional parameters have to be repeated in dependent 
“auto-dnssec-like”  zones that don’t generate their own keys?
     * The salt-length seems irrelevant (set and fixed at key generation 
time).
     * But how (if at all) will publish-safety and retire-safety work 
int his strange setup?


What are "auto-dnssec-like" zones? Zones that don't use "dnssec-policy"? 
In that case, for such zones "publish-safety" and "retire-safety" have 
no effect.


Best regards,

Matthijs


I may have overlooked something, but could not find this↑ in the 
documentation. Ideas and documentation pointers (to the best auto-dnssec 
equivalent) would be very helpful.


Cheers!
Andrej


--
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: Piggybacking on a zone’s dnssec-policy using auto-dnssec: How can one do this after Bind 9.19?

[Matthijs Mekking]

Hi Andrej,

While I am not 100% sure on your use case, let me at least respond to this:

> But I’m starting to realize that I had misunderstood and
> overcomplicated things; simply referencing the "standard" policy again
> from equivalent zones in different views should (?) magically work (as
> Nick Tait pointed out in another message). If that’s the case, then my
> concerns around forcing exactly one instance of a zone to maintain the
> keys and forcing all other instances to passively consume keys are
> null and void.
...
> So eventually it may be as simple as replacing “auto-dnssec maintain;”
> with “dnssec-policy "standard";” and *not* worrying about having
> exactly one “key producing” instance of each zone, because Bind can
> handle this automatically. (?) I’ll give that a try.

That is correct: When you have the same zone (identical name) in 
multiple different views that refer to the same dnssec-policy, there 
will be only one set of keys maintained that is shared for that zone in 
all views.


Best regards,

Matthijs



On 4/17/23 13:03, Andrej Podzimek wrote:

Hi Matthijs,

Thanks for your response.


  dnssec-policy "ReuseKeysFromTheMainView" {
    keys {
      ksk key-directory lifetime unlimited algorithm 
ecdsap384sha384;

      zsk key-directory lifetime unlimited algorithm ;
    };
    nsec3param salt-length 16;
    publish-safety P1D;
    retire-safety P1D;
  };


When looking for the dnssec-policy equivalent of auto-dnssec, you will 
need to look at your current zone signing settings to determine the 
policy.


Look at your current keys and check their algorithm and key length. 
From your policy excerpt from above it looks like you are using a 
KSK/ZSK strategy with algorithm ECDSAP384SHA384 (14).


Key rollovers were done outside of BIND9, either manually or scripted. 
So "lifetime unlimited" makes sense here.


The dnssec-policy example above was meant to serve as an auto-dnssec 
equivalent that passively consumes keys, not “the real thing”. That’s 
why it’s called “ReuseKeysFromTheMainView”. The policy that actually 
generates the key files looks like this (and has a finite lifetime):


  dnssec-policy "standard" {
    keys {
      ksk key-directory lifetime 361d algorithm ecdsap384sha384;
      zsk key-directory lifetime 61d algorithm ecdsap384sha384;
    };
    nsec3param salt-length 16;
    publish-safety P1D;
    retire-safety P1D;
  };


There are at least two concerns:

(1) Will the dependent “unlimited lifetime” views automatically pick 
up the key updates made by the main “limited lifetime” view (instead 
of blindly expecting the key files to never change)?


Sorry, I fail to understand what dependent "unlimited lifetime" views 
are, and what the main "limited lifetime" view is.


Are you perhaps asking how to initiate a key rollover with dnssec-policy?


The “limited lifetime” view’s zones reference the "standard" policy 
directly.
An “unlimited lifetime” view’s zones reference keys generated by the 
"standard" policy. This is currently achieved using “auto-dnssec 
maintain”. Later, once auto-dnssec is gone, I thought that referencing 
the fake "ReuseKeysFromTheMainView" policy would yield a similar behavior.


(2) Which of the additional parameters have to be repeated in 
dependent “auto-dnssec-like”  zones that don’t generate their own keys?
 * The salt-length seems irrelevant (set and fixed at key 
generation time).
 * But how (if at all) will publish-safety and retire-safety work 
int his strange setup?


What are "auto-dnssec-like" zones? Zones that don't use 
"dnssec-policy"? In that case, for such zones "publish-safety" and 
"retire-safety" have no effect.


IIUC, all my zones in all views will have to switch to dnssec-policy, 
eventually, once auto-dnssec ceases to exist.


But I’m starting to realize that I had misunderstood and overcomplicated 
things; simply referencing the "standard" policy again from equivalent 
zones in different views should (?) magically work (as Nick Tait pointed 
out in another message). If that’s the case, then my concerns around 
forcing exactly one instance of a zone to maintain the keys and forcing 
all other instances to passively consume keys are null and void.


(As a side note, the best zone sharing option (which already works for 
me in some cases) is the “in-view” pointer, which automatically copies 
all zone settings, including the "standard" DNSSEC policy. The reason 
why certain zones are (re)defined in other views rather than linked 
using “in-view” is a need for different zone data, different 
“allow-query” settings etc.)


So eventually it may be as simple as replacing “auto-dnssec maintain;” 
with “dnssec-policy "standard";” and *not* worrying about having exactly 
one “key producing” instance of each zone, because Bind can handle this 
automatically. (?) I’ll give that a

Re: Old ZSK refuses to retire

[Matthijs Mekking]

Hi Carsten,

This is too little information to figure out what is going on.

Can you share (offline if you wish) the output of 'rndc dnssec -status 
'?


Can you share the contents of the ".state" files for the given zone?

And can you enable debug logs (level 3) (I am particularly the "keymgr" 
logs).


Thanks, best regards,

Matthijs



On 4/26/23 14:09, Carsten Strotmann via bind-users wrote:

Hi,

I have a situation where in a BIND 9 zone with dnssec-policy and 
inline-signing, after a ZSK rollover, the (old) ZSK is refusing to retire. 
Although the timing metadata shows the retire and deletion dates in the past, 
the ZSK is still in the zone and is signing the records (along with the new 
ZSK, so there are two ZSK RRSigs on each RRSet).

Setting new retire/inactive + deletion times with dnssec-settime (with 
parameter -s to update the state file) does not help either.

Removing the key files will stop the key being active (there are no new RRSigs 
generated from this key), but the DNSKEY record still stays in the zone.

Any idea how to recover from such a situation (other than removing the signed 
zone and journals and re-signing the zone again)?

Greetings

Carsten


--
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-policy change from ZSK/KSK to CSK failed (bogus DNSSEC for zone)

[Matthijs Mekking]

Hi,

On 6/2/23 13:53, Sebastian Wiesinger wrote:

Hi,

I recently moved from auto-dnssec to dnssec-policy and after the
switch I tried to change a zone from an RSA ZSK/KSK to an ECDSA CSK.

When I changed the dnssec-policy from rsa to ecdsa-csk the old keys
immediately got removed which lead to a bogus DNSSEC for the zone. I
was expecting a rollover procedure.


Did you wait until the migration was complete? Everything needs to be 
omnipresent after the migration before you can making DNSSEC policy 
changes safely.


I noticed:

>- ds: hidden

This means that from BIND's perspective the DS has not been published. 
Most likely because the other keys were not fully omnipresent yet.


If the DS is not published yet, or at least the migration has not 
reached this state yet, you can do anything with the DNSSEC records, 
because of the absence of a secure delegation


Best regards,

Matthijs



BIND version is 9.18.12 (Debian Backports).

My question is, did I do something wrong? What would have been the
right way to do it? I noticed that the DS state is "hidden" before and
after the switch of the dnssec-policy but I found no way to change
that.

Here is config and logs of the change:

Old and new policy are:

dnssec-policy "rsa" {
 keys {
 ksk key-directory lifetime unlimited algorithm rsasha256 2048;
 zsk key-directory lifetime P60D algorithm rsasha256 1024;
 };
};

dnssec-policy "ecdsa-csk" {
 keys {
 csk key-directory lifetime unlimited algorithm 13;
 };
};

Zone definition is:

zone "sub.my.zone" {
 type master;
 file "/etc/bind/dynamic-zones/sub.my.zone/sub.my.zone";
 allow-transfer { localhost; ns2; };
 key-directory "/etc/bind/dynamic-zones/sub.my.zone";
 dnssec-policy "ecdsa-csk";
 parental-agents { 127.12.12.13; };
 allow-update { key sub.my.zone_api.; };
};


Jun 02 13:26:19 alita named[1001022]: general: notice: zone 
sub.my.zone/IN/default: checkds: set 1 parentals
Jun 02 13:26:19 alita named[1001022]: dnssec: info: zone 
sub.my.zone/IN/default: reconfiguring zone keys
Jun 02 13:26:19 alita named[1001022]: dnssec: info: keymgr: retire DNSKEY 
sub.my.zone/RSASHA256/54096 (ZSK)
Jun 02 13:26:19 alita named[1001022]: dnssec: info: keymgr: retire DNSKEY 
sub.my.zone/RSASHA256/56781 (ZSK)
Jun 02 13:26:19 alita named[1001022]: dnssec: info: keymgr: retire DNSKEY 
sub.my.zone/RSASHA256/13786 (KSK)
Jun 02 13:26:19 alita named[1001022]: dnssec: info: keymgr: DNSKEY 
sub.my.zone/ECDSAP256SHA256/36745 (CSK) created for policy ecdsa-csk
Jun 02 13:26:19 alita named[1001022]: dnssec: info: DNSKEY 
sub.my.zone/RSASHA256/56781 (ZSK) is now deleted
Jun 02 13:26:19 alita named[1001022]: dnssec: info: DNSKEY 
sub.my.zone/RSASHA256/13786 (KSK) is now deleted
Jun 02 13:26:19 alita named[1001022]: dnssec: info: Fetching 
sub.my.zone/ECDSAP256SHA256/36745 (CSK) from key repository.
Jun 02 13:26:19 alita named[1001022]: dnssec: info: DNSKEY 
sub.my.zone/ECDSAP256SHA256/36745 (CSK) is now published
Jun 02 13:26:19 alita named[1001022]: dnssec: info: DNSKEY 
sub.my.zone/ECDSAP256SHA256/36745 (CSK) is now active
Jun 02 13:26:19 alita named[1001022]: dnssec: info: zone 
sub.my.zone/IN/default: next key event: 02-Jun-2023 13:31:19.338
Jun 02 13:26:19 alita named[1001022]: notify: info: zone 
sub.my.zone/IN/default: sending notifies (serial 2014014053)

DNSSEC status before:

dnssec-policy: rsa
current time:  Fri Jun  2 13:23:54 2023

key: 54096 (RSASHA256), ZSK
   published:  no
   zone signing:   no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: hidden
   - zone rrsig: unretentive

key: 56781 (RSASHA256), ZSK
   published:  yes - since Fri Jun  2 11:15:23 2023
   zone signing:   yes - since Fri Jun  2 12:20:23 2023

   Next rollover scheduled on Tue Aug  1 10:15:23 2023
   - goal:   omnipresent
   - dnskey: omnipresent
   - zone rrsig: rumoured

key: 13786 (RSASHA256), KSK
   published:  yes - since Wed Jan 22 22:42:33 2014
   key signing:yes - since Wed Jan 22 22:42:33 2014

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
   - ds: hidden
   - key rrsig:  omnipresent



DNSSEC status after:

dnssec-policy: ecdsa-csk
current time:  Fri Jun  2 13:32:23 2023

key: 54096 (RSASHA256), ZSK
   published:  no
   zone signing:   no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: hidden
   - ds: hidden
   - zone rrsig: unretentive
   - key rrsig:  hidden

key: 56781 (RSASHA256), ZSK
   published:  no
   zone signing:   no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: unretentive
   - ds: unretentive
   - zone rrsig: unretentive
   - key rrsig:  unretentive

key: 36745 (ECDSAP256SHA256), CSK
   published:  yes - since Fri Jun  2 13:26:19 2023
   key signing:

Re: dnssec not automatically updating on 1 server

[Matthijs Mekking]

First of all, I don't recommend copying the configuration and having two 
primaries signing the same zone. It would at least need some key 
management synchronizing the signing keys.


I see that the DNSKEY set from ns1 differs from ns2 (there are two more 
keys there, where do they come from?)


Please provide 'rndc dnssec -status' output for the zone on both servers.

Please provide the logs as Ondrej said. Also preferably everything on 
level 3 debug.


Best regards,

Matthijs

On 6/15/23 15:54, Michael Martinell via bind-users wrote:
Anybody have any ideas on why my dnssec records don’t always 
automatically update on my NS2 authoritative server?  On my NS1 
authoritative server the records update without issue.


NS2 is an exact copy of NS1. We SCP all of the config files from the 
first server to the second server and do “rndc reconfig && rndc reload 
&& systemctl restart bind” on both servers.


They are both Centos 7 running Bind 9.16.40.

When it fails, I get this message:

[root@ns2 ~]# delv itctel.com @ns2.itctel.com

;; validating itctel.com/A: verify failed due to bad signature 
(keyid=3593): RRSIG has expired


;; validating itctel.com/A: no valid signature found

;; RRSIG has expired resolving 'itctel.com/A/IN': 75.102.160.231#53

;; validating itctel.com/A: verify failed due to bad signature 
(keyid=3593): RRSIG has expired


;; validating itctel.com/A: no valid signature found

;; RRSIG has expired resolving 'itctel.com/A/IN': 
2607:d600:9000:300:75:102:160:231#53


;; resolution failed: RRSIG has expired

I have this policy in named.conf

dnssec-policy "itc-no-rotate" {

     keys {

     ksk key-directory lifetime unlimited algorithm 13;

     zsk key-directory lifetime unlimited algorithm 13;

     };

     nsec3param;

};

I have this set up in a custom includes file:

zone "itctel.com" in {

     type master;

     file "forward/itctel.com.zone";

     dnssec-policy itc-no-rotate;

     inline-signing yes;

};

No changes to my actual zone files. The inline signing takes care of 
everything.


Here is a list of my files for this domain

/var/named/forward/itctel.com.zone  
/var/named/forward/itctel.com.zone.jnl  
/var/named/forward/itctel.com.zone.signed


/var/named/forward/itctel.com.zone.jbk   
/var/named/forward/itctel.com.zone.new  
/var/named/forward/itctel.com.zone.signed.jnl


*Michael Martinell*
Network/Broadband Technician

*Interstate Telecommunications Coop., Inc.
*312 4th Street West • Clear Lake, SD 57226
Phone: (605) 874-8313
michael.martin...@itccoop.com
www.itc-web.com



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

[Matthijs Mekking]

Perhaps this article is a better read for you:

https://kb.isc.org/v1/docs/en/dnssec-key-and-signing-policy

Best regards,

Matthijs


On 6/22/23 22:03, Daniel A. Rodriguez via bind-users wrote:

Thanks, I was reading but wasn't able to decode that.


Best regards


El 22 de junio de 2023 4:27:21 p. m. GMT-03:00, "Ondřej Surý" 
 escribió:


It’s not. TL;DR use dnssec-policy.

The more elaborate version of the TL;DR can be found in the DNSSEC
Guide here:
https://bind9.readthedocs.io/en/v9.18.16/dnssec-guide.html


--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do
not feel obligated to reply outside your normal working hours.


On 22. 6. 2023, at 20:43, Daniel A. Rodriguez via bind-users
 wrote:


I wonder if it's mandatory make a manual deployment prior to an
automated setup.
-- 
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




--
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: Master file permission denied

[Matthijs Mekking]

I suspect permissions on the key-directory are not yet correct:

key-directory "/var/cache/bind/keys";

On 6/28/23 22:35, Daniel Armando Rodriguez via bind-users wrote:

However, as soon as I added this

    dnssec-policy "default";
    inline-signing yes;

Error came up again :-(

--
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: extended dns error

[Matthijs Mekking]

Upgrade to 9.18, because 9.16 does not support extended DNS errors.

See

https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_date&state=all&label_name%5B%5D=Extended%20DNS%20Errors&first_page_size=20

For which errors are supported.

Best regards, Matthijs

On 7/11/23 11:10, sami.ra...@sofrecom.com wrote:

Hello  community

I want to use "extended dns error" option on my recursive dns server. 
What config changes are required to enable EDE?


I am using BIND 9.16.42 as recursive server.

Regards Sami



--
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 Setup ARM Manual vs KB article on adding inline-signing for non-dynamic zones

[Matthijs Mekking]

On 7/24/23 20:14, E R wrote:
As if DNSSec is not confusing enough...It seems the ARM manual that 
matches my release is out of step with the web site.  I followed the 
"Easy-Start Guide for Signing Authoritative Zones" in the ARM manual 
after manually signing my test zone for my starting point.  The ARM says 
you ONLY need to specify "dnssec-policy default;" in your zone, view or 
options clause for the newer way to sign things.  I completed the steps 
successfully (except for one command that no longer works as shown in 
the manual which is not important).  I cannot find anything broken 
with BIND 9.16.23-RH (Extended Support Version) when I follow the ARM 
manual.


This document https://kb.isc.org/docs/dnssec-key-and-signing-policy 
 says I need to 
have dynamic zone for things to work.  Don't need or design anything 
other than a good ole static zone since an entry is changed like 3-4 
times per year.  The newest ARM has a new section that mentions needing 
to setup Dynamic DNS but it also states that BIND previously used 
implicit inline-signing.  It is really difficult for a casual observer 
to sort this out.  No reference to what they mean by "previously".


It says in the blue box dynamic zones required **or** inline-signing 
enabled.


Did they break builds newer than 9.16.23 and that is why I am not seeing 
any issues?  Or is it the fact that I am not an DNSSEC expert I am not 
seeing a glaring issue?


This has been true since 9.16.33.

Best regards,

Matthijs
--
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-policy syntax error in options but not in view

[Matthijs Mekking]

What Mark said.

So that would become:

dnssec-policy "mydefault" {
keys {
csk key-directory lifetime unlimited algorithm ecdsa256;
};
};

options {
dnssec-policy "mydefault";
};


On 8/4/23 01:32, Mark Andrews wrote:
You can’t define a policy there. You can tell named to use the policy. 
Move the definition outside of options.


--
Mark Andrews


On 4 Aug 2023, at 08:26, E R  wrote:


My understanding from the ARM is that the dnssec-policy can be in the 
"options", "view" or "zone".  I have mine in "view" and when I try to 
move into "options" I get a syntax error that I cannot seem to 
understand what is wrong.  I stripped out all other statements and 
reduced the dnssec-policy to just a handful of items to KISS and I 
still do not see why why I get the error from named-checkconf.  I can 
move the block from under "options" to the "view" and it just works so 
I am not sure why named-checkconf thinks there is a missing 
semicolon?  Bind 9.16.23-RH.


# named-checkconf 1.conf
1.conf:3: missing ';' before '{'
1.conf:3: '}' expected near '{'

# cat 1.conf
options {
   dnssec-policy "mydefault" {
     keys {
         csk key-directory lifetime unlimited algorithm ecdsa256;
     };
   };
 };


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



--
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: question about DNSSEC with PKCS11

[Matthijs Mekking]

Hi,

The KB article was written before dnssec-policy. Unfortunately, OpenSSL 
with engine_pkcs11 does not support creating keys. So if you want to use 
an HSM with dnssec-policy, you will need to create the keys yourself and 
you can then import them in the key-directory with dnssec-keyfromlabel. 
Then, when it is time to create a new key according to BIND, it will 
select a pregenerated key instead.


Sorry for this inconvenience. We are working on making dnssec-policy 
work with HSMs including key generation through the OpenSSL 3.0 provider 
API.


Best regards,

Matthijs


On 8/5/23 04:50, sun guonian wrote:

hi,

I have tried the DNSSEC sign testing according the document,
https://kb.isc.org/docs/bind-9-pkcs11 


(and section 5.5 of the Bv9ARM of version 9.18.16)

I have two questions about it,

1. since I use HSM(now is softhsm) to store the DNSSEC key, does it more
insecure to convert the key(s) from HSM to .private file with 
dnssec-keyfromlabel ?


2. when I configure KASP policy, I notice that bind will generate new key(s)
each time it need, but there is no new object in softhsm generated. 
Could bind

of this version roll the objects in HSM/softhsm ?

Thanks in advanced.

Best Regards,
SUN Guonian

And my environment is,
bind-9.18.16
opensc-0.42
softhsm-2.6.1
openssl-1.1.1k from system
RockyLinux 8


--
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: KASP Rollover = Immediate Loss of DNSKEY (Why Do Inactive Keys Disappear?)

[Matthijs Mekking]

When your ZSK is safe to be retired depends on the state of the DS, so 
without knowing the state of the KSK it is hard to say whether this 
immediate removal of the old ZSK is legit or not.


Best regards,

Matthijs


On 10/20/23 01:46, Eddie Rowe wrote:
Thank you for your kind reply - BIND is too smart for me!  I can confirm 
that when you use a CSK key that letting BIND know that the key has been 
published ("rndc dnssec -keyid value -checkds published zone") resolves 
the issue with a CSK rollover which I tried since I had issues with ZSKs 
doing the same thing.


The same solution does not seem to impact a ZSK rollover which baffles 
me.  Are there any other considerations for when BIND might rollover a 
ZSK sooner than I expected?


I waited until ZSK was omnipresent and as soon as I run the rollover 
command the old key disappears (3 hour TTL) and my test zone is 
immediately resigned with the new ZSK.  Rollover was about 30 minutes 
ago and current time is 18:40 on Oct 19...info shows that the original 
ZSK should be still active but it is not.


*Original ZSK Key*

# cat *43876*.state

; This is the state of key 43876, for myexample2.com.

Algorithm: 13

Length: 256

Lifetime: 17702

Successor: 5264

KSK: no

ZSK: yes

Generated: 20231019202240 (Thu Oct 19 15:22:40 2023)

Published: 20231019202240 (Thu Oct 19 15:22:40 2023)

Active: 20231019202240 (Thu Oct 19 15:22:40 2023)

*Retired: 20231020011742 (Thu Oct 19 20:17:42 2023)*

Removed: 20231030022242 (Sun Oct 29 21:22:42 2023)

DNSKEYChange: 20231019231242 (Thu Oct 19 18:12:42 2023)

ZRRSIGChange: 20231019231242 (Thu Oct 19 18:12:42 2023)

DNSKEYState: unretentive

ZRRSIGState: unretentive

GoalState: hidden


*New ZSK Key*

# cat *5264*.state

; This is the state of key 5264, for myexample2.com.

Algorithm: 13

Length: 256

Lifetime: 5184000

Predecessor: 43876

KSK: no

ZSK: yes

Generated: 20231019231242 (Thu Oct 19 18:12:42 2023)

Published: 20231019231242 (Thu Oct 19 18:12:42 2023)

*Active: 20231020011742 (Thu Oct 19 20:17:42 2023)*

Retired: 20231219011742 (Mon Dec 18 19:17:42 2023)

Removed: 20231229022242 (Thu Dec 28 20:22:42 2023)

DNSKEYChange: 20231019231242 (Thu Oct 19 18:12:42 2023)

ZRRSIGChange: 20231019231242 (Thu Oct 19 18:12:42 2023)

DNSKEYState: rumoured

ZRRSIGState: rumoured

GoalState: omnipresent


# dig @localhost myexample2.com DNSKEY +multi

; <<>> DiG 9.16.23-RH <<>> @localhost myexample2.com DNSKEY +multi

; (2 servers found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56141

;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; COOKIE: cb17dbf88eab8fab01006531b7fe20a031be5b4fab07 (good)

;; QUESTION SECTION:

;myexample2.com.IN DNSKEY

;; ANSWER SECTION:

myexample2.com.3600 IN DNSKEY 257 3 13 (

N7XVBtoat8ebr4jYDczH6cb/6WLJCYJ+A2h+wmQXh/Am

F21xZsZ5awToRz6pC3Z11m1q1fOxN+JKa3x4xQOPIA==

) ; KSK; alg = ECDSAP256SHA256 ; key id = 28233

myexample2.com.3600 IN DNSKEY 256 3 13 (

fInt/iKpWoqsQdIpninExDUyOUZCgM/tGl3I5vgoogpK

ivBEwi9FRRUSMYpTY+etEWXGwSdm7jkHowrhjWz3ZQ==

) ; *ZSK; alg = ECDSAP256SHA256 ; key id = 5264*

;; Query time: 1 msec

;; SERVER: 127.0.0.1#53(127.0.0.1)

;; WHEN: Thu Oct 19 18:13:02 CDT 2023

;; MSG SIZErcvd: 231




*From:* Mark Andrews 
*Sent:* Sunday, October 8, 2023 8:11 PM
*To:* Eddie Rowe 
*Cc:* bind-users@lists.isc.org 
*Subject:* Re: KASP Rollover = Immediate Loss of DNSKEY (Why Do Inactive 
Keys Disappear?)



 >Given the parent zone doesn’t have DS records for the zone and there 
is no >private trust anchor published,
 >there is no harm in changing the DNSKEYs immediately.  Try again and 
this time >tell named that there are

 >DS records published for the zone.

 >  rndc dnssec -keyid value -checkds published zone

 >This is also how you tell named about private trust anchors which are 
equivalent >to publishing DS records

 >in the parent.




--
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: How to update zone with dnssec-policy (error with nsupdate: RRset exists)

[Matthijs Mekking]

Hi,

Disabling inline-signing is a good workaround. The issue is that BIND 
with inline-signing maintains a signed file separately and needs to bump 
the SOA SERIAL.


The serial queried is for the DNSSEC signed zone, but the dynamic update 
is done against the unsigned version of the zone. Hence the prereq 
yxrrset failure.


There is a related issue on our gitlab about this: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/4352


Best regards,
Matthijs


On 10/24/23 08:13, Matthias Fechner wrote:

Am 08.07.2023 um 08:48 schrieb Matthias Fechner:
If I try now to update some records remotely on the server I see in 
the log of the server:

==> /var/named/var/log/named.log <==
08-Jul-2023 07:40:22.962 update-security: info: client @0x848ac0760 
93.182.104.69#18475/key idefix.fechner.net-beta.fechner.net: signer 
"idefix.fechner.net-beta.fechner.net" approved
08-Jul-2023 07:40:22.962 update: info: client @0x848ac0760 
93.182.104.69#18475/key idefix.fechner.net-beta.fechner.net: updating 
zone 'fechner.net/IN': update unsuccessful: fechner.net/SOA: 'RRset 
exists (value dependent)' prerequisite not satisfied (NXRRSET)


What I did is at first execute nsdiff to control if the changes are 
making sense with:

nsdiff  -k ../.key fechner.net fechner.net

```

nsdiff: loading zone fechner.net. via AXFR from ns.fechner.net.
zone fechner.net/IN: loaded serial 2023070228 (DNSSEC signed)
OK
nsdiff: loading zone fechner.net. from file fechner.net
zone fechner.net/IN: loaded serial 2023070201
OK
prereq yxrrset fechner.net. IN SOA  ns.fechner.net. 
hostmaster.fechner.net. 2023070228 43200 7200 1814400 86400
update add fechner.net. 300 IN SOA  ns.fechner.net. 
hostmaster.fechner.net. 2023070229 43200 7200 1814400 86400
update delete fechner.net. IN TXT   "v=spf1 a mx 
a:anny.lostinspace.de mx:freebsd.org a:mx2.freebsd.org ~all"
update add fechner.net. 300 IN TXT  "v=spf1 a mx 
a:anny.lostinspace.de a:beta.fechner.net mx:freebsd.org 
a:mx2.freebsd.org ~all"
update delete gitlab.fechner.net. IN TXT    "v=spf1 a mx 
a:anny.lostinspace.de -all"
update add gitlab.fechner.net. 300 IN TXT   "v=spf1 a mx 
a:anny.lostinspace.de a:beta.fechner.net -all"
update delete ark.fechner.net. IN TXT   "v=spf1 a mx 
a:anny.lostinspace.de -all"
update add ark.fechner.net. 300 IN TXT  "v=spf1 a mx 
a:anny.lostinspace.de a:beta.fechner.net -all"
update delete news.fechner.net. IN TXT  "v=spf1 a mx 
a:anny.lostinspace.de -all"
update add news.fechner.net. 300 IN TXT "v=spf1 a mx 
a:anny.lostinspace.de a:beta.fechner.net -all"

send
answer
```

So I tried to chain nsupdate to it with:
nsdiff  -k ../.key fechner.net fechner.net | nsupdate -k ../.key

```

nsdiff: loading zone fechner.net. via AXFR from ns.fechner.net.
zone fechner.net/IN: loaded serial 2023070228 (DNSSEC signed)
OK
nsdiff: loading zone fechner.net. from file fechner.net
zone fechner.net/IN: loaded serial 2023070201
OK
update failed: NXRRSET
Answer:
;; ->>HEADER<<- opcode: UPDATE, status: NXRRSET, id: 14683
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;fechner.net.   IN  SOA

;; TSIG PSEUDOSECTION:
idefix.fechner.net-beta.fechner.net. 0 ANY TSIG hmac-sha256. 
1688794822 300 32 re/dNrsChdUQSyzMox2O+uAQWJG7+LBWNkS19QmJ48U= 14683 
NOERROR 0

```

anyone an idea what can cause this? 


if anyone else has these problems, I need to disable inline-signing:
inline-signing no;

after this, it is working perfectly fine.

Gruß
Matthias


--
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: Old link in DNSSEC Guide for number of TLDs with DNSSEC

[Matthijs Mekking]

Thank you for pointing it out.

In the future, you can create a gitlab issue for such things.

For this one I created one already:

https://gitlab.isc.org/isc-projects/bind9/-/issues/4417

Best regards,

Matthijs

On 11/4/23 17:04, Kurt Jaeger wrote:

Hi!

In

https://bind9.readthedocs.io/en/v9.18.19/dnssec-guide.html

there's a link to

https://stats.research.icann.org/dns/tld_report/

which is no longer valid. New data seems to be here:

https://ithi.research.icann.org/
ITHI == idenitifier technologies health indicators
how many TLDs support DNSSEC ?
  https://ithi.research.icann.org/graph-m7.html


--
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: KASP Key Rollover: ZSK Disappears Immediately

[Matthijs Mekking]

Hi Nick,

The timings are based on what is configured in the dnssec-policy: It is 
too costly to observe the zone every time to see if there is still a 
signature of the predecessor key. So yes: it takes the maximum possible 
time to determine when all signatures have been replaced.


This time is Iret (based on RFC 7583) and the main portion of that is 
Dsgn, the delay needed to ensure that all existing RRsets have been 
re-signed with the new key. The maximum sign delay is:


Dsgn = (signatures-validity - signatures-refresh)

In the default policy this is indeed 9 days.

I still suspect that the original issue from Eddie was because the KSK 
had its DS state in hidden.


Best regards,

Matthijs

On 11/13/23 09:55, Nick Tait via bind-users wrote:

On 03/10/2023 09:59, Eddie Rowe wrote:

I appreciate the feedback.  I did make sure the ZSK is omnipresent and the
issue still happens so it might be that my attempt to take the default 
policy
and bring it down to 1 day to hurry along testing.  I will see if I 
can find
any test policies in the list archives and failing that use the 
default one

with a greater amount of patience.

Hi Eddie.

Not sure if you're still interested in this topic, but a couple of weeks 
ago I did a manual ZSK roll-over, to see if I observed results similar 
to what you described in your original email...


Before starting the rollover /everything/ was showing omnipresent.

After initiating the rollover things mostly happened in the expected 
timeframes, but there was one thing that surprised me: The old ZSK 
removal date was set 9-and-a-bit days(!) after the roll-over was 
initiated, and the old ZSK and new ZSK state files showed "ZRRSIGState: 
unretentive" and "ZRRSIGState: rumoured" (respectively) right up until 
the old ZSK removal date, before eventually transitioning to the 
expected end states of "ZRRSIGState: hidden" and "ZRRSIGState: 
omnipresent" (respectively). This was in spite of the fact that all 
RRSIG records were replaced with the new ZSK more than a week prior. I 
can only assume that the 9 days somehow relates to how long BIND wanted 
to allow itself to generate RRSIGs for all the records in a really, 
really large zone file?


Anyway, I remembered seeing "ZRRSIGState: rumoured" in your ZSK state 
file before you initiated your ZSK roll-over, and so I suspect that all 
your issues stem from the fact that not everything was omnipresent 
before you initiated the roll-over?


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: Switching to a different dnssec-policy broke my zone.

[Matthijs Mekking]

This should be possible.

Please file a bug report:

https://gitlab.isc.org/isc-projects/bind9/-/issues/new

Mention the version used and describe the steps how to reproduce.

Best regards,

Matthijs

On 11/22/23 13:20, Björn Persson wrote:

My zone was previously signed with a KSK and a ZSK with unlimited
lifetime. I switched the zone over to a dnssec-policy using CSKs and
automatic key rotation. After the DS record was updated, most of the
RRSIG records were removed, leaving the zone broken to validating
resolvers.

Am I not supposed to do that, or is this a known bug, or do I need to
spend the time to write a detailed bug report?

Björn Persson



--
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: migration from auto-dnssec to dnssec-policy deletes keys immediately

[Matthijs Mekking]

On 12/28/23 12:58, Adrian Zaugg wrote:

Hi Nick

Not changing the key algo does help indeed when introducing dnssec-policy, see
the log below. Thank you very much for pointing this out.

But I do not understand why BIND deletes valid and published keys, just
because there should be another algo used. Couldn't this be done in a smooth
key rollover process aswell? Maybe someone with more insights than I have,
could explain this behaviour. Thanks!


I suspect because it did not have the right key states set. In order to 
do this all automatically we need to maintain state. Prior to 
dnssec-policy there is no such state. When migrating to dnssec-policy we 
try to derive the key states from the key timing metadata in the key files.


You should check if the migration is complete and all key states are in 
omnipresent. You can do so with 'rndc dnssec -status '. From that 
point on it should be safe to make policy configuration changes, such as 
algorithm rolls, and old keys are phased out smoothly.


I am thinking of adding an additional safety mechanism during migration, 
because you are not the first one to do this.


Best regards,
  Matthijs






Best regards, Adrian.


Log of successful change from auto-dnssec to dnssec-policy (using the same
algo):
2023-12-28 11:53:00: zone myzone.ch/IN (signed): generated salt: [...]
2023-12-28 11:53:00: zone myzone.ch/IN (signed): checkds: set 4 parentals
2023-12-28 11:53:01: zone myzone.ch/IN (signed): zone_addnsec3chain(1,CREATE,
32,[...])
2023-12-28 11:53:01: zone myzone.ch/IN (signed): reconfiguring zone keys
2023-12-28 11:53:01: keymgr: DNSKEY myzone.ch/ECDSAP256SHA256/50817 (ZSK)
created for policy mypolicy_ecdsa
2023-12-28 11:53:01: Permissions on the file /var/lib/bind/keys/Kmyzone.ch.
+013+61287.private have changed from 0640 to 0600 as a result of this
operation.
2023-12-28 11:53:01: Permissions on the file /var/lib/bind/keys/Kmyzone.ch.
+013+38348.private have changed from 0640 to 0600 as a result of this
operation.
2023-12-28 11:53:01: Fetching myzone.ch/ECDSAP256SHA256/50817 (ZSK) from key
repository.
2023-12-28 11:53:01: Key myzone.ch/ECDSAP256SHA256/50817: Delaying activation
to match the DNSKEY TTL (86400).
2023-12-28 11:53:01: DNSKEY myzone.ch/ECDSAP256SHA256/50817 (ZSK) is now
published
2023-12-28 11:53:01: DNSKEY myzone.ch/ECDSAP256SHA256/50817 (ZSK) is now
active
2023-12-28 11:53:01: CDS for key myzone.ch/ECDSAP256SHA256/61287 is now
published
2023-12-28 11:53:01: CDNSKEY for key myzone.ch/ECDSAP256SHA256/61287 is now
published
2023-12-28 11:53:01: zone myzone.ch/IN (signed): next key event: 28-Dec-2023
12:53:01.176
2023-12-28 11:53:01: zone myzone.ch/IN (signed): sending notifies (serial
2021010692)



--
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: Problem upgrading to 9.18 - important feature being removed

[Matthijs Mekking]

As the main developer of dnssec-policy, I would like to confirm that 
what has been said by Michael and Nick are correct.


I will repeat the most important takeaways:

- Setting the lifetime to unlimited on keys and BIND will never roll 
your keys automatically.


- Most issues that were shared on this list have to do with migrating to 
dnssec-policy.


- When migrating to dnssec-policy, make sure the configuration matches 
your existing keys.


- Make sure the migration is complete by checking that all states are in 
'omnipresent' (with 'rndc dnssec -status ').


- If you feel like the DS is stuck in 'rumoured' state you might need to 
run 'rndc dnssec -checkds seen' on the key.


- It is not recommended to switch to dnssec-policy if you are currently 
in a rollover.


I acknowledge that migration takes some care and I wish the process was 
easier. We have some ideas to make it less error prone, but I haven't 
found the time to work on that.


On the more positive side, we haven't heard

Thanks to all for switching to dnssec-policy and reporting issues.

Best regards,

Matthijs


On 2/27/24 07:01, Nick Tait via bind-users wrote:

On 27/02/2024 13:22, Michael Sinatra wrote:

On 2/26/24 13:41, Al Whaley wrote:
Originally (under the above command) RR records for DNSSEC were 
maintained by bind, but the ZSK and KSK keys were maintained by me.  
This command is being discarded.  I understand that bind "sort of" 
supports this feature in 9.18 by allowing the DNSSEC policy statement 
to declare unlimited lifetime, but after careful reading of the 
documentation and reading a number of complaints, it turns out that 
bind may under various circumstances decide that it is appropriate 
not to use existing keys and decide that it knows best, and then it 
makes new ones.  This potential instability of course would be 
disastrous, and completely unnecessary.


I have never experienced this, in either BIND 9.16 or BIND 9.18 
(including the latter with KASP set to not rotate any keys).  Can you 
elaborate as to where in the documentation and/or what complaints you 
have seen where correctly configured KASPs in 9.18.24+ decide to roll 
keys?  I'd certainly like to know if that's the case, for reasons 
described below. 


The only example that I can recall (from this list) where this type of 
thing happened was where someone specified a different algorithm when 
transitioning to dnssec-policy. The advice for this type of situation is 
to transition to dnssec-policy with the same algorithm first, and make 
sure everything in your state files is "omnipresent", and only then 
update the dnssec-policy to use a different algorithm.


My (somewhat uneducated) advice would also be to avoid 
implementing dnssec-policy if you were in the middle of a key roll-over. 
Not because I think it would necessarily create a problem, but more to 
reduce risk and make it easier to verify that nothing untoward has happened.


In other words, if you aren't in the middle of a roll-over, and your 
current keys don't have any expiration set, then you can reconfigure 
your zone to use a dnssec-policy that specifies the same algorithm as 
what you previously had, and BIND should be happy to carry on using the 
existing keys -- indefinitely if you've specified an unlimited lifetime. 
The only difference you should notice is that after 
implementing dnssec-policy there are additional *.state files in your 
keys directory.


The only other thing I'd add is that if (after transitioning 
to dnssec-policy) you do initiate a manual roll-over, keep an eye on 
your state files to verify that the new key becomes "omnipresent". This 
can take much longer than you might expect! For ZSK roll-overs don't be 
surprised if it takes 9-10 days. Also FYI for KSK (and CSK) roll-overs, 
you may need to run rndc commands to tell BIND when DS records are 
added/removed -- but that is possibly what you already do with auto-dnssec?


Of course in life there are no absolute guarantees, so you should back 
up your configuration and make a plan to mitigate the impacts in the 
event that everything turns pear-shaped?


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: Problem upgrading to 9.18 - important feature being removed

[Matthijs Mekking]

On 2/27/24 19:35, Michael Richardson wrote:


Matthijs Mekking  wrote:
 > As the main developer of dnssec-policy, I would like to confirm that
 > what has been said by Michael and Nick are correct.

Cool.

 > - When migrating to dnssec-policy, make sure the configuration matches
 > your existing keys.

Is there a way to validate the policy against what's in a specific 
zone/directory?
Effectively, "do your key management stuff --just-kidding --verbose"?


There is nothing like that today.


 > - Most issues that were shared on this list have to do with migrating
 > to dnssec-policy.

Agreed: and it bit me, and I am still a bit shell shocked.

 > - If you feel like the DS is stuck in 'rumoured' state you might need
 > to run 'rndc dnssec -checkds seen' on the key.

okay, good to know this.
. o O ( Umbrella Academy )

 > - It is not recommended to switch to dnssec-policy if you are currently
 > in a rollover.

 > I acknowledge that migration takes some care and I wish the process was
 > easier. We have some ideas to make it less error prone, but I haven't
 > found the time to work on that.

Are there open issues?


So far this were only ideas and not turned into gitlab issues, but 
things that I have been considering is a check to see if migration is 
complete (that would prevent any other policy changes), a 
named-checkconf option to see if the dnssec-policy configuration matches 
the existing key-directory.


Carsten created an issue for dry-running a migration:

https://gitlab.isc.org/isc-projects/bind9/-/issues/4606
--
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: Problem upgrading to 9.18 - important feature being removed

[Matthijs Mekking]

On 3/1/24 12:23, G.W. Haywood wrote:

Hi there,

On Fri, 1 Mar 2024, Ond?ej Sur? wrote:

On 26. 2. 2024, at 22:41, Al Whaley wrote:

> A lot of pain and suffering in this world comes from people being
> sure they have a 'better idea' and everybody needs to do whatever.
> This feels a bit like that. ...

... ultimately, the developers working on BIND 9 are just a few
people and it's absolutely reasonable to remove rarely used features
- especially if there's a replacement ...

For every decision we make, be it adding a new feature or removing
an old feature, we do carefully consider the implications ...


And in this case I think it would be unfair to the developers not to
mention that more than two years ago, before actually implementing
this change, the developers did ask for comment and there was debate.
If the OP took a part in that debate I missed it.


See here for the FYI: 
https://lists.isc.org/mailman/htdig/bind-users/2022-November/106948.html


In short, we said we would go forward with the deprecation, despite key 
creation in HSM's was not yet supported (it will be in 9.20, already 
merged in our development release).


There is functional parity, everything you do with auto-dnssec can also 
be done with dnssec-policy. If you don't want to do automatic key 
rollovers, use 'lifetime unlimited' on keys.


There is a section on manual key rollover in our kb article: 
https://kb.isc.org/docs/dnssec-key-and-signing-policy


- Matthijs





8<------
Date: Tue, 10 Aug 2021 10:02:59 +0200
From: Matthijs Mekking 
To: bind-users@lists.isc.org
Subject: Deprecating auto-dnssec and inline-signing in 9.18+
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

Hi users,

We are planning to deprecate the options 'auto-dnssec' and 
'inline-signing' in BIND 9.18. The reason for this is because 
'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.


Deprecating means that you can still use the options in 9.18, but a 
warning will be logged and it is very likely that the options will be 
removed in BIND 9.20.


We would like to encourage you to change your configurations to 
'dnssec-policy'. See this KB article for migration help:


  https://kb.isc.org/docs/dnssec-key-and-signing-policy

Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' 
configurations? Is there a use case that is not (yet) covered by 
'dnssec-policy'? Any other concerns? Please let us know.

8<--

To try to make this more positive, Maybe the lesson here is that if
you're using BIND other than because it happened to come with your
distro, then it's probably a good idea to keep an eye on this list to
monitor the plans for development.  If it says that in the ARM, which
IMO it probably should, I missed that too.


--
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: Problem upgrading to 9.18 - important feature being removed

[Matthijs Mekking]

slow down 
conversions from older algorithms to new ones.


My main point here is that I am not just trying to get bind to not 'time 
out' my keys (with 'lifetime unlimited'), I am trying to prevent it from 
deciding my keys don't meet 'current standards' and make new ones.  As 
far as I know, there's no way to do that.


It does, until you make configuration changes to the dnssec-policy. So 
it will never do that on its own.



I am sorry, but so far I have heard nothing that disputes the functional 
parity with 'auto-dnssec'.



Best regards,

Matthijs



regards

Al

On 3/4/2024 06:05, Matthijs Mekking wrote:



On 3/1/24 12:23, G.W. Haywood wrote:

Hi there,

On Fri, 1 Mar 2024, Ond?ej Sur? wrote:

On 26. 2. 2024, at 22:41, Al Whaley wrote:

> A lot of pain and suffering in this world comes from people being
> sure they have a 'better idea' and everybody needs to do whatever.
> This feels a bit like that. ...

... ultimately, the developers working on BIND 9 are just a few
people and it's absolutely reasonable to remove rarely used features
- especially if there's a replacement ...

For every decision we make, be it adding a new feature or removing
an old feature, we do carefully consider the implications ...


And in this case I think it would be unfair to the developers not to
mention that more than two years ago, before actually implementing
this change, the developers did ask for comment and there was debate.
If the OP took a part in that debate I missed it.


See here for the FYI: 
https://lists.isc.org/mailman/htdig/bind-users/2022-November/106948.html


In short, we said we would go forward with the deprecation, despite 
key creation in HSM's was not yet supported (it will be in 9.20, 
already merged in our development release).


There is functional parity, everything you do with auto-dnssec can 
also be done with dnssec-policy. If you don't want to do automatic key 
rollovers, use 'lifetime unlimited' on keys.


There is a section on manual key rollover in our kb article: 
https://kb.isc.org/docs/dnssec-key-and-signing-policy


- Matthijs





8<--
Date: Tue, 10 Aug 2021 10:02:59 +0200
From: Matthijs Mekking 
To: bind-users@lists.isc.org
Subject: Deprecating auto-dnssec and inline-signing in 9.18+
Message-ID: 
Content-Type: text/plain; charset=utf-8; format=flowed

Hi users,

We are planning to deprecate the options 'auto-dnssec' and 
'inline-signing' in BIND 9.18. The reason for this is because 
'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.


Deprecating means that you can still use the options in 9.18, but a 
warning will be logged and it is very likely that the options will be 
removed in BIND 9.20.


We would like to encourage you to change your configurations to 
'dnssec-policy'. See this KB article for migration help:


  https://kb.isc.org/docs/dnssec-key-and-signing-policy

Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' 
configurations? Is there a use case that is not (yet) covered by 
'dnssec-policy'? Any other concerns? Please let us know.

8<--

To try to make this more positive, Maybe the lesson here is that if
you're using BIND other than because it happened to come with your
distro, then it's probably a good idea to keep an eye on this list to
monitor the plans for development.  If it says that in the ARM, which
IMO it probably should, I missed that too.


--
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] testing KASP

[Matthijs Mekking]

Hi,

On 5/16/24 14:02, adrien sipasseuth wrote:

Hello,

I try to set up a testing environment in order to create some scripts 
for automated the roll over KSK.


# question 1 #
this is my policy :

dnssec-policy "test" {
     keys {
     ksk lifetime P3D algorithm ecdsa256 2048;
     zsk lifetime P1D algorithm ecdsa256 2048;
     };

     // Key timings
     purge-keys P4D;

     // Signature timings
     signatures-refresh  PT50M;
     signatures-validity PT1H;
     signatures-validity-dnskey PT1H;

     // Zone parameters
     max-zone-ttl PT1H;
     parent-ds-ttl PT1H;

};

I would like automaticly update new DS to my registar, to do it this my 
logic :


For each file en .state
     If is KSK with "DSState: rumoured" or "DSState: hidden"
         If not in my registar (dig ds  +dnssec +multiline)
             Publish on my Registar(api register)
             Notify Bind(bind rndc dnssec -checkds -key  published 
)


Only if KSK has DSState: rumoured. If the DSState is hidden it means 
that it is not expected to be in the parent (for example because the 
DNSKEY has not yet been fully propagated).




Do y need to withdraw the old key too immediatly ? anything else to do ?


Do you mean withdraw the old DS?

I would use similar logic but then use "unretentive" instead of 
"rumoured". Following the example above:


For each file en .state
  If is KSK with "DSState: unretentive"
  If in my registar (dig ds  +dnssec +multiline)
  Withdraw on my Registar(api register)
  Notify Bind(bind rndc dnssec -checkds -key  withdrawn



# question 2 #
If i want to unsigned a zone, i change my policy to "insecure" which is 
default but file like .signed still exist, Bind doesn't remove it ?


Correct. If all DNSSEC records have been removed, it is safe to remove 
the "dnssec-policy" configuration from your named.conf and then remove 
the .signed file.


Unsigning your zone also takes time.



# question 3 #

In state file, when the remove date issue, can i just remove the key, 
anything else to do ?


When all states are "hidden" it is safe to remove the key.

Best regards,

Matthijs



Regards,
Adrien SIPASSEUTH




--
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: checkds - min. version for this ?

[Matthijs Mekking]

On 7/18/24 15:53, vom513 wrote:

Hello all,

I could have sworn I saw mention on this list at some point of this (just can’t 
find it in the archives).

I currently run a 9.18.x BIND and I use parental agents for automatic key 
rollover.  I have a script that builds these and I included them in my config.

 From what I read on:

https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-checkds

The “checkds” statement, if set to yes, will simply look at the parent NSes 
with no need to create/maintain the parental-agents list.

Is this correct ?  And also - what version of BIND was this first introduced 
(seems like something 9.19.x ?) ?


Correct. The "checkds" option was introduced in 9.19.12.

Best regards,

Matthijs


My current setup is fine for me - but if there is a more elegant/native way of 
doing it in the future I’d want to do that vs. reinventing the wheel.

Thanks.

--
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: Deleting a key

[Matthijs Mekking]

Hi Casey,

Don't muck around with dnssec-settime. As Peter mentioned earlier, your 
key seems to be in rollover, awaiting DS publication. I'll repeat what 
he said:


  The DS for the new key is only rumored. If you have seen the DS in the
  parent, tell BIND so:

  rndc dnssec -checkds -key 48266 published
  rndc dnssec -checkds -key 50277 withdrawn

Alternatively, you can configure "checkds yes" for your zone, and BIND 
will check the DS at the parent and continue rollover automatically.


Best regards,

Matthijs

On 8/7/24 08:02, Casey Deccio wrote:

Hi all,

I'm probably missing something obvious here, but I'm trying to figure 
out how to "delete" a DNSKEY from zone that uses inline signing.  The 
zone statement looks like this:


zone "dns-lab.info" {
type master;
file "/var/cache/bind/db.dns-lab.info";
dnssec-policy alg8;
inline-signing yes;
};

This is the current state:

https://dnsviz.net/d/dns-lab.info/ZrMLNw/dnssec/ 



Or:

$ sudo rndc dnssec -status dns-lab.info
dnssec-policy: alg8
current time:  Tue Aug  6 23:48:14 2024

key: 50277 (ECDSAP256SHA256), CSK
   published:      yes - since Thu Oct 19 09:59:06 2023
   key signing:    yes - since Thu Oct 19 09:59:06 2023
   zone signing:   yes - since Thu Oct 19 09:59:06 2023

   Rollover is due since Thu Oct 26 16:11:03 2023
   - goal:           hidden
   - dnskey:         omnipresent
   - ds:             unretentive
   - zone rrsig:     omnipresent
   - key rrsig:      omnipresent

key: 48266 (RSASHA256), CSK
   published:      yes - since Thu Oct 26 16:11:03 2023
   key signing:    yes - since Thu Oct 26 16:11:03 2023
   zone signing:   yes - since Thu Oct 26 16:11:03 2023

   No rollover scheduled
   - goal:           omnipresent
   - dnskey:         omnipresent
   - ds:             rumoured
   - zone rrsig:     omnipresent
   - key rrsig:      omnipresent

Note that keys with two DNSSEC algorithms are in the zone, which might 
be complicating things... ?


Now I use dnssec-settime to give key 50277 a "delete date":

$ sudo -u bind dnssec-settime -D+5mi 
/var/cache/bind/Kdns-lab.info.+013+50277.

/var/cache/bind/Kdns-lab.info.+013+50277.key
/var/cache/bind/Kdns-lab.info.+013+50277.private

It seems to work:

$ sudo cat /var/cache/bind/Kdns-lab.info.+013+50277.key | grep Delete
; Delete: 20240807054556 (Tue Aug  6 23:45:56 2024)

$ sudo /etc/init.d/named reload
Reloading named configuration (via systemctl): named.service.

I'm not really sure what the following lines mean in the log because 
they don't seem to correspond to the times in the key file.


$ sudo tail -100 /var/log/syslog | grep key
2024-08-06T23:41:10.353023-06:00 bass named[216234]: zone 
dns-lab.info/IN/authoritative-only (signed): reconfiguring zone keys
2024-08-06T23:41:10.356705-06:00 bass named[216234]: keymgr: retire 
DNSKEY dns-lab.info/ECDSAP256SHA256/50277 (CSK)
2024-08-06T23:41:10.356888-06:00 bass named[216234]: zone 
dns-lab.info/IN/authoritative-only (signed): next key event: 07-Aug-2024 
00:41:10.345


However, nothing ever changes with key 50277. I've done all this 
multiple times over several days. It continues to sign records when I 
add records to the zone.  If someone has ideas to point me in the right 
direction, that would be great.


$ /usr/sbin/named -v
BIND 9.18.28-1~deb12u2-Debian (Extended Support Version) 


Thanks,
Casey


--
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-policy & views

[Matthijs Mekking]

Hi Graham,

On 2/29/20 5:27 PM, Graham Clinch wrote:
> How does the new-in-9.16 dnssec-policy interact with views - in
> particular for key generation/rollover?
> 
> For example, we have a zone defined in multiple views with different
> contents (and thus not suitable for in-view), being signed by the same
> set of keys (currently maintained by dnssec-keymgr) - this allows us to
> publish only a single set of DS records for that zone.
> 
> If a zone 'example.net' is defined in view 'a', and a zone 'example.net'
> is defined in view 'b', but both views share a single key-directory, is
> it 'safe' to configure dnssec-policy in both views?

Thanks for sharing your use case. I tried it and it is unsafe to do so
in 9.16.0.

The dnssec-policy does not take into account shared keys. But with views
you sort of implicitly have shared keys because you have multiple
versions of the zone. In the current code there is a race condition on
running key management on the different versions of the zone which may
result in too many keys.

I created an issue for this bug:

https://gitlab.isc.org/isc-projects/bind9/issues/1653

And I have a proposed fix for it. It may make the 9.16.1 release,
otherwise 9.16.2. With this fix you should be able to safely configure
dnssec-policy for a zone in multiple views, sharing the same set of keys.

Best regards,

Matthijs


> 
> Graham
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Non-disruptive migration to dnssec-policy possible?

[Matthijs Mekking]

Hi Håkan,

First of all, thanks for trying out the new dnssec-policy feature.

I'll admit there is insufficient documentation and tooling around
migration to dnssec-policy, possibly there is a bug too.

Existing keys do not have a .state file, and so named will try to match
those keys with the policy by looking at the data in the .key and
.private files. However, perhaps some metadata is different? If so the
keys don't match the policy and named will try to replace them (I
suspect the DNSKEY TTL is different).

You can use the dnssec-settime tool to write the state file, but it is
more intended to be a method for debugging and testing.

It is odd that it immediately deletes the existing keys. I would like to
follow-up on this. Would you be able to rerun the experiment with the
dnssec log category set to debug? That way we can see what the internal
keymgr decided about those keys.

If so, could you create an issue for it on our GitLab repository?

https://gitlab.isc.org/isc-projects/bind9/

There exists a system test that tests this case and it passes, so either
or test is wrong, or your setup uncovers a scenario we did not anticipate.

Thanks for reporting, best regards,

Matthijs

On 3/25/20 12:53 PM, Håkan Lindqvist via bind-users wrote:
> Hello,
> 
> I have seen essentially this same question/problem posed by others in
> other forums but never seen any proper answers to it.
> I have now tried this myself with BIND 9.16.1 and faced the exact same
> issue that I had previously read about.
> 
> How does one migrate an already signed zone from "auto-dnssec maintain"
> to "dnssec-policy x" in a non-disruptive manner?
> 
> The manual
> (https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/Bv9ARM.ch05.html#dnssec_policy_grammar)
> does not appear to cover this this scenario and the DNSSEC Guide
> (https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html) does not
> mention dnssec-policy at all.
> 
> However, the wiki
> (https://gitlab.isc.org/isc-projects/bind9/-/wikis/DNSSEC-Key-and-Signing-Policy-(KASP)#key-generation)
> appears to suggest that existing keys would be picked up.
> 
> With that in mind, one might naively think that switching to a
> keytype-compatible dnssec-policy should be safe, but in practice it
> appears to be anything but.
> 
> Eg existing KSK+ZSK algo 13 keys seem like they could (and arguably
> should) be carried over to a policy mandating KSK+ZSK and algo 13
> (particularly if the policy has unlimited lifetime for the key, but even
> with limited lifetime one would hope that the regular rollover timers
> would be applied).
> 
> In practice when you change the zone configuration to use dnssec-policy,
> all existing keys are immediately yanked and replaced with new keys. No
> timers or anything seem to matter.
> 
> 
> This is what my own test looked like:
> 
> Existing  KSK+ZSK keys with only these timings present in the .key files:
> 
> Created:
> Publish:
> Activate:
> 
> And a policy like this (named to reflect what is what while testing):
> 
> dnssec-policy alg13-ksk-unlimited-zsk-60day {
>     keys {
>     ksk key-directory lifetime unlimited algorithm ECDSAP256SHA256;
>     zsk key-directory lifetime P60D algorithm ECDSAP256SHA256;
>     };
> };
> 
> And this is the log output when first loading BIND after changing the
> configuration to use that dnssec-policy:
> 
> zone zone.example/IN (signed): reconfiguring zone keys
> keymgr: DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) created for
> policy alg13-ksk-unlimited-zsk-60day
> keymgr: DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) created for
> policy alg13-ksk-unlimited-zsk-60day
> Removing expired key 20481/ECDSAP256SHA256 from DNSKEY RRset.
> DNSKEY zone.example/ECDSAP256SHA256/20481 (ZSK) is now deleted
> Removing expired key 12506/ECDSAP256SHA256 from DNSKEY RRset.
> DNSKEY zone.example/ECDSAP256SHA256/12506 (KSK) is now deleted
> Fetching zone.example/ECDSAP256SHA256/49004 (KSK) from key repository.
> DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now published
> DNSKEY zone.example/ECDSAP256SHA256/49004 (KSK) is now active
> Fetching zone.example/ECDSAP256SHA256/54646 (ZSK) from key repository.
> DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now published
> DNSKEY zone.example/ECDSAP256SHA256/54646 (ZSK) is now active
> zone zone.example/IN (signed): next key event: 22-Mar-2020 15:08:19.805
> 
> As can be seen, it immediately deleted the existing keys, claiming that
> they were "expired".
> 
> One could argue that the ZSK certainly was old enough to be expired
> (even though I would still maintain that it must do a proper rollover
> starting from now rather than just yanking the key), but the KSK policy
> was "lifetime unlimited" and nothing about end of life in the existing
> .key file. How can such a key even be "expired"?
> 
> I did notice that the key files (both old and new) also got a
> corresponding .state file created as part of this process. Is that
> relevant to the problem?
> Ie, do existing k

Re: Non-disruptive migration to dnssec-policy possible?

[Matthijs Mekking]

Hi Shumon,

The "NOT IMPLEMENTED YET" is still accurate. It means that if you use
dnssec-policy, your zones will be signed with NSEC. Any attempts to make
it work with NSEC3 (with Dynamic Update for example) have undefined
behavior.

You are right that at this moment dnssec-policy is not yet suitable for
your use case. We will implement NSEC3 for dnssec-policy in 9.17 and
backport it to 9.16.

Best regards,

Matthijs

On 3/25/20 8:50 PM, Shumon Huque wrote:
> On Wed, Mar 25, 2020 at 9:04 AM Matthijs Mekking  <mailto:matth...@isc.org>> wrote:
> 
> Hi Håkan,
> 
> First of all, thanks for trying out the new dnssec-policy feature.
> 
> I'll admit there is insufficient documentation and tooling around
> migration to dnssec-policy, possibly there is a bug too.
> 
> [...]
> 
> HI Matthijs,
> 
> We are just starting to look at 9.16.x also, and are considering what it
> would take to move our current "auto-dnssec maintain" configuration to
> the new dnssec-policy feature.
> 
> We use NSEC3 though, and from your wiki, I see the following:
> 
> " Currently if you want to sign your zone with NSEC3 you can do so by
> introducing
> an NSEC3PARAM record via Dynamic Update. This is no longer necessary with
> dnssec-policy as you can configure NSEC3 usage in named.conf (NOT
> IMPLEMENTED YET)."
> 
> Is the "NOT IMPLEMENTED YET" still accurate? And if accurate, can you
> elaborate on what that means? e.g. NSEC3 zones don't work at all? NSEC3
> zones can be generated and served, but NSEC3 parameters cannot be
> managed/rolled? Or something else?
> 
> If the latter, I was wondering if it is possible to combine pieces of
> the old and new ways, e.g. pre-configure an unsigned zone with an NSEC3
> param using dynamic update or "rndc signing -nsec3param", and also use
> dnssec-policy to allow for maintenance of the DNSSEC keys? Our
> requirement though is that the signed zone needs to be NSEC3 out of the
> gate. At first glance, if I'm understanding the new configuration
> statements, that doesn't seem possible.
> 
> Thanks!
> Shumon Huque.
> 



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Non-disruptive migration to dnssec-policy possible?

[Matthijs Mekking]

To follow-up,

Migration from existing keys to dnssec-policy was indeed not working
properly, because the internal key states were not initialized properly.
Key states were always initialized as "HIDDEN" and that is why the
keymgr thought it could delete those keys immediately.

The fix is to look more closely at key timing metadata and set the
internal key state appropriately.

This is fixed in the upcoming 9.16.2 release.

Best regards,

Matthijs

On 3/26/20 8:34 PM, Håkan Lindqvist wrote:
> I reported a bug with the requested details:
> https://gitlab.isc.org/isc-projects/bind9/issues/1706
> 
> 
> A related thing that I've noticed in my tests is that "dnssec-policy x"
> seems to also imply "inline-signing yes"?
> Is this intended as a strict requirement, it seems a little awkward?
> 
> On that note, combining "dnssec-policy x" with "inline-signing no" does
> not seem to be handled gracefully.
> This makes me suspect that it's not an intended scenario, is that correct?
> 
> 
> /Håkan
> 
> On 2020-03-25 16:57, Håkan Lindqvist via bind-users wrote:
>> On 2020-03-25 14:03, Matthijs Mekking wrote:
>>> Existing keys do not have a .state file, and so named will try to match
>>> those keys with the policy by looking at the data in the .key and
>>> .private files. However, perhaps some metadata is different? If so the
>>> keys don't match the policy and named will try to replace them (I
>>> suspect the DNSKEY TTL is different).
>>
>> Looking at the .key files, I can confirm that the old files (created
>> by dnssec-keygen) omit the TTL field, while the new .key files have a
>> 3600 TTL specified.
>>
>> I suppose that the dnssec-keygen output depends on whether the -L
>> option was used or not (based on this, I would guess that it's quite
>> common to have .key files with no TTL in the wild).
>>
>>
>>> You can use the dnssec-settime tool to write the state file, but it is
>>> more intended to be a method for debugging and testing.
>>
>> Ok. No, I don't particularly want the .state files, it was just a
>> question of whether they were expected/needed ahead of time.
>>
>>
>>> It is odd that it immediately deletes the existing keys. I would like to
>>> follow-up on this. Would you be able to rerun the experiment with the
>>> dnssec log category set to debug? That way we can see what the internal
>>> keymgr decided about those keys.
>>>
>>> If so, could you create an issue for it on our GitLab repository?
>>>
>>>  https://gitlab.isc.org/isc-projects/bind9/
>>
>> Ok, I will try this and report back. (Also whether adding a TTL to the
>> .key file avoids the problem)
>>
>>
>> /Håkan
>>
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Full automatic DNSSEC for hosted zones/domains

[Matthijs Mekking]

Hi Matthias,

The answer is almost, as long as the zone has a DNSSEC policy configured:

zone "newdomain.de" {
   type master;
   file "../master/newdomain.de";
   dnssec-policy default;
}

The only thing not yet fully automated is submitting the DS to the
parent. You can do that as soon as named puts the CDS/CDNSKEY records in
the zone.

Best regards,
Matthijs

On 4/7/20 10:55 AM, Matthias Fechner wrote:
> Dear all,
> 
> is bind (version 9.16.1) able to do all DNSSEC required steps fully by
> itself.
> 
> So I only create a new zone for a domain and include it like for
> newdomain.de:
> zone "newdomain.de" {
>   type master;
>   file "../master/newdomain.de";
>   ...
> }
> 
> After bind was reloaded/restarted, it automatically creates the required
> keys and fully maintain the zone, do key rollover, everything required
> fully by itself?
> 
> Gruß
> Matthias
> 



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Full automatic DNSSEC for hosted zones/domains

[Matthijs Mekking]

Hi Philippe,

On 4/7/20 3:46 PM, Philippe Maechler wrote:
> Hello bind users
> 
>> The answer is almost, as long as the zone has a DNSSEC policy configured:
>>
>> zone "newdomain.de" {
>>   type master;
>>   file "../master/newdomain.de";
>>   dnssec-policy default;
>> }
>>
>> The only thing not yet fully automated is submitting the DS to the
>> parent. You can do that as soon as named puts the CDS/CDNSKEY records in
>> the zone.
> 
> So you're saying, that with a DNSSEC policy configured, bind is creating CDS 
> records for me? If so, then when my registrar is supporting those records 
> (switch.ch), this zone fully automated in regards of DNSSEC?
> Is the creation of CDS Records a config option or on by default?

Yes, that is right. The creation of CDS and CDNSKEY records happens
always and cannot be turned off with an option.


> What about going from secure to insecure? Is this possible with dnssec policy 
> or do I then have to put the relevant CDS records in the zone by hand?

This is not possible yet with dnssec-policy. I suggest to put the
deletion CDS record in the zone, set dnssec-policy to none, and
dnssec-signzone your zone temporarily.

Best regards,

Matthijs


> 
> Best regards
> Philippe
> 
> 



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: CDS/CDNSKEY are not published with BIND-9.16.1 and dnssec-policies

[Matthijs Mekking]

Hi Tom,

Because you just started signing your zone. The DNSKEY and RRSIG records 
are published but have to wait a TTL time to before the DS may be 
published, to avoid a situation where a resolver fetches the DS but 
still has the corresponding DNSKEY query in the negative cache.


This time is based on the dnskey-ttl (60 seconds), publish-safety (1 
hour), max-zone-ttl (1 day) and zone-propagation-delay (300 seconds).


- publish-safety is an additional wait period before continuing a key
  roll, to allow some time to react on unforeseen events.
- max-zone-ttl should be set to your maximum used TTL in the zone. In
  the future we may add the functionality to walk the zone and determine
  the max-zone-ttl.
- zone-propagation-delay is an additional wait period to cover for the
  time it takes between changes and actual publication.

All these values are there to be extra careful on key rollover timings. 
You can lower these values in the dnssec-policy to speed up the process 
for your test zone, or tweak them to better match your setup.


Best regards,

Matthijs

On 09-04-2020 08:27, Tom wrote:

Hi
Using BIND-9.16.1.
In the last ISC dnssec webinar 
(https://www.youtube.com/watch?v=2aB__FZZQ84) I heared, that CDS/CDNSKEY 
records automatically should be published when using dnssec-policies.


My policy looks like this:
dnssec-policy "test-policy" {
 dnskey-ttl 60;
 keys {
     ksk lifetime unlimited algorithm ecdsa256;
     zsk lifetime unlimited algorithm ecdsa256;
 };
};

and the zone like this:
zone "example.com" {
     type master;
     file "master/example.com.zone";
     key-directory "/etc/named/keys/example.com";
 dnssec-policy "test-policy";
};


When digging this zone for CDS/CDNSKEY records, then these keys are not 
existing:

$ dig +norec +noall +answer @127.0.0.1 cds example.com
$ dig +norec +noall +answer @127.0.0.1 cdnskey example.com

The keyfile for "example.com" also do not show a "published"-date:
$ cat Kexample.com.+013+02624.key
; This is a key-signing key, keyid 2624, for example.com.
; Created: 20200409061638 (Thu Apr  9 08:16:38 2020)
; Publish: 20200409061638 (Thu Apr  9 08:16:38 2020)
; Activate: 20200409061638 (Thu Apr  9 08:16:38 2020)
example.com. 60 IN DNSKEY 257 3 13 
uV/NtPZSL1fmO3FAi4pZCcbTl19iD3SizgVcDXGJEl1g4l/cHUGvVl33 
3cx2cODA6RUj55pZa77g1VBtFBXByg==



Any hints, why in this case the dnssec-policy mechanism doesn't publish 
the CDS/CDNSKEY records?


Many thanks.

Kind regards,
Tom
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND-9.16.1 & KASP

[Matthijs Mekking]

Mark,

On 4/13/20 8:54 PM, Evan Hunt wrote:
> On Mon, Apr 13, 2020 at 02:22:53PM +0200, Mark Elkins wrote:
>> Question - What are the "TYPE65534" records? What are they saying? I am 
>> using "DiG 9.16.1" so surprised it doesn't know.
> 
> This is a mechanism named uses to keep track of the status of zone
> signing operations, so that if there's a crash or power outage before
> signing is complete, it'll know which step it needs to resume on. To
> see the status in a human-readable form, use "rndc signing -list ".
> If it says signing is complete, you're free to remove the records
> with "rndc signing -clear all ".
> 
>> My zones '$TTL' is 1200... so I would have thought the CDS record would 
>> have appeared by now.
>> I "signed" the zone at Apr 12 21:27 +02:00 and its now 16 hours later. I 
>> thought the biggest delay factor is the zones $TTL, often set to one day.
> 
> I'm... not sure CDS is published automaitcally yet. I'd have to check to be
> sure, but I think that's coming in a future release.

If you sign your zone for the first time, named needs to make sure the
DNSKEY and RRSIG records are long enough in the zone such that if a
resolver is able to fetch the DS, it must also be able to fetch the
corresponding DNSKEY and RRSIG records. Only then the CDS is published
indicating it is safe to submit the DS record.

This time is the the maximum zone TTL, zone propagation delay, and
publish safety time. The dnssec-policy does not yet look into the zone
for the maximum TTL but derives it from configuration. The default
policy sets the maximum zone TTL to 1 day. Together with  the zone
propagation delay and publish safety delay from the default policy this
is a 25 hour and 5 minute wait before the CDS is published.

Obviously you can change your policy to lower the maximum-zone-ttl to
1200 in your case (and if you don't care about a publish safety period,
you can set it to 0 seconds).

>> Looks like the SOA Serial Number still needs to be maintained manually. 
>> Was expecting a more OpenDNSSEC approach. Would love an automated 
>> MMDDxx number - date it was last 'modified'. Would be perfect for 
>> small zones that are rarely updated.

> I think the zone option "serial-update-method date;" does this. (I haven't
> tested it with dnssec-policy though.)

Despite the documentation says this is for dynamic DNS zones, this also
works for inline-signing and dnssec-policy zones.

- Matthijs



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: VS: Change DNSSEC algorithm and switch to use KASP

[Matthijs Mekking]

Hi,

If you want to switch to KASP with the a different algorithm, you should 
be able to use BIND 9.16.2 and just reconfigure your zone to use 
"dnssec-policy".  The existing keys will be removed in a timely manner, 
while named creates new keys with the new algorithm.


Make sure you will submit the DS to your parent once the new CDS/CDNSKEY 
record is published in your zone.


Best regards,

Matthijs

On 25-04-2020 22:28, Jukka Pakkanen wrote:

I just did the same operation in our BIND servers, converted all DNSSEC enabled 
zones with different algorithms to KASP/dnssec-policy and ecdsa256/13.

All I did was replaced the two lines in named.conf:

 inline-signing yes;
 auto-dnssec maintain;

to

dnssec-policy "ecdsa256";

And of course created the policy there too.

If the algorithm in the zone was changed (previously something else than "13"), 
updated the DS record at the registrar as well.

Worked out smoothly, ok there was a brief moment before the new DS was 
published and zone secured again, but did this at night time, at the morning 
everything was perfect, and now all zones using that policy.

Jukka


-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta Matthias 
Fechner
Lähetetty: 25. huhtikuuta 2020 10:08
Vastaanottaja: bind-users@lists.isc.org
Aihe: Change DNSSEC algorithm and switch to use KASP

Dear all,

I followed now the series here (again, thanks a lot to make this public!):
https://www.youtube.com/watch?v=MheHMWCOTvE&list=PLUwyH0o3uuICgnbQj_lQajRI_CzewZr7q

Just now I only sign one domain which is using the "auto-dnssec maintain;".
What I understood from the series is that KASP does not support switching from 
"auto-dnssec maintain" to KASP, yet.

As my single domain is using RSASHA256 and I want to use one algorithm
(ECDSA256)  for each domain I maintain in my DNS servers (to would like to have 
a clean start with KASP).
I just wanted to make sure I do not break this single domain
(fechner.net) which is already signed.
I cannot remove DNSSEC before the DS has disappeared on the parent.

What I understood so far is using the following procedure (to disable DNSSEC 
for this single specific domain):
- ask the parent zone to remove the DS (as long as the DS exists in the parent 
zone I must not remove DNSSEC as that would break the zone)
- after the DS disappeared in the parent zone, wait for at least the TTL of the 
DS (86400) + maybe one day (safety)
- now my zone does not require to have DNSSEC and I can remove DNSSEC
- instruct bind to delete the key using dnssec-settime to remove the key 
(dnssec-settime -I +1d -D +2d keyfile)
- wait 2 days
- check no RRSIGS are existing for the domain
- wait for one day (TTL) + 1 say (safety) = at least 2 days
- now start to use KASP and let it create keys and sign your zone using
ecdsa256 (is this a recommended algo for using DNSSEC?)
- wait till CDS and CDNSKEY appears in the zone (bind ensures here the TTLs 
match, so it will not add the CDS before required time is passed)
- ask parent to add the DS to their zone
- the moment the DS is added on parent, DNSSEC is enforced

If I do not ask the parent to add the DS key, I can keep DNSSEC for the zones, 
but it will not be enforced or?
(this does not work if the registra would import the DS because CDS and CDNSKEY 
keys are existing, so be carefull here)

I'm talking here about zone fechner.net.

The TTL on the parent seems to be 86400:
dig +dnssec +multi -t DS fechner.net. @A.GTLD-SERVERS.NET ...
fechner.net.    86400 IN DS 64539 10 2 (
     12860767104BEE7B250F03B5D03425BC978F65CB426E
     EDC9C9B541AFB5D52D8D ) fechner.net.    
86400 IN DS 64539 10 1 (
     81EF72A9B9D92A9FD4F50856D1371DA05F5ACC27 ) ...

The TTL in my zone is also 86400, so I used this for all waiting times.

Thanks a lot for any comments!

Gruß
Matthias


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: KASP Inactive/Retired timestamps

[Matthijs Mekking]

Hi Gregory,

Thanks for trying out out the new KASP. Let me try to answer your
questions below.

On 5/20/20 2:37 AM, Gregory Shapiro via bind-users wrote:
> After the fantastic ISC DNSSEC webinar series last month, I began
> using KASP for my DNSSEC signed zones.  I have noticed an odd
> behavior with regards to the files BIND keeps in keys/ (K*.key,
> K*.private, and K*.state).  For inactive/retired keys, every BIND
> restart updates the dates in those files (see below).  This raises
> two questions:
> 
> 1. Should the time a key becomes inactive or retired be a fixed point
> in time rather than changing to the last time BIND restarted for
> every restart?

Named now takes care of the rollover, taking over the job of fiddling
with dnssec-keymgr. That means that named will set the key times.

Note that a key time is an indication of an event happening: if the
underlying state machine thinks it is not yet safe to do so, the event
will happen at a later point in time.

In other words, the keymgr embedded in named is making decisions on
rollover actions based on this state machine, not the key times.  The
key times do help the user to see when key rollovers will happen.

In principle these times are fixed, but changes in key files (a key gets
published, a change in key lifetime, ...)  will trigger updating the key
times.


> 2. When, if ever, is it safe to remove the files from the keys
> directory for inactive/retired keys (i.e., is there a state after
> Inactive or Retired)?

There is a Deleted time as well, at this point the key and corresponding
signatures should no longer occur in the zone.  When looking at the key
state files: if all states are in "hidden" it is safe to prune the files.

> An example set of changes is shown in the pruned diff below.  Note
> that for this particular key, the state file shows the following
> states:

Thanks for showing this example. This is a minor bug. What happens is
that the key file matches your dnssec-policy but most likely another
active key also matches. Any excess keys are retired immediately (even
if this key was already retired previously).


Best regards,

Matthijs


> DNSKEYState: hidden ZRRSIGState: hidden GoalState: hidden
> 
> --- Kgshapiro.net.+008+05640.key18 May 2020 02:06:14 -
> 1.9 +++ Kgshapiro.net.+008+05640.key19 May 2020 23:53:06
> - -; Inactive: 20200518020420 (Tue May 18 02:04:20 2020) +;
> Inactive: 20200519230430 (Tue May 19 23:04:30 2020)
> 
> --- Kgshapiro.net.+008+05640.private18 May 2020 02:06:14 -
> 1.9 +++ Kgshapiro.net.+008+05640.private19 May 2020 23:53:06
> - -Inactive: 20200518020420 +Inactive: 20200519230430
> 
> --- Kgshapiro.net.+008+05640.state  18 May 2020 02:06:14 -
> 1.8 +++ Kgshapiro.net.+008+05640.state  19 May 2020 23:53:06
> - -Retired: 20200518020420 (Tue May 18 02:04:20 2020) +Retired:
> 20200519230430 (Tue May 19 23:04:30 2020)
> 
> Thanks! ___ Please 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
> 



signature.asc
Description: OpenPGP digital signature
___
Please 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 migration sanity check

[Matthijs Mekking]

Hi John,

It all depends on the key material that is used to sign your zone. It
looks like you have to update the DNSKEY RRset, so I assume the vendors
are responsible for signing and each have their own key material.

In order to let the world know you are going to use new keys you will
have to pre-publish them in your zone. The DNSKEY RRset should be the
same in both versions of the zone . Also introduce the new NS records in
the child zone at the losing vendor.

Approximately one TTL (300 seconds in your case) later the new DNSKEY
RRset should be propagated and you can swap the DS and NS at the parent.
And when the DS and NS records of the one vendor have expired you can
remove the old key material from the zone.

For a bit more background on this you can take a look at
https://tools.ietf.org/html/rfc6781#section-4.3.5

In most cases there is no need to go insecure. The RFC section I refer
to have some considerations why you might want to go insecure during the
transition.

Hope this helps,

- Matthijs


On 8/19/20 8:45 PM, John W. Blue via bind-users wrote:
> We are in the process of moving from one IPAM vendor to another.
> 
>  
> 
> All of our zones are DNSSEC signed and the TTL’s have been lowered to
> 300 seconds.
> 
>  
> 
> At a high level, the playbook is to update the registrar with names/IP
> addresses of the new servers and update the DSKEY.  Depending on the
> time of the day that the cutover actually happens at we know the process
> to request of the registrar an out of band data push so the new servers
> will be seen by the open Internet.
> 
>  
> 
> A suggestion have been put forth that we should unsign our zones prior
> to migration but I am skeptical of the benefits of doing so.
> 
>  
> 
> Are we missing something obvious?
> 
>  
> 
> John
> 
> 
> ___
> Please 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
> 



signature.asc
Description: OpenPGP digital signature
___
Please 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: kasp-policy and catalog zones

[Matthijs Mekking]

Hi Christian,

There are no plans for this.

While technically a secondary can have a "dnssec-policy" statement
(acting as a bump-in-the-wire signer), signing a zone is mainly a
primary server responsibility and a policy configuration does not need
to be transferred to its secondaries.

For now I would suggest just add the zone with `rndc addzone` to the
primary or update the primary name server configuration and add the
"dnssec-policy" option.

Best regards,

Matthijs

On 9/18/20 7:52 PM, BÖSCH Christian wrote:
> Hi,
> 
>  
> 
> Is there a plan when the option for KASP "dnssec-policy" within
> 
> a catalog member zone will be available?
> 
> Just like with allow-transfer.catalog.example. IN APL ….
> 
>  
> 
> Thanks,
> 
> Christian
> 
> 
> ___
> Please 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
> 



signature.asc
Description: OpenPGP digital signature
___
Please 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: auto RRSIG enable

[Matthijs Mekking]

And in 9.16 you can use the following line to sign your zones:

   dnssec-policy default;

And you can create your own dnssec-policy if you need a different
signing configuration.

Best regards,

Matthijs

On 11/2/20 7:20 AM, Nyamkhand Buluukhuu wrote:
> Hello,
> 
> Yes you can define below configurations in your options:
> 
>        inline-signing yes;​
> 
> This configuration automates your signing zone tasks as whenever you
> change, add, delete your records or signature expired, named
> automatically re-sign your zone data with the keys in your key-directory.​
> 
> ​
> 
>        auto-dnssec maintain;​
> 
> This is for the automated key management. With this option enabled,
> named will periodically check if there are new key available, or expired
> key and manage DNSKEY records. It's very helpful when you renew your keys.
> 
> 
> 
> /Have a nice day :)/**
> 
> *BR, NYAMKHAND Buluukhuu*
> 
> * *
> 
> *Engineer*
> 
> *TPD/ETSD*
> 
> UNESCO street - 28, MPM Complex
> 
> Ulaanbaatar -14220, Mongolia
> 
> Mobile:   (976) 94081017
> 
> Web:   www.mobicom.mn
> 
>  
> 
> /Before you start - Be safety smart///
> 
>  
> 
> 
> 
> 
> *From:* bind-users  on behalf of rams
> 
> *Sent:* Monday, November 2, 2020 2:14 PM
> *To:* bind-users 
> *Subject:* auto RRSIG enable
>  
> Hi,
> Do we need to set any option in named.conf for auto RRSIG generation in
> bind? 
> Can anyone help me on this.
> 
> Regards,
> Ramesh
> 
> ___
> Please 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
> 



signature.asc
Description: OpenPGP digital signature
___
Please 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: ISC DNSSEC Guide - Working with the Parent Zone

[Matthijs Mekking]

Hi Daniel,

With which specific 9.16 version are you testing? The first versions 
used an unsafe time based rollover, assuming the DS would be published 
withing a certain time. In 9.16.7 a new rndc command "rndc dnssec 
-checkds" was introduced to tell BIND 9 that the DS for a given key has 
been published.


Best regards,

Matthijs

On 23-12-2020 09:53, Daniel Stirnimann wrote:

Hi all,

I'm testing the key rollover behavior of BIND 9.16 with the new
introduced "dnssec-policy" statement.

The ISC DNSSEC Guide, chapter Working with the Parent Zone (2) [1] states:

"At the time of this writing (mid-2020) BIND does not check for the
presence of a DS record in the parent zone before completing the KSK or
CSK rollover and withdrawing the old key. Instead, you need to use the
rndc tool to tell named that the DS record has been published."

The last sentence that one has to tell named that the DS record has been
published is not what I'm observing. My tests show that BIND continues
(finishes) the key rollover. The use of the rndc tool is not required.
Is this an error in the documentation?

dnsviz output of the test domain:

badware.ch signed with key 39414 but no trust anchor in .ch yet:
https://dnsviz.net/d/badware.ch/X9DD2w/dnssec/

badware.ch DNSSEC boostrap completed (with trust anchor in .ch,
automatically picked up by CDS/CDNSKEY polling by the parent):
https://dnsviz.net/d/badware.ch/X9ZGPA/dnssec/

badware.ch key rollover from key 39414 to key 6207 in progress:
https://dnsviz.net/d/badware.ch/X9oemQ/dnssec/

badware.ch previous key rollover finished. key 39414 is unused and will
be removed from the DNSKEY rrset soon. No "rndc" command has been used
to tell named to complete the key rollover.
Next key rollover started with the introduction of key 15769:
https://dnsviz.net/d/badware.ch/X-L1BQ/dnssec/


DNSSEC Policy:

dnssec-policy "test" {
 keys {
 csk key-directory lifetime 7d algorithm 13;
 };

 // Key timings
 dnskey-ttl 3600;
 publish-safety 1h;
 retire-safety 1h;

 // Zone parameters
 max-zone-ttl 3600;
 zone-propagation-delay 300;

 // Parent parameters
 parent-ds-ttl 1h;
 parent-propagation-delay 1h;
};

Thank you,
Daniel

[1]
https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2

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


___
Please 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: ISC DNSSEC Guide - Working with the Parent Zone

[Matthijs Mekking]

Hi Daniel,

This zone was signed before, prior to switching to 'dnssec-policy'? Or 
did you enable DNSSEC by adding 'dnssec-policy'?


If you have them, would you be able to share with me (off list) the logs 
and the key (state) files?


- Matthijs


On 23-12-2020 10:47, Daniel Stirnimann wrote:

Hello Matthijs,

I'm testing with version 9.16.9.

Ok, I'm more confused now.

For the current key rollover the DNSKEY RRset is not signed with both
the old key 6207 and the new key 15769 but only with the new key 15769.
The domain is now bogus:

https://dnsviz.net/d/badware.ch/X-MRAg/dnssec/


rndc dnssec -status badware.ch
dnssec-policy: test
current time:  Wed Dec 23 10:42:00 2020

key: 39414 (ECDSAP256SHA256), CSK
   published:  no
   key signing:no
   zone signing:   no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: unretentive
   - ds: unretentive
   - zone rrsig: unretentive
   - key rrsig:  hidden

key: 6207 (ECDSAP256SHA256), CSK
   published:  yes - since Wed Dec 16 07:33:24 2020
   key signing:no
   zone signing:   no

   Key is retired, will be removed on Fri Jan  1 11:43:24 2021
   - goal:   hidden
   - dnskey: omnipresent
   - ds: unretentive
   - zone rrsig: unretentive
   - key rrsig:  hidden

key: 15769 (ECDSAP256SHA256), CSK
   published:  yes - since Wed Dec 23 07:33:24 2020
   key signing:yes - since Wed Dec 23 07:33:24 2020
   zone signing:   yes - since Wed Dec 23 09:38:24 2020

   Next rollover scheduled on Wed Dec 30 07:33:24 2020
   - goal:   omnipresent
   - dnskey: omnipresent
   - ds: rumoured
   - zone rrsig: rumoured
   - key rrsig:  omnipresent


Daniel

On 23.12.20 10:33, Matthijs Mekking wrote:

Hi Daniel,

With which specific 9.16 version are you testing? The first versions
used an unsafe time based rollover, assuming the DS would be published
withing a certain time. In 9.16.7 a new rndc command "rndc dnssec
-checkds" was introduced to tell BIND 9 that the DS for a given key has
been published.

Best regards,

Matthijs

On 23-12-2020 09:53, Daniel Stirnimann wrote:

Hi all,

I'm testing the key rollover behavior of BIND 9.16 with the new
introduced "dnssec-policy" statement.

The ISC DNSSEC Guide, chapter Working with the Parent Zone (2) [1] states:

"At the time of this writing (mid-2020) BIND does not check for the
presence of a DS record in the parent zone before completing the KSK or
CSK rollover and withdrawing the old key. Instead, you need to use the
rndc tool to tell named that the DS record has been published."

The last sentence that one has to tell named that the DS record has been
published is not what I'm observing. My tests show that BIND continues
(finishes) the key rollover. The use of the rndc tool is not required.
Is this an error in the documentation?

dnsviz output of the test domain:

badware.ch signed with key 39414 but no trust anchor in .ch yet:
https://dnsviz.net/d/badware.ch/X9DD2w/dnssec/

badware.ch DNSSEC boostrap completed (with trust anchor in .ch,
automatically picked up by CDS/CDNSKEY polling by the parent):
https://dnsviz.net/d/badware.ch/X9ZGPA/dnssec/

badware.ch key rollover from key 39414 to key 6207 in progress:
https://dnsviz.net/d/badware.ch/X9oemQ/dnssec/

badware.ch previous key rollover finished. key 39414 is unused and will
be removed from the DNSKEY rrset soon. No "rndc" command has been used
to tell named to complete the key rollover.
Next key rollover started with the introduction of key 15769:
https://dnsviz.net/d/badware.ch/X-L1BQ/dnssec/


DNSSEC Policy:

dnssec-policy "test" {
  keys {
  csk key-directory lifetime 7d algorithm 13;
  };

  // Key timings
  dnskey-ttl 3600;
  publish-safety 1h;
  retire-safety 1h;

  // Zone parameters
  max-zone-ttl 3600;
  zone-propagation-delay 300;

  // Parent parameters
  parent-ds-ttl 1h;
  parent-propagation-delay 1h;
};

Thank you,
Daniel

[1]
https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2

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


___
Please 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-us

Re: How to migrate dnssec algorithm smoothly from auto-dnssec to dnssec-policy?

[Matthijs Mekking]

Hi Thomas,

Your policy requests four keys in two algorithms: rsasha1 and 
ecdsap256sha256. The keys that are being retired are of algorithm 
rsasha256. Because the existing algorithms don't match the policy, they 
are being retired.


In other words, it doesn't look like the existing keys were of algorithm 
rsasha1.


Also keep in mind that if the configured length of the keys in 
dnssec-policy don't match the existing keys, the existing keys will also 
be retired.


Best regards,

Matthijs



On 15-01-2021 11:49, von Dein, Thomas wrote:

Howdy,

I have a domain which is being signed automatically using auto-dnssec on an 
older bind9, it uses RSASHA1 keys. Now the registry requires us to move to a 
more secure algorithm. Therefore I updated bind to bind9.16.6. Now I could 
switch to dnssec-policy, however if I change the algorithm, it immediately 
drops the old keys instead of retiring them. I didn't find any hint in the docs 
or on the net how to do this.

So this was the old config:

zone "customer.bank" in {
   type master;
   file "zone/master/customer.bank";
   key-directory "/usr/local/etc/namedb/zone/keys";
   auto-dnssec maintain;
   inline-signing yes;
   dnssec-dnskey-kskonly yes;
};

Now after upgrading I changed it to:

dnssec-policy "eval" {
 keys {
 ksk lifetime 2d algorithm rsasha1;
 zsk lifetime 2d algorithm rsasha1;
 ksk lifetime 365d algorithm ecdsap256sha256;
 zsk lifetime 60d algorithm ecdsap256sha256;
 };
};

zone "helaba.bank" in {
   type master;
   file "zone/master/helaba.bank";
   key-directory "/usr/local/etc/namedb/zone/keys";
   dnssec-policy "eval";
};

My idea was to retire the rsasha1 keys after 2 days and then replace them with 
the newly generated ones. However, this is what bind actually did:

15-Jan-2021 11:20:46.036 zoneload: zone customer.bank/IN (unsigned): loaded 
serial 2020100500
15-Jan-2021 11:20:46.042 zoneload: zone customer.bank/IN (signed): loaded 
serial 2020100551 (DNSSEC signed)
15-Jan-2021 11:20:46.049 general: zone customer.bank/IN (signed): 
receive_secure_serial: unchanged
15-Jan-2021 11:20:46.297 notify: zone customer.bank/IN (signed): sending 
notifies (serial 2020100551)
15-Jan-2021 11:20:46.297 dnssec: zone customer.bank/IN (signed): reconfiguring 
zone keys
15-Jan-2021 11:20:46.311 dnssec: keymgr: retire DNSKEY 
customer.bank/RSASHA256/31284 (ZSK)
15-Jan-2021 11:20:46.311 dnssec: keymgr: retire DNSKEY 
customer.bank/RSASHA256/39364 (KSK)
15-Jan-2021 11:20:46.664 dnssec: keymgr: DNSKEY customer.bank/RSASHA1/14477 
(KSK) created for policy eval
15-Jan-2021 11:20:46.868 dnssec: keymgr: DNSKEY customer.bank/RSASHA1/61258 
(ZSK) created for policy eval
15-Jan-2021 11:20:46.868 dnssec: keymgr: DNSKEY 
customer.bank/ECDSAP256SHA256/41200 (KSK) created for policy eval
15-Jan-2021 11:20:46.868 dnssec: keymgr: DNSKEY 
customer.bank/ECDSAP256SHA256/55282 (ZSK) created for policy eval
15-Jan-2021 11:20:46.938 dnssec: DNSKEY customer.bank/RSASHA256/31284 (ZSK) is 
now deleted
15-Jan-2021 11:20:46.938 dnssec: DNSKEY customer.bank/RSASHA256/39364 (KSK) is 
now deleted
15-Jan-2021 11:20:46.939 dnssec: Fetching customer.bank/RSASHA1/14477 (KSK) 
from key repository.
15-Jan-2021 11:20:46.939 dnssec: DNSKEY customer.bank/RSASHA1/14477 (KSK) is 
now published
15-Jan-2021 11:20:46.939 dnssec: DNSKEY customer.bank/RSASHA1/14477 (KSK) is 
now active
15-Jan-2021 11:20:46.939 dnssec: Fetching customer.bank/RSASHA1/61258 (ZSK) 
from key repository.
15-Jan-2021 11:20:46.939 dnssec: DNSKEY customer.bank/RSASHA1/61258 (ZSK) is 
now published
15-Jan-2021 11:20:46.939 dnssec: DNSKEY customer.bank/RSASHA1/61258 (ZSK) is 
now active
15-Jan-2021 11:20:46.939 dnssec: Fetching customer.bank/ECDSAP256SHA256/41200 
(KSK) from key repository.
15-Jan-2021 11:20:46.939 dnssec: DNSKEY customer.bank/ECDSAP256SHA256/41200 
(KSK) is now published
15-Jan-2021 11:20:46.939 dnssec: DNSKEY customer.bank/ECDSAP256SHA256/41200 
(KSK) is now active
15-Jan-2021 11:20:46.939 dnssec: Fetching customer.bank/ECDSAP256SHA256/55282 
(ZSK) from key repository.
15-Jan-2021 11:20:46.939 dnssec: DNSKEY customer.bank/ECDSAP256SHA256/55282 
(ZSK) is now published
15-Jan-2021 11:20:46.939 dnssec: DNSKEY customer.bank/ECDSAP256SHA256/55282 
(ZSK) is now active
15-Jan-2021 11:20:46.985 dnssec: zone customer.bank/IN (signed): next key 
event: 15-Jan-2021 13:20:46.297
15-Jan-2021 11:20:51.305 notify: zone customer.bank/IN (signed): sending 
notifies (serial 2020100558)

In fact it created 2 new key pairs, one for rsasha1 and one for ecdsap256sha256.

I am pretty sure my setup is invalid somehow.

So how could I configure bind so that it keeps the existing rsasha1 keys for a 
while and use the new ones only afterwards?


Best regards,
Tom
___
Please 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://

Re: Updating a DNSSEC config to use a different algorithm

[Matthijs Mekking]

Hi,

Depends on what your DNSSEC configuration is. Are you using 
dnssec-signzone/named? auto-dnssec maintain? inline-signing? 
dnssec-policy? dnssec-keymgr?


Yes there are a lot of ways to maintain DNSSEC in BIND. The recommended 
way forward is to use dnssec-policy. Migrating to it may still be a bit 
tricky*, but once you use it, changing a new signing algorithm is pretty 
simple:


1. Update your dnssec-policy, reload config.
2. Wait a little bit.
3. When the new DS is in the parent, run "rndc dnssec -checkds published
   on the right key id."
4. Also run "rndc dnssec -checkds withdrawn" on the id of the key that
   has its DS removed from the parent.
5. Have a celebratory drink.

Algorithm rollover with dnssec-policy will gracefully transition to the 
keys with the new algorithms, so during the rollover period you should 
see your zone being signed with two algorithms.


Best regards,

Matthijs


*In principal you can just switch to dnssec-policy with your existing 
key files and BIND will initialize key state files for those keys. But 
there is at least one known bug that deleted keys may be used again for 
signing (those deleted keys still have their key files in the key 
directory). [GL #2406]



On 01-02-2021 14:40, @lbutlr wrote:

I've been using alg-7 for DNS, but that is no longer recommended. How difficult 
is it to change the signing algorithm and what is the process (Bind 9.16.11)?



___
Please 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: Updating a DNSSEC config to use a different algorithm

[Matthijs Mekking]

On 01-02-2021 17:34, @lbutlr wrote:

On 01 Feb 2021, at 07:14, Matthijs Mekking  wrote:

Depends on what your DNSSEC configuration is. Are you using
dnssec-signzone/named? auto-dnssec maintain? inline-signing?
dnssec-policy? dnssec-keymgr?


These are all good questions, and when I set this up I could have
answered with some degree of confidence.

What I have in named.conf is simply dnssec-validation auto; and
domains have auto-dnssec maintain, so I guess that answers that
question.


Yes there are a lot of ways to maintain DNSSEC in BIND. The
recommended way forward is to use dnssec-policy. Migrating to it
may still be a bit tricky*, but once you use it, changing a new
signing algorithm is pretty simple:

1. Update your dnssec-policy, reload config.


Assuming there is no dnssec-policy (there is not) what would I update
it to?

This did give me enough to DDG on, does this link look reasonable?

<https://serverfault.com/questions/1007899/how-to-migrate-bind-configuration-to-dnssec-policy-from-auto-dnssec-maintain-wit>

 #v+ dnssec-policy alg13-ksk-unlimited-zsk-60day { keys { ksk
key-directory lifetime unlimited algorithm ECDSAP256SHA256; zsk
key-directory lifetime P60D algorithm ECDSAP256SHA256; }; }; #v-


If you switch to dnssec-policy, before you change your algorithm you 
have to migrate the old keys.


You can use two methods:

1. Create a dnssec-policy that matches your current keys (so in your 
case algorithm 7, also make sure you use the same length).


So I guess something like:

dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm 7 2048;
zsk key-directory lifetime P60D algorithm 7 1024 ;
};
};

This is an assumption. Check the key length with your existing keys.

2. You can also initialize the key states manually with dnssec-settime:

Key state options:
-s: update key state file (default no)
-g state: set the goal state for this key
-d state date/[+-]offset: set the DS state
-k state date/[+-]offset: set the DNSKEY state
-r state date/[+-]offset: set the RRSIG (KSK) state
-z state date/[+-]offset: set the RRSIG (ZSK) state

dnssec-settime -s -g OMNIPRESENT now -d OMNIPRESENT now \
-k OMNIPRESENT now -r OMNIPRESENT now 
dnssec-settime -s -g OMNIPRESENT now -k OMNIPRESENT now \
-z OMNIPRESENT now 

It is a bit technical, but this would make your existing key files ready 
to for dnssec-policy. Use this if your zone is correctly signed at the 
moment, and the DS is in the parent for some time.


Algorithm rollover:

Now that you have migrated your existing key files (they will now have a 
.state file), you can reconfigure your dnssec-policy with a new 
algorithm,. The alg-7 keys will be gracefully removed from the zone, 
while new keys with a new algorithm will be introduced.



If so, what are the possible values for the algorithm? And for the
actual policy (alg13-…)? I also see mention of a dissed-policy
default but that is out of context so I don't know if that is simply
telling the domain to use the policy defined separately in the the
named.conf as above. Alg13-ksk gives two hits on DDG, and the second
one is in Japanese.


Algorithm 13 (ECDSAP256SHA256) is a good choice. It is becoming best 
practice, it is as popular as algorithm 8 (RSASHA256)*, and the majority 
of resolvers can validate with this algorithm**


* https://stats.dnssec-tools.org/
** https://blog.apnic.net/2018/08/23/measuring-ecdsa-in-dnssec-an-update/



2. Wait a little bit. 3. When the new DS is in the parent, run
"rndc dnssec -checkds published on the right key id." 4. Also run
"rndc dnssec -checkds withdrawn" on the id of the key that has its
DS removed from the parent. 5. Have a celebratory drink.


Way ahead of you there! 🥃


*In principal you can just switch to dnssec-policy with your
existing key files and BIND will initialize key state files for
those keys. But there is at least one known bug that deleted keys
may be used again for signing (those deleted keys still have their
key files in the key directory). [GL #2406]


Hopefully that will not be an issue as there are no old key files. Or
rather they are all about the same age of Jan-Feb of 2019,


This bug affects key files that exist but have their "Inactive" and/or
"Delete" timing metadata in the past.

Best regards,

Matthijs
___
Please 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: Updating a DNSSEC config to use a different algorithm

[Matthijs Mekking]

On 02-02-2021 14:40, @lbutlr wrote:

On 02 Feb 2021, at 02:23, Matthijs Mekking  wrote:

1. Create a dnssec-policy that matches your current keys (so in your case 
algorithm 7, also make sure you use the same length).

So I guess something like:

dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm 7 2048;
zsk key-directory lifetime P60D algorithm 7 1024 ;
};
};

This is an assumption. Check the key length with your existing keys.


Yes, the current keys are alg 7 2048 bit. Is there a document on the various options here? I am 
plowing through the "BIND 9 Administrator Reference Manual, Release BIND 9.16.5 (Stable 
Release)" but it is slow going right now and "dnssec-policy" does not appear in the 
pdf in a searchable form, which makes things even more fun).


No, I could add them to the ARM. But it is the same as dnssec-signzone:

-a :
RSASHA1 | NSEC3RSASHA1 |
RSASHA256 | RSASHA512 |
ECDSAP256SHA256 | ECDSAP384SHA384 |
ED25519 | ED448 | DH


If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ 
suits you better?




(This domain has a RRSIG range of 2021010953 - 20210221230953)

I am guessing as soon as I add that DNSSEC-policy I also need to change each domain record from 
"auto-dnssec maintain;" to "dnssec-policy default;" or do I do that after the 
.state files have been created? (That doesn't sound right, but best to check).


I guess with "each domain record" you mean "each zone".

If you are migrating, don't change it to "dnssec-policy default;". This 
is a built-in policy that does not match your existing keys.


Instead, change it to "dnssec-policy alg13-ksk-unlimited-zsk-60day;"

Once you have .state files, you should be able to change to a different 
policy, including "default". Note that the default policy uses a single 
key (as both KSK and ZSK).




Now that you have migrated your existing key files (they will now have a .state 
file), you can reconfigure your dnssec-policy with a new algorithm,. The alg-7 
keys will be gracefully removed from the zone, while new keys with a new 
algorithm will be introduced.


So once all the domains have a .state file associated with them in the key 
directory I can change the dnssec-policy to the sample I had before and it will 
just migrate from the alg 7 keys above to alg ECDSAP256SHA256 (or I can just 
say alg 13 instead).

#v+
dnssec-policy alg13-ksk-unlimited-zsk-60day {
 keys {
 ksk key-directory lifetime unlimited algorithm 13;
 zsk key-directory lifetime P60D algorithm 13;
 };
};


Yes, once all keys for the zones in question have a .state file 
associated with them, you should be able to change the dnssec-policy and 
start using ECDSA (you can use the string ECDSAP256SHA256 or the number 13).


I would recommend to first check if the .state files look correct before 
changing your dnssec-policy (do the keys in your zone match the .state 
file? Are the states set to OMNIPRESENT? Is the goal set to OMNIPRESENT?



- Matthijs




#v-

That seems very straightforward, there must be a catch somewhere.


___
Please 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: Updating a DNSSEC config to use a different algorithm

[Matthijs Mekking]

Hi,

On 02-02-2021 18:16, @lbutlr wrote:

On 02 Feb 2021, at 07:36, Matthijs Mekking  wrote:

If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ suits 
you better?


The PDF works fine, and I can search for "dnssec" and "policy" but it is using 
some emdash or similar character for the - in between which makes searching an issue (even if I 
copy the text from the PDF and then search for what.I copied).


(This domain has a RRSIG range of 2021010953 - 20210221230953)
I am guessing as soon as I add that DNSSEC-policy I also need to change each domain record from 
"auto-dnssec maintain;" to "dnssec-policy default;" or do I do that after the 
.state files have been created? (That doesn't sound right, but best to check).


I guess with "each domain record" you mean "each zone".


Yes. I still think of them as domains (because they are all domains in my case).


If you are migrating, don't change it to "dnssec-policy default;". This is a 
built-in policy that does not match your existing keys.


OK, now I am a bit confused.

In named.conf there is dsnssec-policy alg13-ksk-unlimited-zsk-60day { …

Then in the zone currently I have:

zone "kreme.com" { type primary; file "kreme.com.signed"; auto-dnssec maintain; 
allow-update { key "rndc-key"; }; }

Are you saying I need to change auto-dnssec maintain; to "dsnssec-policy 13;"?


No, sorry. I was saying don't change to "dnssec-policy default;" (which 
also uses 13). Change it to the dnssec-policy that you created that 
match your existing keys (alg-7).




I would recommend to first check if the .state files look correct before 
changing your dnssec-policy (do the keys in your zone match the .state file? 
Are the states set to OMNIPRESENT? Is the goal set to OMNIPRESENT?


I did this with a domain that does not get email as a test:

#v+
named.conf:
dnssec-policy alg13-ksk-unlimited-zsk-60day {
 keys {
ksk key-directory lifetime unlimited algorithm 7 2048;
zsk key-directory lifetime P60D algorithm 7 1024 ;
 };
};

zone "example.com" { type primary; file "example.com.signed"; dnssec-policy default; 
allow-update { key "rndc-key";}; };

; This is the state of key 2611, for mrsbutler.com.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20210202134627 (Tue Feb  2 06:46:27 2021)
Published: 20210202134627 (Tue Feb  2 06:46:27 2021)
Active: 20210202134627 (Tue Feb  2 06:46:27 2021)
PublishCDS: 20210203145127 (Wed Feb  3 07:51:27 2021)
DNSKEYChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
ZRRSIGChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
KRRSIGChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
DSChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
#v-

I also have new key and private and state files for the alg 7 KSK and ZSK files 
for the zone I am testing with, and the old files are gone, so I think it 
migrated correctly?


Check your zone and see if they still have the alg 7 keys. If so you 
probably migrated correctly. You can use "rndc dnssec -status zone" to 
see about all the keys available for this zone.


What old files are gone? Named doesn't remove key files (yet).



But I guess that is what you meant by it using a single key for KSK and ZSK?


Yes, one key that has both the KSK and ZSK role.



Is there a reason NOT to use default? If I use default can I then eliminiate 
the dnssec-policy alg13-ksk-unlimited-zsk-60day { … } block entirely once the 
new keys and state files are created?


There could be reasons not to use the default, but we think the default 
policy suits most people. It has a single key and does not do scheduled 
rollovers.


If you want to have scheduled rollovers, different algorithm, prefer to 
have a separate KSK, tweak the signature lifetimes, etc. Then you can 
create your own dnssec-policy.




I tried to use `rndc dnssec -checkds published example.com" but it wants a -key 
and doesn't seem to want the name of the .key file, so not sure what the syntax is 
there and the man page on rndc isn't helping. Status, on the other hand:


-key id (id is the 5 digit number).



# rndc dnssec -status example
dnssec-policy: default
current time:  Tue Feb  2 10:01:32 2021

key: 1058 (NSEC3RSASHA1), ZSK
   published:  no
   zone signing:   no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: hidden
   - zone rrsig: unretentive

key: 37515 (NSEC3RSASHA1), KSK
   published:  no
   key signing:no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: hidden
   - ds: hidden
   - key rrsig:  hidden

key: 2611 (ECDSAP256SHA256), CSK
   published:  yes - since 

Re: DNSKEY failure

[Matthijs Mekking]

Hi,

On 05-02-2021 10:23, @lbutlr wrote:

So, with my test domain that is using dsnssec-policy default dnsviz reports

"DNSKEY: No response was received from the server over UDP"

But:

dig +norec +dnssec +bufsize=512 +ignore dnskey

Shows a DNSKEY record.


It would be useful to also provide the dig output, and what domain it is 
about.


Compare the output with the response you get when you dig your name servers.

Best regards,

Matthijs



(There is no DNSKEY record shown on the domains still using auto-dnssec 
maintain; with alg-7 keys, but I think that is expected).

Is this a propagation issue, or is there something I need to do for "192.112.36.4, 
UDP_-_EDNS0_512_D_KN" to see the DNSKEY record?

example.com.  3600IN  RRSIG   DNSKEY 13 2 3600 20210217190645 
20210203180645 18434 example.com. {blah blah blah}



___
Please 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 and NSEC missing ZSK?

[Matthijs Mekking]

Hi,

On 08-02-2021 12:20, @lbutlr wrote:

I feel I am getting close. I got the digest generated for hover.com and updated 
the DNS on the test zone, but I am getting errors on verify that I don't 
understand.

#v+
# dnssec-verify -I text -o example.com /etc/namedb/working/example.com.signed
Loading zone 'example.com' from file '/etc/namedb/working/example.com.signed'

Verifying the zone using the following algorithms:
- ECDSAP256SHA256
Missing ZSK for algorithm ECDSAP256SHA256
Missing NSEC record for blog.example.com
Missing NSEC record for wiki.example.com
Missing NSEC record for foobar.example.com
Missing NSEC record for barfoo.example.com
The zone is not fully signed for the following algorithms:
  vECDSAP256SHA256
.
DNSSEC completeness test failed.NSSEC completeness test failed.
#v-

The missing ZSK is throwing me, and I don't know what to add to my zone record 
for NSEC. I am following along (trying) with 
https://bind9.readthedocs.io/en/latest/dnssec-guide.html which makes no mention 
of this, but shows NSEC showing up in the output of the signed file.


Use dnssec-verify -z to indicate that the ZSK may be the same key as the 
KSK.


The missing NSEC records are more worrisome.



The only thing I can find that seems relevant (though it is for bind 9.7.3) is 
part of the key generation, but I did not generate the keys manually, bind did 
that with dnssec-policy default;

#v+
; This is the state of key 18434, for example.com.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20210202180145 (Tue Feb  2 11:01:45 2021)
Published: 20210202180145 (Tue Feb  2 11:01:45 2021)
Active: 20210202180145 (Tue Feb  2 11:01:45 2021)
PublishCDS: 20210203190645 (Wed Feb  3 12:06:45 2021)
DNSKEYChange: 20210202200645 (Tue Feb  2 13:06:45 2021)
ZRRSIGChange: 20210203190645 (Wed Feb  3 12:06:45 2021)
KRRSIGChange: 20210202200645 (Tue Feb  2 13:06:45 2021)
DSChange: 20210203190645 (Wed Feb  3 12:06:45 2021)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent
#v-

So the state file says the ZSK is yes, but dnssec-verify says no.

I ran delv test and it looks as I expect based on he guide linked above.

#v+
# delv @127.0.0.1 -a /tmp/Kexample.com.+013+18434.key +root=example.com 
example.com SOA +multiline
; fully validated
example.com.  3600 IN SOA ns1.example.net. admin.example.net. (
 2018022422 ; serial
 300; refresh (5 minutes)
 300; retry (5 minutes)
 18000  ; expire (5 hours)
 3600   ; minimum (1 hour)
 )
example.com.  3600 IN RRSIG SOA 13 2 3600 (
 20210221095138 20210207085138 18434 
example.com.
 Qps8u4m6…=
#v-

Is there a way to force rndc/bind to recreate the .signed file? If I move it 
aside and restart named or rndc reload or rndc reconfig, the signed zone file 
is not recreated.



rndc sign zone

- Matthijs
___
Please 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: Still seeing some ALG-7 DNSSE

[Matthijs Mekking]

Most likely you have to delete those files manually.

In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By 
default the keys are retained for 90 days after their latest usage. So 
in that case keys will be cleaned up automatically.


If you run a lower version, or if you set "purge-keys 0;" (disabled), 
you have to purge key files manually.


Best regards,

Matthijs



On 05-04-2021 18:27, @lbutlr wrote:

If I do:

cd /etc/named/working/main/
for i in *; do dig $i +dnssec | grep "A 13 2" | awk '{print $1}';done

I see a list of all the domains on the system, so that's good, everything has a 
ALG-13 signature.

If I do

for i in *; do dig $i +dnssec | grep "A 7 2" | awk '{print $1}';done

I see a list of a handful of domains that still have ALG-7 signatures. This is 
confirmed by a warning in dnsviz.

I don't see any differences in the configurations, and none of the main records 
on the registrar list ALG-7 anymore, only ALG-13.

All of the domains are setup with  dnssec-policy default.

Thera re still 007 keyholes on the system for ALL domains (unexpected), updated 
every hour  (expected).

  8 -rw-r--r--  1 bind  bind   1.0K Apr  5 06:21 Kkreme.com.+007+01083.key
  8 -rw-r--r--  1 bind  bind   587B Apr  5 06:21 Kkreme.com.+007+01083.state
  8 -rw---  1 bind  bind   3.3K Apr  5 06:21 Kkreme.com.+007+01083.private
  8 -rw-r--r--  1 bind  bind   708B Apr  5 06:21 Kkreme.com.+007+30512.key
  8 -rw-r--r--  1 bind  bind   520B Apr  5 06:21 Kkreme.com.+007+30512.state
  8 -rw---  1 bind  bind   1.8K Apr  5 06:21 Kkreme.com.+007+30512.private
  8 -rw-r--r--  1 bind  bind   399B Apr  5 06:21 Kkreme.com.+013+29597.key
  8 -rw-r--r--  1 bind  bind   651B Apr  5 06:21 Kkreme.com.+013+29597.state
  8 -rw---  1 bind  bind   215B Apr  5 06:21 Kkreme.com.+013+29597.private

This domain does not show any ALG-7 keys in dig:

# dig kreme.com +dnssec +short
65.121.55.45
A 13 2 3600 20210415161448 20210401155316 29597 kreme.com. 
Sea2LPlKGeH/aP1kwONwtuH0Jkp2TVHNb/v9PEOUiVQVzCwKMkg79+K9 
bE8yhNQ2vLV4Fxvzk4jknP8Cbq98lQ==

Is there anything I need to do here or not? Will those alg-7 key files continue 
to hang around forever? Do I need to do something to get dnsviz and dig +dnssec 
to stop reporting the old keys or is that like propagation and it will sort 
itself out? I don't see a pattern in the domains that are still showing alg-7 
but it is possible they had the DS/registrar info updated later than the other 
domains.


___
Please 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: Still seeing some ALG-7 DNSSE

[Matthijs Mekking]

On 11-04-2021 01:22, @lbutlr wrote:

On 06 Apr 2021, at 01:13, Matthijs Mekking  wrote:

In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By 
default the keys are retained for 90 days after their latest usage. So in that case keys will be 
cleaned up automatically.


Excellent. Does that go in the zone record with default, or does it replace 
default> I don't see the syntax in the release notes.


If you don't set "purge-keys" it will be retained for 90 days. 
Otherwise, set it inside the 'dnssec-policy' you are using. In other 
words, If you want something else, use this:


dnssec-policy "myway" {
purge-keys P30D;
...
// other policy options
};



Or do I add a

dnssec-policy "default" {
   purge-keys 30; // (or is that field seconds?)
}

Or will that mess up the predefined for default?


First, you cannot (re)configure "default" policy, it is a builtin policy.

You can configure a new policy and just add a single option 
"purge-keys". Zones with that policy will act the same as the default 
policy except for how long to retain keys.


The field is a ttl value or a ISO 8601 duration. So a number is treated 
as seconds. If you want 30 days, use 30d or P30D.


Cheers,

Matthijs
___
Please 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: Zone 126.0.0.1 has 0 SOIA records

[Matthijs Mekking]

Perhaps inspect the zone file?

Also the CDS/CDNSKEY consistency checks stick out. Perhaps remove them 
from the unsigned zone files?


Best regards,

Matthijs

On 12-04-2021 14:52, @lbutlr wrote:

I restored a backup of my named.conf after a little bit of an oops. The file is 
the same exact file as it was yesterday, bt on starting bind I get:

named[24161] 
named[24161] BIND 9 is maintained by Internet Systems Consortium,
named[24161] Inc. (ISC), a non-profit 501(c)(3) public-benefit
named[24161] corporation.  Support and training for BIND 9 are
named[24161] available at https://www.isc.org/support
named[24161] 
named[24161] command channel listening on 127.0.0.1#953
named[24161] zone localhost/IN: CDS/CDNSKEY consistency checks failed
named[24161] zone localhost/IN: not loaded due to errors.
named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:3: ignoring 
out-of-zone data (0.ip6.arpa)
named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:17: ignoring 
out-of-zone data 
(1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa)
named[24161] /usr/local/etc/namedb/working/localhost-reverse.db:18: ignoring 
out-of-zone data (1.0.0.0.ip6.arpa)
named[24161] zone 127.in-addr.arpa/IN: has 0 SOA records
named[24161] zone 127.in-addr.arpa/IN: has no NS records
named[24161] zone 127.in-addr.arpa/IN: not loaded due to errors.
named[24161] zone 0.ip6.arpa/IN: CDS/CDNSKEY consistency checks failed
named[24161] zone 0.ip6.arpa/IN: not loaded due to errors.
named[24161] all zones loaded
named[24161] DNS format error from 82.192.82.228#53 resolving 
112.242.54.110.in-addr.arpa/PTR for 65.121.55.44#55292: Name in-addr.arpa (SOA) 
not subdomain of zone 242.54.110.in-addr.arpa -- invalid response
named[24161] DNS format error from 82.192.82.228#53 resolving 
112.242.54.110.in-addr.arpa/PTR for 127.0.0.1#27795: Name in-addr.arpa (SOA) 
not subdomain of zone 242.54.110.in-addr.arpa -- invalid response

This last repeats periodically

Stoping and starting named don't clear the error, but named appears to be fine 
(checking domains returns expected results). Key files are updating every hour 
as expected. The secondary servers are in sync…



___
Please 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: Ask for automated KSK roll with DS checking

[Matthijs Mekking]

On 14-04-2021 22:30, Greg Rivers via bind-users wrote:

On Wednesday, 14 April 2021 15:00:38 CDT Bob Harold wrote:

Does anyone have an automated KSK roll process, that checks for the DS
record at the parent, that they can share?

As far as I can tell, the automated signing in BIND will roll the KSK if I
set the timing in the policy file, but it won't check the DS record, so it
will happily break DNSSEC if some other process does not update the DS
record at the right time.  That's too big a risk for me, the process needs
to check the DS record before completing the KSK roll.  Surely someone has
done this.  I would rather not reinvent the wheel.  But I have searched and
not found anything yet.


As I understand it, the way it works now is that the actual KSK rollover won't 
occur until you execute `rndc dnssec -checkds ...` [1].


That is correct.


I'm hopeful that named will fully automate this check at some point soon.


It is on the roadmap:

https://gitlab.isc.org/isc-projects/bind9/-/issues/1126

- Matthijs



[1] 



___
Please 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: Ask for automated KSK roll with DS checking

[Matthijs Mekking]

On 15-04-2021 16:35, Bob Harold wrote:


On Thu, Apr 15, 2021 at 8:50 AM Bob Harold <mailto:rharo...@umich.edu>> wrote:



On Thu, Apr 15, 2021 at 2:57 AM Matthijs Mekking mailto:matth...@isc.org>> wrote:



On 14-04-2021 22:30, Greg Rivers via bind-users wrote:
 > On Wednesday, 14 April 2021 15:00:38 CDT Bob Harold wrote:
 >> Does anyone have an automated KSK roll process, that checks
for the DS
 >> record at the parent, that they can share?
 >>
 >> As far as I can tell, the automated signing in BIND will
roll the KSK if I
 >> set the timing in the policy file, but it won't check the DS
record, so it
 >> will happily break DNSSEC if some other process does not
update the DS
 >> record at the right time.  That's too big a risk for me, the
process needs
 >> to check the DS record before completing the KSK roll. 
Surely someone has

 >> done this.  I would rather not reinvent the wheel.  But I
have searched and
 >> not found anything yet.
 >>
 > As I understand it, the way it works now is that the actual
KSK rollover won't occur until you execute `rndc dnssec -checkds
...` [1].

That is correct.

 > I'm hopeful that named will fully automate this check at some
point soon.

It is on the roadmap:

https://gitlab.isc.org/isc-projects/bind9/-/issues/1126
<https://gitlab.isc.org/isc-projects/bind9/-/issues/1126>

- Matthijs


 > [1]

<https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2

<https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2>>
 >

Thank you both very much.  I missed that, and I am testing with the
RedHat RHEL7 version of BIND 9.11, which does not seem to wait. 
Looks like I will need to run a newer version of BIND, at least on

my in-line signing server.

-- 
Bob Harold

University of Michigan


If BIND holds both the child and parent zone, will it add the DS record 
at the correct time?  Or do I still need to write scripts to update the 
DS records in all my sub-zones?  And is there some signal from BIND at 
the time the DS record should be written, or do i need to calculate the 
right time?


Currently you still have to write scripts to update DS records in all 
your parent zones.


The CDS/CDNSKEY records are published in the child zones that indicate 
the DS should be published, so I would script against that.


Then when the DS is seen in the parent, call the rndc dnssec -checkds 
published/withdrawn command.


Best regards,

Matthijs



--
Bob Harold

___
Please 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: Ask for automated KSK roll with DS checking

[Matthijs Mekking]

On 15-04-2021 18:44, Tony Finch wrote:

Matthijs Mekking  wrote:

On 15-04-2021 16:35, Bob Harold wrote:


If BIND holds both the child and parent zone, will it add the DS record
at the correct time?  Or do I still need to write scripts to update the
DS records in all my sub-zones?  And is there some signal from BIND at
the time the DS record should be written, or do i need to calculate the
right time?


Currently you still have to write scripts to update DS records in all
your parent zones.

The CDS/CDNSKEY records are published in the child zones that indicate
the DS should be published, so I would script against that.

Then when the DS is seen in the parent, call the rndc dnssec -checkds
published/withdrawn command.


dnssec-cds can tell you what the parental DS record(s) should be. It
can maintain a dsset file for each child zone that you can $INCLUDE in the
parent. It's fairly bare so it needs to be wrapped with a script that does
the necessary queries and updates.

I don't know if the dnssec-policy stuff includes timing parameters or
checks to protect against parental publication delays; if not then the
wrapper script will have to keep track of time or poll the parent servers
or something.


It does.

After you have issued the 'rndc dnssec -checkds published' command 
(which should be done only if you have seen the DS in the parent), BIND 
will wait for 'parent-ds-ttl' plus 'parent-propagation-delay' plus 
'retire-safety' before actually considering the DS omnipresent. The DS 
needs to be omnipresent before the predecessor DNSKEY may be removed.


The defaults for these values are 1 day, 1 hour, and 1 hour. So after 
running the 'rndc dnssec -checkds published' command, by default the 
rollover will continue 26 hours later.


You should set these parameters to whatever your parent zone is using. 
You should set the 'retire-safety' delay to whatever you feel 
comfortable with.


Best regards,

Matthijs




Tony.


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


___
Please 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: 'managed-keys' is deprecated ??

[Matthijs Mekking]

Hi -T,

I cannot reproduce this confusing warning message. Please use the 
absolute path /var/named/chroot/etc/named.root.key in 
https://bugzilla.redhat.com/show_bug.cgi?id=1972022


Best regards,

Matthijs

On 15-06-2021 07:46, ToddAndMargo via bind-users wrote:

On 6/14/21 9:30 PM, Jim Popovitch via bind-users wrote:

On Tue, 2021-06-15 at 14:27 +1000, Mark Andrews wrote:

https://downloads.isc.org/isc/bind9/9.16.16/doc/arm/Bv9ARM.pdf


The modern-day RTFM  :-)


-Jim P.


"Just Google it."  The new RTFM.  Chuckle!

And ' 'managed-keys' is deprecated" is a bug.
I just reported:

    named-checkconf gives confusing depreciated 'managed-keys' message

    https://bugzilla.redhat.com/show_bug.cgi?id=1972022

:'(

-T


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

___
Please 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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[Matthijs Mekking]

On 15-06-2021 16:32, PGNet Dev wrote:

On 6/10/21 8:38 AM, Tony Finch wrote:

PGNet Dev  wrote:


Has anyone here on-list figured out how to hook bind's internal signing
process to *trigger* and external script to exec those API pushes?


I have not, and I also want to be able to do this, and I also want
scripting hooks for whenever any keys change so that I can stash them
somewhere safer.




Tony.


fyi, @

  automation of DS Record submit to registrar/parent, integrated with 
'new' kasp/dnssec-policy support in bind

   https://gitlab.isc.org/isc-projects/bind9/-/issues/1890

the current feedback is " ... we think the best way is that the user 
scripts this by them self ... "


A brief summary. Folks that are interested in the reasons why can read 
up and discuss here:


  https://gitlab.isc.org/isc-projects/bind9/-/issues/1890#note_220217


and follows with " ... it is more likely that the CDS/CDNSKEY polling 
will be more common than pushing DS updates. A couple of TLDs have 
implemented this already and it looks like there is some movement on 
this topic in the Registrar world."


Of course inaction by TLDs & Registrars has been years-long ...


You may be interested in the multi-signer project, that is now actively 
pushing for this:


  https://github.com/DNSSEC-Provisioning/Multi-signer/

Cheers,

Matthijs




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

___
Please 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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

[Matthijs Mekking]

On 16-06-2021 17:04, PGNet Dev wrote:
@jpmens was kind enough to share the original basis for the simple perl 


He also mentioned

 Logging of CDS/CDNSKEY generation for workflow
  https://gitlab.isc.org/isc-projects/bind9/-/issues/1748

which requests:

 Would it be possible to log CDS/CDNSKEY generation in such a way as 
that a "simple" workflow can be implemented in order to create tooling 
which reacts on the log and performs a dynamic update on a parent zone.
 Whenever a CDS/CDNSKEY is published in a child zone, BIND could 
create a log record indicating for which zone this has occurred.


and appears to have been implemented (?), but not committed/released.


This logging was added in 9.16.7

https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4067
___
Please 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-guide erratum

[Matthijs Mekking]

Hi raf,

On 06-08-2021 16:29, raf via bind-users wrote:

Hi,

I've just read:

 https://bind9.readthedocs.io/en/latest/dnssec-guide.html

(excellent, by the way)


Thanks!


And I've noticed (only!) one typo.

In the "Migrating from NSEC to NSEC3" section, it says:

 dnssec-policy "standard" {
 nsec3param iterations optout no salt-length 16;
 };

There should be an integer after "iterations".

Based on the following text, the number of iterations should be 10.

Should I submit a merge request, or can someone just fix it?


Thanks for reporting.

I created a merge request here: 
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5317


In the future feel free to submit a merge request.

Best regards,

Matthijs




cheers,
raf

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


___
Please 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 questions

[Matthijs Mekking]

Hi raf,

On 09-08-2021 10:08, raf via bind-users wrote:

Hi,

I've got a bunch of DNSSEC questions.
Any advice would be appreciated.

The context is a little VM with six little zones,
soon to be upgraded to debian-11 and bind-9.16.15.
I haven't signed my zones before but now is the time.
I'm going to rotate KSKs annually because it's
finally so easy to on debian stable. Thanks for that.
I know it won't be totally automatic, and that's OK,
but I'd like to check that I have the right idea of
what to monitor for and what to do each time.

Q: Is it OK to use exact multiples for ksk/zsk lifetimes (e.g. 366d/61d)? > 
I assume it's OK if there aren't too many keys to generate at once.


Yes.



Q: Regarding "parent-propagation-delay" and CDS/CDNSKEY RRs:
Assuming the registrar doesn't process them, does this equate to
how long it takes me to notice there's a new DS to upload,
plus how long it takes me to upload it via the registrar's website,
plus how long it takes the registrar to publish the uploaded DS?
Or is it, having instructed the registrar to add/remove a DS,
how long after I've seen it published/withdrawn in the DNS and have
run "rndc dnssec -checkds -key ID published/withdrawn ZONE" that
the parent can be expected to propagate the DS addition/removal
to all their servers? Or does "rndc dnssec -checkds" make
"parent-propagation-delay" irrelevant except when the parent
processes CDS/CDNSKEY RRs? I assume the last.


No, with the latest version of BIND 9.16 you will have either tell named 
that the DS is published with the "rndc dnssec -checkds published" 
command, or you will have to configure parental-agents:


parental-agents lists allow for a common set of parental agents to
be easily used by multiple primary and secondary zones in their
parental-agents lists. A parental agent is the entity that the zone
has a relationship with to change its delegation information
(defined in RFC 7344).


BIND will query the parental agents to see if the new DS is actually
published before withdrawing the old DNSSEC key.



Q: Are CDS/CDNSKEY RRs always in the zone, or just temporarily
there for a short time before and after KSK rollovers?
I don't see them in the wild, so I assume the latter.
I ask for monitoring purposes. What to monitor for withdrawal?
I'm thinking I might want to monitor for DNSKEY additions and
removals instead. More on that below.


While not necessary, CDS and CDNSKEY RRs are always in the zone as long 
as the corresponding DS record is expected to be published.




Q: When would you want a DS RR for a ZSK (i.e. dnssec-dsfromkey -A)?


Never, DS is meant to refer to the key that signs the DNSKEY RRset, thus 
only applicable for KSK.




Q: Any idea why example.com has two KSK DNSKEY RRs?
Might they be mid-rollover at the moment? There's only a DS for one of them.
Perhaps it's just an example.


Most likely a mid-rollover, I will need more details on example.com to 
know for sure.





Q: What software could a registrar use to process CDS/CDNSKEY automatically?
Just curious.


...



Q: Do any/many registrars support CDS/CDNSKEY/RFC7344 yet? It seems not.


No, but I have heard about some registrars looking into it.




Q: Is a "key-directory" option value that doesn't start with "/" relative
to the "directory" option (i.e. a subdirectory)? I assume it is.


The "key-directory" is an optional option that signals that the 
configured "key-directory" should be used. Currently it is the only key 
storage supported, but in the future it may be possible to have per-key 
storage.




Q: Does the signed zone always have a serial that is the serial in the
unsigned zone file plus one? If so, can I continue to use the following
scheme for serials: a 10-digit number consisting of the date followed
by a 2-digit sequence number, where I increment the serial in the zone
file by one whenever I change the zone multiple times on the same day?
e.g.
serial in 1st zone file = 2021091000 signed and published as 202109101
serial in 2nd zone file = 2021091001 signed and published as 202109102
i.e. Is it OK that the never-published serial in a new unsigned zone
file is the same as the previously/currently published serial in the
signed zone? Or is it better to increment the serial in the file by 2
instead of 1?


The serial used depends on the setting of "serial-update-method".



Q: Does the following sound right as a process for managing KSK rollovers?

- Monitor for the appearance of new KSK DNSKEY RRs that bind creates
  (or monitor for the appearance of new CDS RRs)
- Manually upload the DS RRs for the new KSKs via the registrar's website
- Wait for the new DS RRs to appear in the DNS
- Run "rndc dnssec -checkds -key ID published ZONE" to inform bind
- Wait for bind to sign the ZSKs with the new KSKs
- Wait a few TTLs
- Manually d

Deprecating auto-dnssec and inline-signing in 9.18+

[Matthijs Mekking]

Hi users,

We are planning to deprecate the options 'auto-dnssec' and 
'inline-signing' in BIND 9.18. The reason for this is because 
'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.


Deprecating means that you can still use the options in 9.18, but a 
warning will be logged and it is very likely that the options will be 
removed in BIND 9.20.


We would like to encourage you to change your configurations to 
'dnssec-policy'. See this KB article for migration help:


https://kb.isc.org/docs/dnssec-key-and-signing-policy

Do you have reasons for keeping 'inline-signing' or 'auto-dnssec' 
configurations? Is there a use case that is not (yet) covered by 
'dnssec-policy'? Any other concerns? Please let us know.


Best regards,

Matthijs
___
Please 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: Deprecating auto-dnssec and inline-signing in 9.18+

[Matthijs Mekking]

Hi Emannuel,

Thanks for your response.

On 10-08-2021 11:28, FUSTE Emmanuel via bind-users wrote:

Le 10/08/2021 à 10:02, Matthijs Mekking a écrit :

Hi users,

We are planning to deprecate the options 'auto-dnssec' and
'inline-signing' in BIND 9.18. The reason for this is because
'dnssec-policy' is the preferred way of maintaining your DNSSEC zone.

...


Hello,

As today state, it looks to me very premature.
inline-signing and auto-dnssec maintain are about transparent signature
maintenance. > dnssec-policy today is about transparent key 
maintenance/rotation on top
of the engine used by "inline-signing and auto-dnssec maintain"
These are two distinct things for me.


Could you explain what you mean with distinct? You already mention that 
it is "on top of" and to me it is exactly that: the one is the extension 
of the other: 'dnssec-policy' achieves the same things as 'auto-dnssec' 
and 'inline-signing', but is capable of more (key maintenance and 
rollover). So I don't see them as so distinct.



Please add an example showing a dnssec-policy configuration giving the
same result as zone configured with inline-signing and auto-dnssec
maintain : auto signing without automatic key maintenance/rotation. It
should be another default build-in policy ("default-no-auto-rotate" or
something like that).


dnssec-policy "no-auto-rotate" {
keys {
csk lifetime unlimited algorithm 13;
};
};



HSM support for automatic key management, pkcs11 object name mapping,
creation, deletion and more is completely missing from dnssec-policy.


This is a good point. Key creation/deletion inside the HSM for 
dnssec-policy is on the roadmap and must be implemented.




There is even no LTS linux distribution with the open-sc libp11 openssl
engine packaged to be able to use non-deprecated (non native pkcs11)
HSM support.
For now I'm stuck with 9.11 for "on the shelf" pkcs11 support with ISC
bind packages.
With 9.16 packages I'm loosing the pkcs11 support because of lack of
proper version of open-sc libp11 openssl engine in most/all distribs.
Based on the ISC package, I should rebuild it with deprecated native
pkcs11 enabled or try do do a proper packaging of open-sc libp11 openssl
engine. One or the other is on my todo stack for ages but will become
more and more urgent as 9.11 is approaching definitive EOL.
With 9.18, I should  have switched to libp11 engine and use deprecated
'auto-dnssec' and 'inline-signing'.
As today plans, with 9.20 I should abandon HSM usage.


This is planned for Q1 2024. So there is time.

Best regards,
  Matthijs
___
Please 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+

[Matthijs Mekking]

Hi Klaus,

On 10-08-2021 13:38, Klaus Darilion wrote:

Hi Matthijs!

We would like to encourage you to change your configurations to 
'dnssec-policy'. See this KB article for migration help:


https://kb.isc.org/docs/dnssec-key-and-signing-policy


Some comments to this KB article and dnssec-policy:

- The article should mention how to retrieve the DS record from
Bind.


I am not sure what you are asking. Do you mean how to convert the DS
from the DNSKEY record so you can submit it to the registrar?



- How does Bind handle duplicate keyids when generating new keys?
Will Bind ensure that there will not be any duplicate key ideas or
will it just use the duplicate keys? In the latter case the " rndc
dnssec -checkds -key 12345 ..." commands will be ambiguous. (From an
user perspective duplicate keyids should be avoided)


BIND will check for key id collision. When a conflict (for the same
algorithm) is detected a new key will be generated.

Best regards,
  Matthijs




Thanks Klaus


___
Please 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: AW: AW: Deprecating auto-dnssec and inline-signing in 9.18+

[Matthijs Mekking]

Thanks, I got some more suggestions to improve the KB article, I'll 
include yours to that list.


On 10-08-2021 15:28, Klaus Darilion wrote:

On 10-08-2021 13:38, Klaus Darilion wrote:

Hi Matthijs!


We would like to encourage you to change your configurations to
'dnssec-policy'. See this KB article for migration help:

https://kb.isc.org/docs/dnssec-key-and-signing-policy


Some comments to this KB article and dnssec-policy:

- The article should mention how to retrieve the DS record from
Bind.


I am not sure what you are asking. Do you mean how to convert the DS
from the DNSKEY record so you can submit it to the registrar?


Yes. By reading this KB I do not know how the user will be informed which DS 
(or DNSKEY) must be submitted to the parent zone. I know you to convert a 
DNSKEY to DS, but IMO the KB is very good but missest hat point.


- How does Bind handle duplicate keyids when generating new keys?
Will Bind ensure that there will not be any duplicate key ideas or
will it just use the duplicate keys? In the latter case the " rndc
dnssec -checkds -key 12345 ..." commands will be ambiguous. (From an
user perspective duplicate keyids should be avoided)


BIND will check for key id collision. When a conflict (for the same
algorithm) is detected a new key will be generated.


Thanks for the info, could be mentioned somewhere
Klaus


___
Please 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+

[Matthijs Mekking]

On 10-08-2021 15:51, Tim Daneliuk via bind-users wrote:

On 8/10/21 7:51 AM, Matthijs Mekking wrote:

Hi Klaus,

On 10-08-2021 13:38, Klaus Darilion wrote:

Hi Matthijs!


We would like to encourage you to change your configurations to 
'dnssec-policy'. See this KB article for migration help:

https://kb.isc.org/docs/dnssec-key-and-signing-policy


Some comments to this KB article and dnssec-policy:

- The article should mention how to retrieve the DS record from
Bind.



So just to be sure I'm doing the right thing, I've added this to my
options stanza:

 dnssec-policy "default";

Then restarted named and now all the signing magic is taken care of for
me for all zones?  (I was not previously using signing.)


Correct.

But you still need to manually submit the DS record to your 
registrar/parent and if you see the DS published run:


rndc dnssec -checkds published .




TIA,


___
Please 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+

[Matthijs Mekking]

Hi Tim,

On 11-08-2021 04:19, Tim Daneliuk via bind-users wrote:

On 8/10/21 7:32 PM, raf via bind-users wrote:

To get the DS record information to convey to the
registrar, after starting to use the default policy.
look for the CDS record (the child version of the DS
record) with dig:

   dig CDS EXAMPLE.ORG

For the default policy, you'll only have to do this
once (or until your server gets compromised and you
start again). But until you've done this, it's not
done. The trust chain has to go all the way to the
root, so you need the involvement of your registrar
(to get your DS published and signed).



That's quite helpful, thanks, but still unclear about one
thing.  When I run the dig command above I do get a result
back with a "COOKIE" value in the response.  This value
changes each time I run the dig.   Is any one of these the
"DS record" I want to convey to my registrar?

Other than this I see nothing that resembles  a relevant response AND
the COOKIE field does not show up if I do the dig from outside the zone.


Cookies are a different thing, unrelated to DNSSEC:

https://datatracker.ietf.org/doc/html/rfc7873
___
Please 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: AW: Deprecating auto-dnssec and inline-signing in 9.18+

[Matthijs Mekking]

Syntax question:
In https://bind9.readthedocs.io/en/latest/dnssec-guide.html
the double quotes are never used in the zone stanza
where the dnssec-policy is referred to. The double
quotes sometimes (but not always) appear in the
dnssec-policy definition stanza.

Are the double quotes optional in both cases?


Yes, the dnssec-policy defines or refers to a name that is a string, 
which may be a quoted or unquoted string.


Some additional information on the subject: When it comes to strings, 
the named.conf parser expects some options to be quoted strings (usually 
file paths), some options to be unquoted strings (things like algorithm 
and class names), and some options to be just strings (usually names).

___
Please 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: Can't get Bind to publish CDS/CDNSKEY using dnssec-policy

[Matthijs Mekking]

Hi,

On 12-08-2021 09:02, Josef Vybíhal wrote:
Hi, for a second day, I am scratching my head over (automatic) 
publishing CDS/CDNSKEY records. When I read Matthijs Mekkings KB article 
at https://kb.isc.org/docs/dnssec-key-and-signing-policy 
, I wanted to try 
dnssec-policy. Up until now, I successfully was using inline-signing 
with auto-dnssec.


I configured my dnssec-policy to match the current key setting, but I 
probably made a mistake and it did not match it, so a new key was 
generated. No big deal, it's a test domain, rollover is not a problem.


I am sorry, I am afraid you hit a bug: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/2857


The legacy key metadata has no information about the role of keys. It 
determines the role from the key flags: 256 means it is a ZSK, and 257 
is converted to a KSK. In other words, migrating a CSK won't work.


I am working on a fix so that you will be able to migrate CSKs.

For now I have added a warning to the KB article.


Since my TLD supports CDNSKEY, I want to leverage it. So I removed 
current DS record from the domain and expected Bind to publish 
CDS/CDNSKEY 
(https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-cds-and-cdnskey-resource-records 
). 
Unfortunately I can not get bind to automatically publish them. No clue 
why. I kind of expected bind topublish them on PublishCDS: 
20210811135045 (Wed Aug 11 15:50:45 2021) automatically.


The metadata is indeed an indication of when certain events are expected 
to happen. But if BIND determines it is not safe to do so, there may be 
a delay.


From the output below, it looks like not all zone signatures have been 
propagated yet:


>- zone rrsig: rumoured

The PublishCDS metadata is usually set to the the time that the DNSKEY 
has been published, plus dnskey-ttl, zone-propagation-delay, and 
publish-safety. If it is the first key for the zone, the time to 
propagate the zone signatures is taken into account. But in your case 
two other keys already existed.


The PublishCDS metadata can be set more accurately if we can detect that 
none of the other keys have a secure delegation (I think we can).



Best regards,

Matthijs



domain: irmorava.cz 
version: BIND 9.16.19
OS: CentOS 8 Stream + packages from copr.

named.conf:
dnssec-policy "pepa" {
keys {
csk key-directory lifetime unlimited algorithm 13;
};

// Key timings
dnskey-ttl PT1H;
publish-safety PT1H;
retire-safety PT1H;
purge-keys P1D;

// Signature timings
signatures-refresh P5D;
signatures-validity P14D;
signatures-validity-dnskey P14D;

// Zone parameters
max-zone-ttl PT1H;
zone-propagation-delay PT5M;
parent-ds-ttl PT1H;
parent-propagation-delay PT1H;
nsec3param iterations 1 optout false salt-length 16;
};

zone "irmorava.cz " {
type master;
file "master/irmorava.cz.zone";
allow-update { none; };
key-directory "keys/irmorava.cz ";
dnssec-policy pepa;
notify yes;
allow-transfer { pepa_abc; };
};


dig irmorava.cz  @127.0.0.1  
DNSKEY +short +norec
257 3 13 Xsfq5rEgoE+iT+cvq0OZz43MiLiRLeH8SUAEIprn0/J3PNZSYVlCeNuF 
5lfNo6uM0TeApujDhmQ1FPNINKxa2Q==



rndc dnssec -status irmorava.cz 
dnssec-policy: pepa
current time:  Thu Aug 12 08:38:40 2021

key: 22788 (ECDSAP256SHA256), CSK
   published:      yes - since Wed Aug 11 10:20:00 2021
   key signing:    yes - since Wed Aug 11 10:20:00 2021
   zone signing:   yes - since Wed Aug 11 12:25:00 2021

   No rollover scheduled
   - goal:           omnipresent
   - dnskey:         omnipresent
   - ds:             hidden
   - zone rrsig:     rumoured
   - key rrsig:      omnipresent

key: 44055 (ECDSAP256SHA256), CSK
   published:      no
   key signing:    no
   zone signing:   no

   Key has been removed from the zone
   - goal:           hidden
   - dnskey:         hidden
   - ds:             hidden
   - zone rrsig:     unretentive
   - key rrsig:      hidden

key: 35549 (ECDSAP256SHA256), CSK
   published:      no
   key signing:    no
   zone signing:   no

   Key has been removed from the zone
   - goal:           hidden
   - dnskey:         hidden
   - ds:             hidden
   - zone rrsig:     hidden
   - key rrsig:      hidden



/var/named/keys/irmorava.cz/Kirmorava.cz.+013+22788.state 
:

; This is the state of key 22788, for irmorava.cz .
Algorithm: 13
Length: 256
Lifetime: 0
Predecessor: 44055
KSK: yes
ZSK: yes
Generated: 20210811082000 (Wed Aug 11 10:20:00 2021)
Published: 20210811082000 (Wed Aug 11 10:20:00 2021)
Active: 20210811102500 (Wed Aug 11 12:25:00 2021)
DSPublish: 20210811131037 (Wed Aug 11 15:10:37 2021)
DSRemoved: 20210811131020 (Wed Aug 11 15:10:20 2021)
*PublishCDS: 20210811135045 (Wed Aug 11 15:50:45 2021)
*DNSKEYChange: 20210

Re: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes

[Matthijs Mekking]

Hi,

On 16-08-2021 04:28, raf via bind-users wrote:

On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf  wrote:


...


So it's looking good and I'm happy now. But how long
after the zone has been signed can I expect to see
CDS/CDNSKEY RRs appear? Why aren't they created at
the same time as the DNSKEY RRs? I assume there's
a good reason but I can't think what it is.


First the RRsets with signatures need to be in the zone long enough that 
any cached unsigned RRsets in resolver's caches have expired.


If you call 'rndc dnssec -status ' you might see that the "zone 
rrsigs" are still in the "rumoured" state. Once they are omnipresent, 
the DS may be submitted and that is the time when the corresponding 
CDS/CDNSKEY records will be published.




Also, please document the dangers of putting a
dnssec-policy usage directive in the options {} stanza
(unless something signficant has changed since version
9.16.15, and bind now knows not to sign zones that
really shouldn't be signed locally - but even if that's
the case, you could document what version that changed in).


That's a good addition. There are a bunch of other suggestions to 
improve the documentation that I am planning to make and I'll add this 
suggestion to the list. Thanks.




Thanks again for making DNSSEC so easy to implement
(as long as you avoid classic rookie errors). :-)


Thanks for trying it out and reporting back, this way we can improve it 
even more.


Best regards,

Matthijs




cheers,
raf

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


___
Please 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: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes

[Matthijs Mekking]

On 16-08-2021 11:22, raf via bind-users wrote:

On Mon, Aug 16, 2021 at 10:32:35AM +0200, Matthijs Mekking  
wrote:


Hi,

On 16-08-2021 04:28, raf via bind-users wrote:

On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf  wrote:

...


So it's looking good and I'm happy now. But how long
after the zone has been signed can I expect to see
CDS/CDNSKEY RRs appear? Why aren't they created at
the same time as the DNSKEY RRs? I assume there's
a good reason but I can't think what it is.


First the RRsets with signatures need to be in the zone long enough that any
cached unsigned RRsets in resolver's caches have expired.

If you call 'rndc dnssec -status ' you might see that the "zone
rrsigs" are still in the "rumoured" state. Once they are omnipresent, the DS
may be submitted and that is the time when the corresponding CDS/CDNSKEY
records will be published.


Thanks! That makes much sense. I was thinking that it
would be OK to publish the DS sooner when the zone is
signed for the first time. But I get it. I'll trust
bind's sense of timing and be patient. :-)


It is 99% of the time, but there will be corner cases (and dragons).
___
Please 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: bind extended dns error

[Matthijs Mekking]

Reading and parsing EDE is added in June 2020. versions 9.11.20, 9.16.4, 
9.17.2.


Setting EDE is not yet supported. There has been done preliminary work 
to set a few options at the IETF110 Hackathon, but this work hasn't made 
any BIND release yet.


Best regards,

Matthijs

On 07-09-2021 14:35, Sachchidanand Upadhyay via bind-users wrote:

Hi,

   What version of bind is supporting "extended dns error (EDE)"?

   Do i have to do any configuration changes to enable EDE?

   Currently I am running BIND 9.16.18 as recursive server.

BR,
Sachchidanand







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


___
Please 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: Question about "max-zone-ttl" in dnssec-policy

[Matthijs Mekking]

Hi Tom,

The max-zone-ttl is there to calculate the right timings for key 
rollovers. It won't alter the zone TTL values.


You should set the max-zone-ttl to whatever the highest TTL is in your 
zone to make sure key rollovers timings are correct.


This value exists until we have added code to the key manager that will 
read the zone's contents and detect the maximum TTL automatically.


I hope this clarifies things.

Best regards,

Matthijs


On 20-09-2021 17:47, Tom wrote:

Hi list

Testing dnssec-policy with BIND-9.16.21:

I'd like to better understand the "max-zone-ttl"-directive.
So I defined "max-zone-ttl 3600s;" within the dnssec-policy-options, but 
when I configure the default zone TTL or even a ressource record TTL 
higher than the "max-zone-ttl" (for example to 7200s), then it's not 
capped, as described in the documentation.


Look here:
- Within the dnssec-policy, I've defined "max-zone-ttl 3600;"
- The RR "www.example.com." has a TTL of 7200
- The server returns a TTL of 7200

$ dig @192.168.1.10 www.example.com +dnssec +multi
...
...
;; ANSWER SECTION:
www.example.com.    7200 IN A 127.0.0.1
www.example.com.    7200 IN RRSIG A 13 3 7200 (
     20211002202425 20210920143830 42786 example.com.
     3cprtWPAOwEuUvaiV5DKYWxhJHrdU6FL7Jk2+aNavOao
     lTzQMKev2OF6TqPhXXfaHANIz+tiVhZaeaDCDagkSA== )
...
...


What do I misunderstand here?

Many thanks for a hint.

Kind regards,
Tom
___
Please 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

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

Fwd: Question about "max-zone-ttl" in dnssec-policy

[Matthijs Mekking]

Apologies, it appears that I sent this reply to Tom directly.

 Forwarded Message 
Hi Tom,

That seems to be a copy paste error yes. Thanks for catching, will fix.

There is another max-zone-ttl option that is used to cap TTLs of records 
added via dynamic updates.


Best regards,

Matthijs


On 21-09-2021 15:11, Tom wrote:

Hi Matthijs

Thank you for your explanation.

The documentation says, that "any record encountered with a TTL higher 
than max-zone-ttl is capped at the maximum permissible TTL value".


Is the documentation wrong here?

Thank you.
Kind regards,
Tom



On 21.09.21 09:47, Matthijs Mekking wrote:

Hi Tom,

The max-zone-ttl is there to calculate the right timings for key 
rollovers. It won't alter the zone TTL values.


You should set the max-zone-ttl to whatever the highest TTL is in your 
zone to make sure key rollovers timings are correct.


This value exists until we have added code to the key manager that 
will read the zone's contents and detect the maximum TTL automatically.


I hope this clarifies things.

Best regards,

Matthijs


On 20-09-2021 17:47, Tom wrote:

Hi list

Testing dnssec-policy with BIND-9.16.21:

I'd like to better understand the "max-zone-ttl"-directive.
So I defined "max-zone-ttl 3600s;" within the dnssec-policy-options, 
but when I configure the default zone TTL or even a ressource record 
TTL higher than the "max-zone-ttl" (for example to 7200s), then it's 
not capped, as described in the documentation.


Look here:
- Within the dnssec-policy, I've defined "max-zone-ttl 3600;"
- The RR "www.example.com." has a TTL of 7200
- The server returns a TTL of 7200

$ dig @192.168.1.10 www.example.com +dnssec +multi
...
...
;; ANSWER SECTION:
www.example.com.    7200 IN A 127.0.0.1
www.example.com.    7200 IN RRSIG A 13 3 7200 (
 20211002202425 20210920143830 42786 example.com.
 3cprtWPAOwEuUvaiV5DKYWxhJHrdU6FL7Jk2+aNavOao
 lTzQMKev2OF6TqPhXXfaHANIz+tiVhZaeaDCDagkSA== )
...
...


What do I misunderstand here?

Many thanks for a hint.

Kind regards,
Tom
___
Please 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

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

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

___
Please 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 questions

[Matthijs Mekking]

Hi Allesandro,

Your policy has three keys:

   keys {
   ksk key-directory lifetime unlimited algorithm rsasha256 2048;
   zsk key-directory lifetime unlimited algorithm rsasha256 2048;
   csk key-directory lifetime unlimited algorithm rsasha256 2048;
   };

Two of them require DS records (ksk and csk), so that is why you have 
double CDS/CDNSKEY records.


On 27-10-2021 12:54, Alessandro Vesely wrote:

Hi all,

I recently installed version 9.16, and have a number of doubts.  During 
the upgrade, named didn't want to load signed zones because of 
CDS/CDNSKEY inconsistency.  There were CDS records in the zone files, 
which I removed.


I also switched to dnssec-policy.  Somewhere I read that I should have 
defined a policy with keys matching the existing keys.  I also defined a 
"combined" key.  Now I have two DS, two CDS, and two CDNSKEY RRs.  I 
attach a picture of a zone and paste the policy below.


Adding the combined key to the policy means you did not create a policy 
that matched the existing keys. BIND notices that you want three keys, 
you only have two, so it creates the CSK.




The questions:

1. Now, how do I get rid of the extra ksk and zsk?  Is it enough to 
remove them from the policy?


You can remove them from the policy yes, but make sure the migration is 
complete. You can check with "rndc dnssec -status " and make sure 
that your key states are in "omnipresent".



2. I have double CDS/CDNSKEY records, but they're not in the zone 
files.  Do I have to run rndc dnssec -checkds to remove them?


That's because you added the additional CSK to the policy. It is 
probably best to remove it again from the policy and only change the 
policy if the migration is complete.



3. The server produces new .signed and .signed.jnl files every day, 
which is inconvenient as the zone files directory is checked by 
tripwire.  Is that timing determined by the dnskey-ttl?  Would it be 
okay to set it to one month?


The zone is signed if a signature is about to expire. It is not 
determined by dnskey-ttl. I would exclude these files from tripwire 
because they need to written out anyway.



4. Is rndc managed-keys status supposed to display anything meaningful, 
given my setup?  It talks about a non-existing key id.  The sync option 
produces no output at all.  How do I know the overall dnssec status?


"rndc managed-keys status" is for trust anchors, use "rndc dnssec 
-status " instead.



Best regards,

Matthijs



Here's my policy setting:

dnssec-policy "explicit" {
 // Keys
 keys {
     ksk key-directory lifetime unlimited algorithm rsasha256 2048;
     zsk key-directory lifetime unlimited algorithm rsasha256 2048;
     csk key-directory lifetime unlimited algorithm rsasha256 2048;
 };

 nsec3param iterations 1 optout false salt-length 16;

 // Key timings
 dnskey-ttl 86400;
 publish-safety P3W;
 retire-safety P3W;
 purge-keys P1Y;

 // Signature timings
 signatures-refresh P2M;
 signatures-validity P6M;
 signatures-validity-dnskey P6M;

 // Zone parameters
 max-zone-ttl 86400;
 zone-propagation-delay PT1H;

 // Parent parameters
 parent-ds-ttl 86400;
 parent-propagation-delay PT1H;
};


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


___
Please 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 questions

[Matthijs Mekking]

On 27-10-2021 18:48, Alessandro Vesely wrote:
3. The server produces new .signed and .signed.jnl files every day, 
which is inconvenient as the zone files directory is checked by 
tripwire.  Is that timing determined by the dnskey-ttl?  Would it be 
okay to set it to one month?


The zone is signed if a signature is about to expire. It is not 
determined by dnskey-ttl. I would exclude these files from tripwire 
because they need to written out anyway.



Then, why does it have to rewrite it every day, if the zone didn't 
change? dnskey-ttl is the only one-day timing thing, except parent-ds-ttl.


It shouldn't. It should only rewrite if there are changes, for example 
due to zone updates or due to resigning.



BTW, DS RR has a ttl of 10800 at the parent; should I copy that to 
parent-ds-ttl in my policy definition?


Yes.

> What for?

To make sure the key rollovers are timed correctly.

In addition, I took a closer look at your policy.

publish-safety P3W;
retire-safety P3W;

The publish-safety and retire-safety are intended to be small margins 
added to rollover timings to give some extra time to cover unforeseen 
events. The defaults are 1 hour. Maybe you have good reasons to set them 
to 3 weeks, but it is remarkably long.



Best regards,

Matthijs
___
Please 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-policy is not signing anymore

[Matthijs Mekking]

Hi Tom,

On 29-11-2021 09:36, Tom wrote:

Hi

Using BIND-9.16.22:
After some tests with the new KASP feature, I'm running in a issue, 
where BIND isn't signing the zone anymore.


In the old fashion way (auto-dnssec maintain;), I was able - under some 
circumstances - to remove the ".signed" and ".signed.jnl" and 
.jnl-files, restart BIND and everything was fine, the zone was signed 
automatically with the existing keys.


In the special case now, I removed the ZSK key files and removed all 
.signed and .signed.jnl and .jnl-files for a zone (like in the old way). 
The KSK is still existing, a new ZSK is created through the 
"dnssec-policy":


The dnssec-policy checks the key files against the policy. If you remove 
the ZSK key files, it has no ZSK any longer while the policy dictates 
so. That's why it will create a new ZSK.


In other words, don't remove your key files.

(Removing .signed and .jnl files should be fine and be recreated).


## BIND detects the already existing KSK, but logs a warning the the KSK 
is missing or inactive.
29-Nov-2021 07:28:25.653 dnssec: info: keymgr: DNSKEY 
example.ch/ECDSAP256SHA256/27534 (ZSK) created for policy thewaytogo-faster
29-Nov-2021 07:28:25.654 dnssec: info: Fetching 
example.ch/ECDSAP256SHA256/61416 (KSK) from key repository.
29-Nov-2021 07:28:25.654 dnssec: info: DNSKEY 
example.ch/ECDSAP256SHA256/61416 (KSK) is now published
29-Nov-2021 07:28:25.654 dnssec: info: DNSKEY 
example.ch/ECDSAP256SHA256/61416 (KSK) is now active
29-Nov-2021 07:28:25.654 dnssec: info: Fetching 
example.ch/ECDSAP256SHA256/27534 (ZSK) from key repository.
29-Nov-2021 07:28:25.654 dnssec: info: DNSKEY 
example.ch/ECDSAP256SHA256/27534 (ZSK) is now published
29-Nov-2021 07:28:25.654 general: info: CDS for key 
example.ch/ECDSAP256SHA256/61416 is now published
29-Nov-2021 07:28:25.654 general: info: CDNSKEY for key 
example.ch/ECDSAP256SHA256/61416 is now published
29-Nov-2021 07:28:25.659 dnssec: info: zone example.ch/IN (signed): next 
key event: 29-Nov-2021 09:33:25.641
29-Nov-2021 07:28:25.660 general: warning: zone example.ch/IN (signed): 
Key example.ch/ECDSAP256SHA256/61416 missing or inactive and has no 
replacement: retaining signatures.


I am not able to reproduce this. Is this after a restart or a reload?

Perhaps it's better to report an issue on our gitlab:

https://gitlab.isc.org/isc-projects/bind9/-/issues/new

Please provide the steps to reproduce and logs with debug level 3.

Best regards,
  Matthijs




## But the KSK (61416) is existing and seems signing
$ rndc dnssec -status example.ch
dnssec-policy: thewaytogo-faster
current time:  Mon Nov 29 09:10:42 2021

key: 61416 (ECDSAP256SHA256), KSK
   published:  yes - since Tue Oct 12 16:50:17 2021
   key signing:    yes - since Tue Oct 12 16:50:17 2021

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
   - ds: omnipresent
   - key rrsig:  omnipresent

key: 27534 (ECDSAP256SHA256), ZSK
   published:  yes - since Mon Nov 29 07:28:25 2021
   zone signing:   no

   Next rollover scheduled on Mon Dec  6 05:23:25 2021
   - goal:   omnipresent
   - dnskey: rumoured
   - zone rrsig: hidden



So, BIND detects the already existing KSK and ZSK, but is not able to 
sign the dnskey-rrset with the KSK or some TXT-records with the ZSK.



## DNSKEY RR are existing, the RRSIG is missing
$ dig +short @127.0.0.1 +norec +dnssec dnskey example.ch
256 3 13 3YU6kADe6IRhJ2rcmHOrPgH6tq/7PQQP7VpLBA70p/bPQFPRagdxuGdl 
XrDg7tQ9WTr553BA5dUGqRBEYYQTUw==
257 3 13 bT4QClt+P9+t1+vF/Ulj7DSISBVMV86TktfNqheiUVGqfZ2hsEpYP140 
flVurgV17M/nzujoMW0KgyTuP3p4Kw==



The dnssec-policy looks like this:
dnssec-policy "thewaytogo-faster" {
     signatures-refresh 5d;
     signatures-validity 14d;
     signatures-validity-dnskey 14d;
     dnskey-ttl 3600s;
     publish-safety 1h;
     retire-safety 1h;
     purge-keys 30d;
     keys {
     ksk lifetime unlimited algorithm ecdsap256sha256;
     zsk lifetime 7d algorithm ecdsap256sha256;
     };
     zone-propagation-delay 300s;
     max-zone-ttl 86400s;
     parent-propagation-delay 1h;
     parent-ds-ttl 3600;
};



When running "rndc sign example.ch", then nothing happens -> I'm not 
sure, if "rndc sign" is still possible with "dnssec-policy"...?


Any hints, how I can recover this state to a working signing-state 
without recreating a new KSK?
I assume, that disabling DNSSEC completely and creating a new ZSK/KSK 
will work, but in the case now, I already have the mentioned KSK (61416).


Thank you.
Kind regards,
Tom
___
Please 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: ds showing hidden 3+ days after key roll

[Matthijs Mekking]

Hi Larry,

Without more information it is hard to tell what is going on.

Can you share your dnssec-policy and the contents of the key state file? 
And if you have useful logs (grep for keymgr) that would be handy too to 
see what is going on.


If you prefer to share them off list, you can mail them me directly.

Best regards,

Matthijs

On 08-02-2022 18:00, Larry Rosenman wrote:

Greetings,
     new poster.  I just converted over to DNSSEC-policy,  and rolled my 
KSK.  I see:

key: 269 (RSASHA256), KSK
   published:  yes - since Sun Feb  6 14:31:32 2022
   key signing:    yes - since Sun Feb  6 14:31:32 2022

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
   - ds: hidden
   - key rrsig:  omnipresent


ler in thebighonker in namedb🔒 on  master [!] as 🧙
❯

Is it normal to see the ds as hidden?  It IS published, and I told rndc 
that.


Any insight appreciated.


--
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: ds showing hidden 3+ days after key roll

[Matthijs Mekking]

Hi Larry,

There has been several bug fixes for dnssec-policy since its 
introduction. What version of 9.17 are you running?


I can't tell what causes the ds to stay in the hidden state. The timings 
in the state file should allow it to move to the next state.


If you were able to turn on logging, on each run the keymgr will tell 
you the reason why it cannot move the DS to the next state. Such logs 
happen on DEBUG(1) level.


Best regards,

Matthijs



On 09-02-2022 17:35, Larry Rosenman wrote:

On 02/09/2022 9:52 am, Matthijs Mekking wrote:

Hi Larry,

Without more information it is hard to tell what is going on.

Can you share your dnssec-policy and the contents of the key state
file? And if you have useful logs (grep for keymgr) that would be
handy too to see what is going on.

If you prefer to share them off list, you can mail them me directly.

Best regards,

Matthijs

On 08-02-2022 18:00, Larry Rosenman wrote:

Greetings,
 new poster.  I just converted over to DNSSEC-policy,  and rolled 
my KSK.  I see:

key: 269 (RSASHA256), KSK
   published:  yes - since Sun Feb  6 14:31:32 2022
   key signing:    yes - since Sun Feb  6 14:31:32 2022

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
   - ds: hidden
   - key rrsig:  omnipresent


ler in thebighonker in namedb🔒 on  master [!] as 🧙
❯

Is it normal to see the ds as hidden?  It IS published, and I told 
rndc that.


Any insight appreciated.



thebighonker# cat Klerctr.org.+008+00269.state
; This is the state of key 269, for lerctr.org.
Algorithm: 8
Length: 2048
Lifetime: 0
Predecessor: 20014
KSK: yes
ZSK: no
Generated: 20220206203132 (Sun Feb  6 14:31:32 2022)
Published: 20220206203132 (Sun Feb  6 14:31:32 2022)
Active: 20220206213632 (Sun Feb  6 15:36:32 2022)
DSPublish: 20220207015646 (Sun Feb  6 19:56:46 2022)
PublishCDS: 20220206223632 (Sun Feb  6 16:36:32 2022)
DNSKEYChange: 20220206223632 (Sun Feb  6 16:36:32 2022)
KRRSIGChange: 20220206223632 (Sun Feb  6 16:36:32 2022)
DSChange: 20220206203132 (Sun Feb  6 14:31:32 2022)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
thebighonker#

dnssec-policy "ler1" {
    keys {
    ksk lifetime unlimited algorithm 8 2048 ;
    zsk lifetime 30d algorithm 13;
    };
    // Key timings
    dnskey-ttl 3600;
    publish-safety 1h;
    retire-safety 1h;
    purge-keys P90D;
    // Signature timings
    signatures-refresh 5d;
    signatures-validity 14d;
    signatures-validity-dnskey 14d;
    // Zone parameters
    max-zone-ttl 86400;
    zone-propagation-delay 300;
    // Parent parameters
    parent-ds-ttl 86400;
    parent-propagation-delay 1h;
    nsec3param iterations 0 salt-length 0;
};

Unfortunately my 9.17(alpha) named got into a signing loop, so I don't 
want to look through that logging.


I know -- I need to update to 9.18, but am waiting on the FreeBSD port 
maintainer to add 9.18 to the ports tree

--
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: ds showing hidden 3+ days after key roll

[Matthijs Mekking]

8 dnssec: debug 1: keymgr: dnssec 
evaluation of KSK lerctr.org/RSASHA256/269 record DS: rule1=(~false or 
true) rule2=(~true or true) rule3=(~true or false)
<183>1 2022-02-09T02:18:28.588453-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: dnssec says 
no to KSK lerctr.org/RSASHA256/269 type DS state HIDDEN to state RUMOURED


ler in thebighonker in ~ via ☕ v1.8.0 via 🐪 v5.32.1 via 💎 v2.7.5 as 🧙
❯

On 02/10/2022 6:20 am, Matthijs Mekking wrote:

Hi Larry,

There has been several bug fixes for dnssec-policy since its
introduction. What version of 9.17 are you running?

I can't tell what causes the ds to stay in the hidden state. The
timings in the state file should allow it to move to the next state.

If you were able to turn on logging, on each run the keymgr will tell
you the reason why it cannot move the DS to the next state. Such logs
happen on DEBUG(1) level.

Best regards,

Matthijs



On 09-02-2022 17:35, Larry Rosenman wrote:

On 02/09/2022 9:52 am, Matthijs Mekking wrote:

Hi Larry,

Without more information it is hard to tell what is going on.

Can you share your dnssec-policy and the contents of the key state
file? And if you have useful logs (grep for keymgr) that would be
handy too to see what is going on.

If you prefer to share them off list, you can mail them me directly.

Best regards,

Matthijs

On 08-02-2022 18:00, Larry Rosenman wrote:

Greetings,
 new poster.  I just converted over to DNSSEC-policy,  and 
rolled my KSK.  I see:

key: 269 (RSASHA256), KSK
   published:  yes - since Sun Feb  6 14:31:32 2022
   key signing:    yes - since Sun Feb  6 14:31:32 2022

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
   - ds: hidden
   - key rrsig:  omnipresent


ler in thebighonker in namedb🔒 on  master [!] as 🧙
❯

Is it normal to see the ds as hidden?  It IS published, and I told 
rndc that.


Any insight appreciated.



thebighonker# cat Klerctr.org.+008+00269.state
; This is the state of key 269, for lerctr.org.
Algorithm: 8
Length: 2048
Lifetime: 0
Predecessor: 20014
KSK: yes
ZSK: no
Generated: 20220206203132 (Sun Feb  6 14:31:32 2022)
Published: 20220206203132 (Sun Feb  6 14:31:32 2022)
Active: 20220206213632 (Sun Feb  6 15:36:32 2022)
DSPublish: 20220207015646 (Sun Feb  6 19:56:46 2022)
PublishCDS: 20220206223632 (Sun Feb  6 16:36:32 2022)
DNSKEYChange: 20220206223632 (Sun Feb  6 16:36:32 2022)
KRRSIGChange: 20220206223632 (Sun Feb  6 16:36:32 2022)
DSChange: 20220206203132 (Sun Feb  6 14:31:32 2022)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
thebighonker#

dnssec-policy "ler1" {
    keys {
    ksk lifetime unlimited algorithm 8 2048 ;
    zsk lifetime 30d algorithm 13;
    };
    // Key timings
    dnskey-ttl 3600;
    publish-safety 1h;
    retire-safety 1h;
    purge-keys P90D;
    // Signature timings
    signatures-refresh 5d;
    signatures-validity 14d;
    signatures-validity-dnskey 14d;
    // Zone parameters
    max-zone-ttl 86400;
    zone-propagation-delay 300;
    // Parent parameters
    parent-ds-ttl 86400;
    parent-propagation-delay 1h;
    nsec3param iterations 0 salt-length 0;
};

Unfortunately my 9.17(alpha) named got into a signing loop, so I 
don't want to look through that logging.


I know -- I need to update to 9.18, but am waiting on the FreeBSD 
port maintainer to add 9.18 to the ports tree



--
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: ds showing hidden 3+ days after key roll

[Matthijs Mekking]

Hi Larry,

This is documented in the DNSSEC RFCs, but AFAICS it is not mentioned in 
our documentation. I created a merge request to add such a note in the 
appropriate places:


https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5823

Best regards,

Matthijs

On 10-02-2022 18:23, Larry Rosenman wrote:

On 02/10/2022 10:10 am, Matthijs Mekking wrote:

Hi,

There are several things wrong here. The gist of it is that there is
no valid ZSK and since the zone is not properly signed, BIND does not
want to publish the DS record (even if outside BIND you already
published the DS).

You can tell that BIND does not agree because it did not publish a CDS
record in your zone.

I also noticed two different algorithms. I hadn't noticed it before
but your policy says:

    keys {
    ksk lifetime unlimited algorithm 8 2048 ;
    zsk lifetime 30d algorithm 13;
    };

This is a garbage policy because you specify different algorithms for
the ksk and the zsk. This can never result in a validly signed zone.

Change the algorithm of the keys so that they match.

Perhaps we can add a named-checkconf check for this.


Best regards,

Matthijs


[snip]

Thanks!   Is that little nuance documented?  (The need for KSK and ZSK 
to be aligned on type of key)



--
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: Changing ZSK-lifetime in dnssec-policy is not applied

[Matthijs Mekking]

Hi Tom,

The lifetime is applied to new keys, so when the ZSK is rolled the 
lifetime of the successor key should be 60 days.


I have considered applying it to existing keys as well (and maybe we 
will some day), but there are a bunch of corner cases that make it 
non-trivial, especially when keys are involved that are in the middle of 
a rollover.


Best regards,
  Matthijs

On 11-02-2022 13:16, Tom wrote:

Hi

Using BIND-9.16.22 and dnssec-policy:

I've migrated an already existing and signing "auto-dnssec"-configured 
zone to dnssec-policy (same algorithms). That worked without any issues. 
After a while, I changed the ZSK lifetime from 30d to 60d (see below) in 
the dnssec-policy:


dnssec-policy "thewaytogo" {
     signatures-refresh 5d;
     signatures-validity 14d;
     signatures-validity-dnskey 14d;

     dnskey-ttl 3600s;
     publish-safety 1h;
     retire-safety 1h;
     purge-keys 10d;

     keys {
     ksk lifetime unlimited algorithm ecdsap256sha256;
     zsk lifetime 60d algorithm ecdsap256sha256;
     };

     zone-propagation-delay 300s;
     max-zone-ttl 86400s;

     parent-propagation-delay 1h;
     parent-ds-ttl 3600;
     nsec3param iterations 0 optout no salt-length 0;
};


After reloading/restarting named, I can't see the new lifetime 
(scheduled rollover), neither in the rndc-output, nor in the keyfile 
itself (ZSK 63304). The new lifetime should be 12/13 Apr and not 13 Mar.


# rndc-output
$ rndc dnssec -status example.com
dnssec-policy: thewaytogo
current time:  Fri Feb 11 13:02:10 2022

key: 455 (ECDSAP256SHA256), ZSK
   published:  yes - since Wed May 20 14:50:09 2020
   zone signing:   no

   Key is retired, will be removed on Mon Jun 29 15:55:09 2020
   - goal:   hidden
   - dnskey: omnipresent
   - zone rrsig: unretentive

key: 63304 (ECDSAP256SHA256), ZSK
   published:  yes - since Fri Feb 11 08:19:18 2022
   zone signing:   yes - since Fri Feb 11 09:24:18 2022

   Next rollover scheduled on Sun Mar 13 07:19:18 2022
   - goal:   omnipresent
   - dnskey: omnipresent
   - zone rrsig: rumoured

key: 39500 (ECDSAP256SHA256), KSK
   published:  yes - since Wed May 20 14:50:09 2020
   key signing:    yes - since Wed May 20 14:50:09 2020

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
   - ds: omnipresent
   - key rrsig:  omnipresent



# key-file
; This is the state of key 63304, for example.com.
Algorithm: 13
Length: 256
Lifetime: 2592000
Predecessor: 455
KSK: no
ZSK: yes
Generated: 20220211071918 (Fri Feb 11 08:19:18 2022)
Published: 20220211071918 (Fri Feb 11 08:19:18 2022)
Active: 20220211082418 (Fri Feb 11 09:24:18 2022)
Retired: 20220313082418 (Sun Mar 13 09:24:18 2022)
Removed: 20220323092918 (Wed Mar 23 10:29:18 2022)
DNSKEYChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
ZRRSIGChange: 20220211092418 (Fri Feb 11 10:24:18 2022)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
GoalState: omnipresent



Any hints for this?

Many thanks.

Best regards,
Tom

--
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: Changing the DNSSEC algorithm

[Matthijs Mekking]

Hi,

BIND 9.16 has dnssec-policy that makes algorithm rollover much easier. I 
recommend you start using that.


Read more on migrating to dnssec-policy here:

  https://kb.isc.org/docs/dnssec-key-and-signing-policy


Best regards,

Matthijs



On 06-04-2022 21:47, Danilo Godec via bind-users wrote:

I read several articles regarding algorithm rollover, including:

* https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

* 
https://downloads.isc.org/isc/bind9/9.16.6/doc/arm/html/advanced.html#dnssec-dynamic-zones-and-automatic-signing


Unfortunately I can't find all of them in my browser history...


For re-signing I have a Bash script running once a month through cron.


With only a few zones to manage I think I'll stick with the simple way 
of editing them by hand.



  Thanks for your thoughts,

     Danilo


On 6.4.2022 13:18, Petr Menšík wrote:


Hi Danilo,

I think the way you have describe should work. But can I ask what 
source this recipe has? I have seen recently similar signing in one of 
our test. I guess this should be from public recipe. Would you share 
its origin, please?


I would recommend having DNS server do the job of maintaining 
signatures. If you do it this way manually, you have to resign your 
zone each time your signatures expire. Do you have set some kind of 
reminder to remind you?


I would try DNSSEC guide [1] with bind 9.16 or more recent. It 
provides a policy inside named. It depends on what version do you 
have. Even 9.11 can maintain signatures [2] and resign them, but the 
process is more complicated. You would have to just regenerate keys, 
otherwise it will maintain your signatures. But yes, it won't be able 
to edit zone file by hand this way.


Read dnssec-settime manual page and way to set times, when each key 
should be activated or deactivated. It should be more safe if done the 
right way. You can use dnssec-signzone -S to use smart signing and 
then omit step 2. Just provide correct directory to keys. But I admit 
it might be simpler to do it manually if you would upgrade just single 
zone, which has no high impact in case of error.


Btw. it seems really clumsy to read 1000 characters from proper 
entropy source and then use just 16 hexcoded chars from it. 
/dev/urandom might be better source and 16 bytes should be enough.


Regards,
Petr

1. https://bind9.readthedocs.io/en/v9_16_27/dnssec-guide.html

2. 
https://ftp.isc.org/isc/bind9/cur/9.11/doc/arm/Bv9ARM.ch04.html#dnssec.dynamic.zones


On 4/5/22 09:07, Danilo Godec via bind-users wrote:


Hello,


I implemented DNSSEC for my personal domain a good while ago with an 
older Bind and back then, I used RSASHA1-NSEC3-SHA1 algorithm, which 
by now is not recommended... So I'm going to change the algorithm, 
probably to ECDSAP256SHA256, which should also be NSEC3 capable.


Since my domain is small and rarely changes, I'm not using any fancy 
updating features - I manage it manually, by editing the non-signed 
version of the zone file and then signing it to create a signed version.



Here I'd like to verify that I understand the steps required to 
change DNSEC key / algorithm without disruption:



1. create new keys for my zone

  * dnssec-keygen -a ECDSAP256SHA256 -n ZONE mydomain
  * dnssec-keygen -f KSK -a ECDSAP256SHA256 -n ZONE mydomain


2. include new keys in my zone while keeping old keys too:

    $INCLUDE Kmydomain.+008+14884.key <- old key
    $INCLUDE Kmydomain.+008+27618.key <- old key
    $INCLUDE Kmydomain.+013+10503.key <- new key
    $INCLUDE Kmydomain.+013+39532.key <- new key


3. sign the zone file

    /usr/sbin/dnssec-signzone -A -3 $(head -c 1000 /dev/random | 
sha1sum | cut -b 1-16) -e +3024000 -o mydomain -t mydomain.hosts



4. ask the registrar to add new DS record to TLD (I have to do this 
by mail, there is no 'self-service' UI)


5. wait at least one TTL (making sure to use the longest TTL in my zone)

6. ask the registrar to remove old DS record(s) (I don't quite 
remember why, but I had two)


7. wait another TTL period

8. remove old keys from zone

9. re-sign the zone


Will that be OK?


   Best regards,

 Danilo




--
Petr Menšík
Software Engineer
Red Hat,http://www.redhat.com/
email:pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



--
Danilo Godec | Sistemska podpora / System Administration
AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
E: danilo.go...@agenda.si | T: +386 (0)2 421 61 31 | F: +386 (0)2 420 06 90
Agenda OpenSystems  | Največji slovenski 
odprtokodni integrator
Red Hat v Sloveniji  | Red Hat Premier Business 
Partner

ElasticBox  | Poslovne rešitve v oblaku
Agenda d.o.o. 
Izjava o omejitvi odgovornosti / Legal disclaimer statement 





--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the developm

Re: Signatures expired?

[Matthijs Mekking]

Hi,

On 10-04-2022 19:46, @lbutlr via bind-users wrote:

In the process of setting u a new domain I noticed that some existing domains 
are logging and error into /var/log/messages

domain.tld.signed:120: signature has expired

Each domain that is expired shows the same :120

The lines in question do refer to old ALG-7 signatures but shouldn’t those go 
away from the signed file (O've been using ALG 13 for a couple of years.


This is too little information to figure out what is going on.

In order to help you investigate this issue, you would need at least 
have to post your configuration, and perhaps also more log lines, the 
steps you have made to set up the new domain. You may mail them in private.


Best regards,

Matthijs


--
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: How to prevent gratuitous publication of CDS/CDNSKEY records

[Matthijs Mekking]

Hi Niall,

On 14-04-2022 13:59, Niall O'Reilly wrote:

Hi.

Clue needed, please.

I’ve managed to migrate a number of zones from cron-driven signing
using homegrown scripts to automatic management by named, while
retaining the respective original KSK for each.

Following migration, ZSK:s have been replaced as might be expected,
since the keys were shorter than is nowadays recommended.
The old ZSK files are still lingering in the key-directory.


Keys will be purged after the 'purge-keys' interval, which by default is 
90 days after they have been removed from the zone.



I’m seeing that fresh CDS and CDNSKEY are being generated, and
wonder why, as the CDS RDATA matches the parent CD RDATA. I’ve
deleted these using nsupdate, only to find them re-inserted
some time later.


If you use dnssec-policy, you leave the DNSSEC signing to BIND. It 
inserts CDS and CDNSKEY records of the keys that require a DS in the parent.


Note that those records may be removed once the parent has the 
corresponding DS published, but these records may also stay in the zone. 
BIND chooses to keep them in the zone, so that it is clear which DS is 
expected at the parent from the child zone's perspective.




Could it be significant that the parent DS TTL differs from that
of the local CDS?


No.

Best regards,

Matthijs



One of the zones involved is foo.ie.

The server is running BIND 9.16.27-Ubuntu, installed from ppa:isc/bind.

Here below is the relevant dnssec-policy configuration fragment.

|dnssec-policy persistent { // This policy attempts to match or 
accommodate what zonefactory did // and gives keys unrestricted lifetime 
dnskey-ttl 3600; keys { ksk lifetime unlimited algorithm rsasha256; zsk 
lifetime unlimited algorithm rsasha256; }; max-zone-ttl 3600; 
parent-ds-ttl 86400; parent-propagation-delay 48h; publish-safety 7d; 
retire-safety 7d; signatures-refresh 5d; signatures-validity 30d; 
signatures-validity-dnskey 30d; zone-propagation-delay 2h; }; |


Thanks in anticipation.

Niall



--
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-policy makes BIND touch all key files every hour

[Matthijs Mekking]

Hi,

To be precise, BIND updates the key files each keymgr run. But If the 
keymgr waits for an event (rather than a duration), it will retry every 
refresh key interval, which defaults to an hour.


You can check the logs for "next key event" to see when the keymgr is 
scheduled next.


But yes, each time the keymgr runs for a zone, the key files are written 
out for that zone. You are right that this is unnecessary. I have 
created a GitLab issue for this to fix it.


https://gitlab.isc.org/isc-projects/bind9/-/issues/3302

Best regards,

Matthijs


On 25-04-2022 18:49, Laurent Frigault wrote:

On Sun, Apr 24, 2022 at 11:58:44AM +0200, Bjørn Mork wrote:
Hello,
  

I recently moved a few zones from "auto-dnssec maintain" to
"dnssec-policy ..." to prepare for simpler/automatic key rotation in the
future.

For the time being I have configured my policy with separate KSK and ZSK
and unlimited key life times to replicate the old setup as closely as
possible.  I also had a few old and outdated keys lying around, and
would like to keep those, so my policy has "purge-keys 0".  All other
policy settings are default.

The setup is mostly working as expected - which is great.  But there is
one issue which has suprised me, and which is slightly annoying since it
tends to set off a few security warnings:  All the key related files are
now touched by BIND once an hour, whether they are modified or not.
Which they obviously nevery should be, given my current policy.


I discover the same issue with bind 9.16.27 and FreeBSD 13.0
  

This is particularily surprising wrt the deleted keys. But it's equally
unnecessary with the current keys. And touching those is actually more
annoying since it's an unexpected file system operation with real
security implications.  Or at least it feels that way...


My test server run only a few zones and only one with dnssec-policy but
I have a production serveur with more than 70 000 zones. This issue
would generate avec very high IO load on such server.


Is this expected or am I doing something wrong?  And if this is
expected, then why?


Good question.


--
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-policy makes BIND touch all key files every hour

[Matthijs Mekking]

Bjørn,

Perhaps you hit another quirk in the migration. I'll try to explain what 
is happening, or what is supposed to happen.


When migrating to dnssec-policy, there are no state files. BIND tries to 
deduce the state from the timing metadata and the durations from 
dnssec-policy.


For the DS, BIND examines the "SyncPublish" time and checks it against 
the current time (when migrating). If enough time has passed since 
"SyncPublish" the "DSState" will be set to "omnipresent", otherwise it 
will be "rumoured":


if (syncpub <= now && ret == ISC_R_SUCCESS) {
dns_ttl_t ds_ttl = dns_kasp_dsttl(kasp);
ds_ttl += dns_kasp_parentpropagationdelay(kasp);
if ((syncpub + ds_ttl) <= now) {
ds_state = OMNIPRESENT;
} else {
ds_state = RUMOURED;
}
goal_state = OMNIPRESENT;
}

I am not sure what the "SyncPublish" value is in your key file, but 
maybe this is a hint to why the "DSState" is set to "rumoured".


What can you do to get it to "omnipresent"? Tell BIND that the DS is in 
the parent (only do so if it is true of course). You can run


rndc dnssec -checkds published your.zone

And it should update the keyfile. You should then see a "DsPublish" line 
in the state file and wait for DS TTL and parent propagation delay time 
to see the state switch to "omnipresent".


If there are multiple keys eligible you need to specify the key id with 
"-key id".


Hope this helps, and if not, please let me know.

Best regards,

Matthijs


On 26-04-2022 10:50, Bjørn Mork wrote:

Matthijs Mekking  writes:


To be precise, BIND updates the key files each keymgr run. But If the
keymgr waits for an event (rather than a duration), it will retry
every refresh key interval, which defaults to an hour.

You can check the logs for "next key event" to see when the keymgr is
scheduled next.

But yes, each time the keymgr runs for a zone, the key files are
written out for that zone. You are right that this is unnecessary. I
have created a GitLab issue for this to fix it.

https://gitlab.isc.org/isc-projects/bind9/-/issues/3302


Thanks for explaining.  This makes sense.

I guess that the event the keymgr is waiting for must be DSState update
for the active KSK?  Which is another thing I haven't been able to
figure out.

Since I have only migrated existing keys, all states are either "hidden"
(for deleted keys) or "omnipresent".  Except for DSState which is
"rumoured".  And I don't understand why, or what I can do to change that.

For example:

bjorn@louie:~$ grep . /etc/bind/dnssec/dyn.mork.no/Kdyn.mork.no.+013+63342.state
; This is the state of key 63342, for dyn.mork.no.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: no
Generated: 20181012184125 (Fri Oct 12 19:41:25 2018)
Published: 20181012184500 (Fri Oct 12 19:45:00 2018)
Active: 20181012184500 (Fri Oct 12 19:45:00 2018)
PublishCDS: 20181013195000 (Sat Oct 13 20:50:00 2018)
DNSKEYChange: 20220405085059 (Tue Apr  5 09:50:59 2022)
KRRSIGChange: 20220405085059 (Tue Apr  5 09:50:59 2022)
DSChange: 20220405085059 (Tue Apr  5 09:50:59 2022)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent


The DS records for all these zones have been active for years.  I see
that BIND created new and mostly (except for TTL) matching CDS records
when I migrated to dnssec-policy.  Is the TTL mismatch the problem?  Or
is BIND waiting for something else to happen to this (C)DS record?

I guess I could try to sync the TTL for the internal delegations.  But
this is rarely an option for most of the zones with externally managed
parents.

I found https://gitlab.isc.org/isc-projects/bind9/-/issues/2544
describing this problem, but the solutions is still unclear to me.
Maybe it's just a transitional problem when migrating to dnssec-policy?


Bjørn

--
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-policy makes BIND touch all key files every hour

[Matthijs Mekking]

On 26-04-2022 14:25, Bjørn Mork wrote:

Matthijs Mekking  writes:


What can you do to get it to "omnipresent"? Tell BIND that the DS is
in the parent (only do so if it is true of course). You can run

 rndc dnssec -checkds published your.zone

And it should update the keyfile. You should then see a "DsPublish"
line in the state file and wait for DS TTL and parent propagation
delay time to see the state switch to "omnipresent".

If there are multiple keys eligible you need to specify the key id
with "-key id".


Thanks.  Yes, that was the solution.


Glad to hear that worked.



Pretty obvious now that I know :-) We can view the initial bootstrapping
as "half a KSK rollover".

FWIW, I followed the dnssec-policy migration instructions at
https://kb.isc.org/docs/dnssec-key-and-signing-policy , which also
includes KSK rollover instructions.  But I still didn't manage to put
that puzzle together.  Maybe you could include an explicit hint for
those of us who are too slow to figure out these things by ourselves?


Makes sense to me. I have added a note at the end of the "Key states" 
section.



Best regards, Matthijs
--
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: Confused by parental-source documentation

[Matthijs Mekking]

Hi Nick,

Thanks for bringing this to our attention. Yes, this is a copy paste 
error. I think it can be removed, although we could change it because 
you should make sure the address matches with what the parental agent 
expects.


Best regards,
Matthijs

On 01-05-2022 07:18, Nick Tait via bind-users wrote:

Hi list.

I've been reading the latest BIND9 documentation on the new DNSSEC 
features, and section 4.2.28.1 got me horribly confused:


/The following options apply to DS queries sent to
//|parental-agents|//:/

/|parental-source|/

/|parental-source|//determines which local source address, and
optionally UDP port, is used to send parental DS queries. This
address must appear in the secondary server’s
//|parental-agents|//zone clause. This statement sets the
//|parental-source|//for all zones, but can be overridden on a
per-zone or per-view basis by including a
//|parental-source|//statement within the //|zone|//or
//|view|//block in the configuration file./

No matter how many times I read the sentence in blue font, I couldn't 
make sense of it...


I finally realised that the parental-source paragraph is almost 
identical to the documentation for notify-source:


/|notify-source|/

/|notify-source|//determines which local source address, and
optionally UDP port, is used to send NOTIFY messages. This
address must appear in the secondary server’s
//|primaries|//zone clause or in an //|allow-notify|//clause.
This statement sets the //|notify-source|//for all zones, but
can be overridden on a per-zone or per-view basis by including a
//|notify-source|//statement within the //|zone|//or
//|view|//block in the configuration file./

And so I can only assume that the problematic sentence in 
parental-source (i.e. "/This address must appear in the secondary 
server’s //|parental-agents|//zone clause./") is a copy-paste error? If 
that is the case can the sentence please be removed from the documentation?


Or if I'm mistaken can anybody please give an example to explain what 
this is trying to say?


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: understanding keymgr handling of KSK

[Matthijs Mekking]

Hi,

On 09-05-2022 10:16, Bjørn Mork wrote:

Michael Richardson via bind-users  writes:


4) I don't understand the difference between "auto-dnssec maintain;"
and "dnssec-policy default"  (given that I haven't overridden anything).


I believe the only difference is that the latter will track your keys in
addition to the automatic signing.  And it will auto-generate CDS and
CDNSKEY records.  None of which matters much until you start using it
for automatic rollovers.


'auto-dnssec maintain' will also adjust the DNSSEC keys according to the 
key timing metadata ('auto-dnssec allow' will only update signatures).


'dnssec-policy' is also able to create new keys when needed and allows 
you to specify a policy for DNSSEC signing (roughly put: it moves 
dnssec-keymgr functionality inside BIND).




I am not sure, but I suspect this is because the key didn't match your
dnssec-policy.  So the rollover started immediately when you configured
dnssec-policy, with a fresh KSK generatated and removal of the existing
keys with "wrong" algorithms scheduled.


I suspect so too.


AFAIK, I'm not doing CDS (I'd like to, but I don't know how, and I don't know 
if .org is doing it).


Yes, same here.  This is not a problem. I learned from the discussion
here earlier that BIND will just wait for me to manually tell if about
the DS state using "rndc dnssec -checkds ...".  Which is fine.

What's surprising is that the KSK went missing without you telling BIND
that the DS was removed.  I wonder if the problem is that it started out
already having "DSState: hidden" because of the policy mismatch?


Yes, if BIND thinks the DS is not known to the world, it may remove the 
DNSKEY record.



- Matthijs
--
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: why did it take 26 hours for DSState to change to omnipresent?

[Matthijs Mekking]

Hi Nik,

On 16-05-2022 07:49, Nick Tait via bind-users wrote:

Hi there.

Ever since I updated my BIND configuration to use the new dnssec-policy 
feature (a year or so ago) my KSK/CSK rollovers have been a complete 
shambles. My problems stem from the inference (based documentation and 
examples) that running "rndc dnssec -checkds published" tells BIND that 
the DS record is now published in the parent zone? Based on that 
predicate, it would be my expectation that after running this command 
above, the DSState should immediately transition from "rumoured" to 
"omnipresent".


This assumption is incorrect. Once the DS is in the parent, validators 
do not immediately know about the new DS record. That why it is rumoured.


Being omnipresent means that every resolver will use the new DS record 
for validation purposes, whether they have it in the cache, or retrieve 
it from the parent zone. More importantly this means that any previous 
versions of the DS RRset are not known anywhere.


In past rollovers, the DSState hasn't transitioned from "rumoured". And 
then I've thought "oh it must be a bug" and so I've set about trying to 
force the DSState to change to "omnipresent". And suffice to say that 
the shambles followed on from there...


So anyway, since I'd recently upgraded to BIND 9.18.1 (as part of Ubuntu 
22.04 upgrade), and thinking maybe these 'bugs' might now be fixed, I 
thought I'd have another look at it, but this time I'll pay more 
attention to what is going on, and try to be less impatient...


Before I did anything the key state file looked like this:

Algorithm: 15
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20211024221429 (Mon Oct 25 11:14:29 2021)
Published: 20211024221429 (Mon Oct 25 11:14:29 2021)
Active: 20211024221429 (Mon Oct 25 11:14:29 2021)
PublishCDS: 20211025231929 (Tue Oct 26 12:19:29 2021)
DNSKEYChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
ZRRSIGChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
KRRSIGChange: 20211025001929 (Mon Oct 25 13:19:29 2021)
DSChange: 20211025231929 (Tue Oct 26 12:19:29 2021)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent

As you can see the DSState was "rumoured" before I started. So the first 
thing I did was run "rndc dnssec -checkds published", and this added the 
following line to the state file:


DSPublish: 20220515001647 (Sun May 15 12:16:47 2022)

However the DSState value remained "rumoured". So then I thought, I'll 
wait a TTL or two (TTL for DS and DNSKEY are both 1 hour -- although I 
wouldn't expect BIND to know the DS TTL). But still nothing changed. So 
then I decided I'd leave it alone until the next day. When I checked 
after ~20 hours elapsed time, still nothing had changed.


I checked again just now, and finally the DSState has changed to 
"omnipresent". Here are the lines in the state file that have changed:


DSChange: 20220516021647 (Mon May 16 14:16:47 2022)
DSState: omnipresent

So my big question is this: Is it expected that the DSState won't change 
until 26 hours after the "rndc dnssec -checkds published" command is 
run? And if so why does it take so long?


That depends on your dnssec-policy. BIND will/should move the DSState to 
omnipresent after an x amount of time, where:


x =  parent-ds-ttl + parent-propagation-delay + retire-safety


By default these values are

parent-ds-ttl: 24h
parent-propagation-delay: 1h
retire-safety: 1h

So the 26 hours add up.

Now these may be very conservative values, but for the default policy we 
rather wait a little longer than too short.


Best regards,

Matthijs




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

[Matthijs Mekking]

Sandro,

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.


Matthijs

On 23-05-2022 16:12, Sandro wrote:

On 23-05-2022 15:48, Tony Finch wrote:


The place I would look first is the log messages from `named`: is it
complaining about anything?


Plenty of:

zone penguinpee.nl/IN/external: reconfiguring zone keys
zone penguinpee.nl/IN/external: next key event: 22-May-2022 01:00:01.961

When the log files rolled over at 00:00 on 22 May, named.log just reported:

22-May-2022 00:00:07.093 general: info: reloading configuration succeeded
22-May-2022 00:00:07.272 general: info: reloading zones succeeded
22-May-2022 00:00:07.402 general: notice: all zones loaded
22-May-2022 00:00:07.402 general: notice: running


One of the things I have to take care with (because I have got it wrong
several times!) is filesystem permissions: can `named` read the .private
keys? can it read and write to the zone files? can it read and write to
the directories containing the keys and the zone files?


Yeah, that's all fine. All keys for internal and external, forward and 
reverse zones are stored in the same directory with rw access for named. 
On the internal zone, the records look just fine:


RRSIG   CNAME 13 3 259200 (
     20220605095654 20220522085940 56132 penguinpee.nl.
     Geyl5Rz6Kqwfp5JUf09A1NB3fRU6EhdszCihduKlJat7
     W8780MyS2awJjI+xDi9zG9fkO8yQx48hGeDDFxc3dA== )

The reverse zone in the external view was up to date and named was able 
to re-sign the affected zone after the restart. So, permissions are 
good, I'd say.


I'll do some more digging through the log files. I meanwhile increased 
the severity to 'debug 3' for dnssec_debug.


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

[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

[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]*
<https://gitlab.isc.org/isc-projects/bind9/-/issues/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: DNSSEC transition from manually signed zone to dnssec-policy "standard" failed

[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): attempt to 
lock key files, but no key file lock available, abort
Jun  1 21:52:42 domac named[46537]: