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

[Matthijs Mekking]

revent 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: 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]

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]

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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=all_name%5B%5D=Extended%20DNS%20Errors_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: 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: 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: 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-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 

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

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: 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: 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: 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: 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: (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: 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: [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://example.com <http://example.com&

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]

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: key dir massive

[Matthijs Mekking]

On 12/22/22 16:23, Eric Germann wrote:

On Dec 22, 2022, at 09:32, Matthijs Mekking  wrote:






I hope you have read our KB article on dnssec-policy before migrating:

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

It should list the main pitfalls to save you a lot of hassle (I suspect you 
started algorithm rollover immediately when changing to dnssec-policy default).

If there are any things we should add, I am happy to receive your suggestions.


Are there any examples from ISC on how to handle multiple algorithms in the 
dnssec-policy stanza?  I’m running 8 and 13 both as an experiment

Eric


Just list the keys you want. So for example double algorithm, zsk and ksk:

dnssec-policy {

  # RSASHA256
  ksk key-directory lifetime P1Y algorithm 8;
  zsk key-directory lifetime P1M algorithm 8;
  # ECDSAP256SHA256
  ksk key-directory lifetime P1Y algorithm 13;
  zsk key-directory lifetime P1M algorithm 13;

};

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: key dir massive

[Matthijs Mekking]

Hi Edwardo,

On 12/22/22 05:01, Edwardo Garcia wrote:

Hi,
I recently upgraded from 9.16 to latest version and changed a zone, ran 
verisign test and it said all good, so changed my zones from auto 
maintain dnssec to dnssec policy default, what a nightmare, most our 
zones vanished few hours later for a day, and it create new keys for 
everything, this bug i saw was fixed many versions ago, should it not 
see my have keys and re-use them (keys were made a year ago on current 
at the time v9.11, we upgrade to 9.16 in July and no issue till these 
option name change rubbish. I was warned by colleagues not to do this as 
they too say migration nightmares, but I am my own person and now I 
regret not listening their advise.


I hope you have read our KB article on dnssec-policy before migrating:

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

It should list the main pitfalls to save you a lot of hassle (I suspect 
you started algorithm rollover immediately when changing to 
dnssec-policy default).


If there are any things we should add, I am happy to receive your 
suggestions.



Now I think is under control, once identifying the current key set, is 
it safe to manually delete all the others keys privates and states, 
except the current one, and will any of that DS change again?


Probably, without knowing your current state of things it is hard to 
give a more confident answer.


Setting 'purge-keys' inside your 'dnssec-policy' is probably your best 
bet for the future. By default, no longer used keys are deleted from 
disk after 90 days.


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: [KASP] setup KASP in master / slave architecture

[Matthijs Mekking]

Hi,

No.

You don't need DNSSEC maintenance on your secondary zones if you already 
have set it on your primary zones. So


zone "***" {
  type secondary;
  primaries { ***; };
  file "***.db";
};

is enough.

Best regards,

Matthijs.

On 12/9/22 09:58, adrien sipasseuth wrote:

Hi Matthijs,

thank you, so just to confirm something like this should work :
Master :
dnssec-policy "test" {
     keys {
         ksk lifetime P3D algorithm rsasha256 2048;
         zsk lifetime P2D algorithm rsasha256 1024;
     };
};

zone "**" {
     type master;
     file "/***/*.db";
     notify yes;
     key-directory "/**/**/";
     inline-signing yes;
     dnssec-policy test;
};

And my Slaves :
zone "**" {
     type slave;
         masters { ** ; };
     file "/ **/ ** / ** .db";
     key-directory "/ ** / ** / ** .fr";
     auto-dnssec maintain;
     inline-signing yes;
};

am i rigth ?

Regards

Adrien




Le ven. 9 déc. 2022 à 09:33, Matthijs Mekking <mailto:matth...@isc.org>> a écrit :


Hi Adrien,

You should **not** copy the dnssec-policy configuration to your
secondaries. They transfer in the signed zone from the primary server.

Best regards,

Matthijs


On 12/9/22 09:24, adrien sipasseuth wrote:
 > Hello,
 >
 >
 > Lokking for some guidance, sorry if i use the wrong way to contact
 > community user support.
 >
 >
 > I would like to set up DNSSEC using KASP.
 >
 > I have an architecture with a master and several slaves.
 >
 > Here is my policy and zone configuration:
 >
 > dnssec-policy "test" {
 >
 >      keys {
 >
 >      ksk lifetime P3D algorithm rsasha256 2048;
 >
 >      zsk lifetime P2D algorithm rsasha256 1024;
 >
 >      };
 >
 > };
 >
 > zone "**" {
 >
 >      type master;
 >
 >      file "/***/*.db";
 >
 >      notify yes;
 >
 >      key-directory "/**/**/";
 >
 >      inline-signing yes;
 >
 >      dnssec-policy test;
 >
 > };
 >
 >
 > after restart, it seems ok, keys are generated on master, no
errors in
 > logs etc.
 >
 > I copied this policy, the keys and the zone configuration on each
of my
 > slaves then I restarted my slaves everything seems ok (in the logs).
 >
 > except that now I wonder if the keys on each of my slaves will be
 > generated independently from those of my master.
 >
 >
 > In this case, I will end up with different keys for the same zone
 > depending on the slave1 / slave2 etc / master. I suppose that it
is not
 > good because we should have for the same zone, a pair of keys and
this
 > one should be copied on each slaves?
 >
 > There some tuto / documentation about how to setup KASP in master /
 > slaves topology ?
 >
 >
 > Sorry if it's not enough clear...
 >
 >
 > Thank you
 >
 > *Adrien SIPASSEUTH*
 >
 >
-- 
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] setup KASP in master / slave architecture

[Matthijs Mekking]

Hi Adrien,

You should **not** copy the dnssec-policy configuration to your 
secondaries. They transfer in the signed zone from the primary server.


Best regards,

Matthijs


On 12/9/22 09:24, adrien sipasseuth wrote:

Hello,


Lokking for some guidance, sorry if i use the wrong way to contact 
community user support.



I would like to set up DNSSEC using KASP.

I have an architecture with a master and several slaves.

Here is my policy and zone configuration:

dnssec-policy "test" {

     keys {

     ksk lifetime P3D algorithm rsasha256 2048;

     zsk lifetime P2D algorithm rsasha256 1024;

     };

};

zone "**" {

     type master;

     file "/***/*.db";

     notify yes;

     key-directory "/**/**/";

     inline-signing yes;

     dnssec-policy test;

};


after restart, it seems ok, keys are generated on master, no errors in 
logs etc.


I copied this policy, the keys and the zone configuration on each of my 
slaves then I restarted my slaves everything seems ok (in the logs).


except that now I wonder if the keys on each of my slaves will be 
generated independently from those of my master.



In this case, I will end up with different keys for the same zone 
depending on the slave1 / slave2 etc / master. I suppose that it is not 
good because we should have for the same zone, a pair of keys and this 
one should be copied on each slaves?


There some tuto / documentation about how to setup KASP in master / 
slaves topology ?



Sorry if it's not enough clear...


Thank you

*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: parental-agents clause - IP address only ?

[Matthijs Mekking]

'parental-agents' work the same as 'primaries'. It only supports addresses.

Listing them as domain names would technically be possible to implement, 
but it requires an authoritative server to act as an resolver. Adding 
resolver code to the path of an authoritative server is like crossing 
the streams. It adds security risks that are unnecessary for an 
authoritative server, so I'd rather not add such functionality.


Best regards,

Matthijs

On 05-12-2022 03:34, vom513 wrote:

Hello all,

So I set up parental-agents lists for my zones, and actually got to see it work 
(awesome !).  bind detected the parent DS records and acted accordingly.

However, I currently have these lists configured using the IP (v4 only at the 
moment) addresses of the parent NS’es.  I tried inputting hostnames, and I got 
errors (i.e. syntax) every time.

I would prefer to put these in as hostnames.  While at a certain level in the 
tree these don’t change very often, they can and do.  I’d rather not have to 
keep track of these in this manner.

So my question - am I just mangling the syntax - or does this clause really 
only support IPs ?  I was thinking if so - perhaps the reason is some chicken 
vs. egg / security reason ?  I.e. not trusting the name (which would have to be 
itself resolved) ?

Thanks in advance for clue++

--
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: Struggling with dnssec-policy timers

[Matthijs Mekking]

On 29-11-2022 00:39, vom513 wrote:




On Nov 28, 2022, at 3:12 PM, vom513  wrote:

Thanks for the reply and info…

I would have thought the CDS would be published before the key went
active.  I.e. there would be a period of TWO DS’es at the parent
(I’m assuming the parent supports CDS/CDNSKEY which mine
(registrar) does).


This is called Double-DS rollover (RFC 7583, Section 3.3.2). BIND 
implements the Double-KSK method (RFC 7583, Section 3.3.1) for 
dnssec-policy.




Since the new key goes active, CDS is published, and the old key is
retired at the same time - isn’t this going to cause a (lack of
coverage/chain of trust) problem ?  I’m really trying to get to a
point of a “one command” rollover.  I.e. no API, no uploading DS,
etc.  I guess I’ll see tonight when it happens, but I can’t help
but feel when the clock strikes I’m going to be missing DS for the
new key at the parent.



Sorry to self reply…

So it did “work” as you said Matthijs… I don’t think I necessarily
need those timers (publish/retire-safety) that I tweaked.  I’d rather
use as many bind defaults as possible.  I think a big part of my
issue was misunderstanding “retired” status.  I nuked everything
clean and will try this again once everything settles down.  Thanks
for your patience with me and pointers.


The default publish-safety and retire-safety are set to 3600 seconds.
They are meant to delay rollovers to deal with unforeseen events. I
don't think you need to change them unless you have a good reason to do so.



PS: My registrar says they check CDS/CDNSKEY once a day.  Do you
think that’s reasonable ?  I certainly appreciate them being
cognizant/careful of too much load on their systems with too many
frequent checks, but a day seems long to me...


KSK rollovers are meant to happen infrequently, so once a day seems
reasonable to me.

Note that you would still have to check the parent when the DS has
changed. The DS may be published and withdrawn automatically in the
parent zone if your registar polls the CDS/CDNSKEY, but BIND by default
does not check whether the DS has actually been published.

Either check it manually, or scripted, and use "rndc dnssec -checkds" to
signal BIND that a certain DS has been published or withdrawn.

Or set up a "parental-agents" in your named.conf, that is a server that
BIND will use to query the DS RRset to fully automate the KSK rollover.


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: Struggling with dnssec-policy timers

[Matthijs Mekking]

Hi,

On 27-11-2022 23:32, vom513 wrote:

Hello all,

I’m still having a really hard time understanding and getting my
timings right.  At least I think I am (from the way I’m reading the
status/logs/state files).

I let my current CSK get completely “omnipresent” for all it’s timers
(I’m not even sure if this is really necessary…)  I did a rollover,
and I’m very confused by the various timers I’m seeing.

FYI - I added:

publish-safety 1d; retire-safety 1d;

To the policy “default”.  Other than that and NSEC3, everything is
using values from the “default” policy.  With this, it seems that my
successor key will go active but CDS won’t be published until the
same exact time.  This seems to defeat the purpose of doing an
overlapping rollover.  I would think I would want CDS published
before the new key goes active.  Is the old key going to keep being
used for signing as well ?  I don’t think so because it’s retirement
is also at this exact moment.

The CDS cannot be published before the new key is active. BIND 9
performs a Double DNSKEY rollover, so only after the new key is active,
the DS may be published in the parent (and publishing CDS is an
indication that the DS may be published).



So simultaneously, it seems that I have:

- New key start to be used for signing - CDS is published - Old key
is retired

If I’m reading this right - did my timers screw this up ?  I would
have hoped/assumed that the “default” policy would have timers
arranged as such as there there *should* not be any gaps in coverage
(assuming everything else goes swimmingly…)  I’ll be honest - I’m
kind of feeling like an idiot because of how difficult this seems.


I assume you used "rndc dnssec -rollover" to initiate a rollover 
(because the default policy has key lifetime unlimited).


I don't know what times you expect, but the timings look fine to me. The 
current key 35731 will be retired today (20221128231500 (Mon Nov 28 
18:15:00 2022), and at that time the successor key 3697 will become active.


Because at this point there are two DNSKEY's omnipresent (i.e. known to 
the world), it is safe to swap the DS.


So unless I am misunderstanding, I think all is fine?

Best regards,

Matthijs




Can someone please set me straight ?  I can “nuke” this zone’s keys
and state and start over (which I’ve done several times already).
It’s just getting a bit tiresome because of course when I do this all
the various timers start over.

Here are my state files, 2 keys.  Current and a successor.  Thanks in
advance.

— ; This is the state of key 3697, for acuity.tech. Algorithm: 13 
Length: 256 Lifetime: 0 Predecessor: 35731 KSK: yes ZSK: yes 
Generated: 20221127221000 (Sun Nov 27 17:10:00 2022) Published:

20221127221000 (Sun Nov 27 17:10:00 2022) Active: 20221128231500 (Mon
Nov 28 18:15:00 2022) PublishCDS: 20221128231500 (Mon Nov 28 18:15:00
2022) DNSKEYChange: 20221127221000 (Sun Nov 27 17:10:00 2022) 
ZRRSIGChange: 20221127221000 (Sun Nov 27 17:10:00 2022) KRRSIGChange:

20221127221000 (Sun Nov 27 17:10:00 2022) DSChange: 20221127221000
(Sun Nov 27 17:10:00 2022) DNSKEYState: rumoured ZRRSIGState: hidden 
KRRSIGState: rumoured DSState: hidden GoalState: omnipresent


; This is the state of key 35731, for acuity.tech. Algorithm: 13 
Length: 256 Lifetime: 546573 Successor: 3697 KSK: yes ZSK: yes 
Generated: 20221122152527 (Tue Nov 22 10:25:27 2022) Published:

20221122152527 (Tue Nov 22 10:25:27 2022) Active: 20221122152527 (Tue
Nov 22 10:25:27 2022) Retired: 20221128231500 (Mon Nov 28 18:15:00
2022) Removed: 20221209232000 (Fri Dec  9 18:20:00 2022) DSPublish:
20221123043555 (Tue Nov 22 23:35:55 2022) PublishCDS: 20221124153027
(Thu Nov 24 10:30:27 2022) DNSKEYChange: 20221123163027 (Wed Nov 23
11:30:27 2022) ZRRSIGChange: 20221124153027 (Thu Nov 24 10:30:27
2022) KRRSIGChange: 20221123163027 (Wed Nov 23 11:30:27 2022) 
DSChange: 20221125053555 (Fri Nov 25 00:35:55 2022) DNSKEYState:
omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent 
DSState: omnipresent GoalState: hidden



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

[Matthijs Mekking]

Hi Mark,

On 24-11-2022 13:44, Mark Elkins via bind-users wrote:

OK - so I read RFC7344... Automating DNSSEC Delegation Trust Maintenance

There are two interesting paragraphs.

_/5.  CDS/CDNSKEY Publication/_/
//
//   The Child DNS Operator publishes CDS/CDNSKEY RRset(s).  In order to//
//   be valid, the CDS/CDNSKEY RRset(s) MUST be compliant with the rules//
//   in Section 4.1. *When the Parent DS is in sync with the CDS/CDNSKEY*/*/
/**/   RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY 
RRset(s);/*/

//   the Child can determine if this is the case by querying for DS//
//   records in the Parent./



_/6.1.1.  CDS/CDNSKEY Polling/_/
//
//   This is the only defined use of CDS/CDNSKEY resource records in this//
//   document.  There are limits to the scalability of polling techniques;//
//   thus, some other mechanism is likely to be specified later that//
//   addresses CDS/CDNSKEY resource record usage in the situation where//
//   polling runs into scaling issues.  Having said that, polling will//
//   work in many important cases such as enterprises, universities, and//
//   smaller TLDs.  In many regulatory environments, the Registry is//
//   prohibited from talking to the Registrant.  In most of these cases,//
//   the Registrant has a business relationship with the Registrar, so the//
//   Registrar can offer this as a service.//
//
//*If the CDS/CDNSKEY RRset(s) do not exist, the Parental Agent MUST*/*/
/**/   take no action.  Specifically, it MUST NOT delete or alter the/**/
/**/   existing DS RRset./*

I'm confused. There is no text describing how a Key Rollover might work. 
The Child can delete the CDS once it believed the Parent has activated 
the appropriate DS. There is no discussion on how a Parent will know to 
remove that DS record... unless it is via asking the Child for all 
existing DNSKEY records of type 257 and then recalculating the DS 
records and working out what is missing. Then we don't need CDS records 
at all - just Poll for DNSKEY records?


Note that the child can delete the CDS **RRset** once it believes the 
parent is in sync (not just a single CDS record).


The parent should remove the existing DS record if it encounters a 
CDS/CDNSKEY RRset that does not have a corresponding record for the 
given DS record.


The only corner case is that there is no way to signal that all DS 
records must be removed from the parent (i.e. going insecure) in RFC 
7344. That is defined in RFC 8078.


Hope this helps taking away your confusion.



I think I really prefer the simplicity of mirroring the CDS's of a Child > into 
the DS's on the Parent. Makes handling of Null CDS records easier.


Me too :)

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

[Matthijs Mekking]

Hi,

I think this should work with some caveats.

First, If you migrate to dnssec-policy (that is the zone is already 
signed), make sure that the key properties match the current DNSKEYs.


Second is about your script:

> If the child looses a CDS record - my external script will remove the
> corresponding DS record from the parent.

This is true for BIND 9, as it will publish the CDS for as long as the 
DS should be in the parent. But it doesn't have to be the case. The RFC 
(7344) says:


   When the Parent DS is in sync with the CDS/CDNSKEY
   RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s);
   the Child can determine if this is the case by querying for DS
   records in the Parent.

Personally I like to keep the CDS in the child zone, so you can see if 
the parent is in sync, that is why I implemented it in BIND 9 to keep 
the CDS.


Best regards,

Matthijs


On 23-11-2022 18:24, Mark Elkins via bind-users wrote:

Hi people,

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

I have put the following policy in my named.conf file:-

dnssec-policy "ecdsa256-policy" {
     signatures-refresh 5d;
     signatures-validity 14d;
     signatures-validity-dnskey 14d;
     dnskey-ttl 3600;
     publish-safety 1h;
     retire-safety 1h;
     purge-keys 10d;

     keys {
     ksk lifetime 370d algorithm ecdsa256;   // < this part in 
particular!

     zsk lifetime 34d algorithm ecdsa256;
     };

     zone-propagation-delay 300s;
     max-zone-ttl 86400s;
     parent-propagation-delay 1h;
     parent-ds-ttl 3600;
};

I also have some external code that goes trawling for CDS records and 
puts into a parent whatever it finds in the child - that in this case is 
signed with the above policy stanza.


If the child creates a new CDS - my external scripts will find it and 
pop it into the parent as a DS record.
If the child looses a CDS record - my external script will remove the 
corresponding DS record from the parent.

Basically - whatever is in the child as a CDS will be in the parent as a DS.
A null CDS removes all DS records - but that's not my question.

Is there anything else I need to do? Any additional rndc's ??

--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 



--
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 - CSK rollover help

[Matthijs Mekking]

Thanks for providing the data.

So it looks to me that nothing has happened yet because you scheduled 
the rollover at 2022112223 (November 22, 2022, 23:00:00 UTC). That's 
why no successor has been created yet, the datetime is still in the future.


You can see in the state file that the key will be retired at
2022-11-23 01:05:00 UTC. This is 2 hours and 5 minutes after the 
rollover starts, that is the sum of the DNSKEY TTL plus the 
publish-safety margin, plus the configured zone propagation delay.


So if all goes well, your rollover should start tonight (UTC).

You can set the log level to debug 1 and you will likely see the time in 
seconds when the new successor needs to be generated/selected. ("keymgr: 
new successor needed for DNSKEY  (CSK) (policy default-nsec3) in 
 seconds").


Best regards,

Matthijs


On 21-11-2022 15:54, vom513 wrote:




On Nov 21, 2022, at 3:29 AM, Matthijs Mekking  wrote:

Hi,

It is hard to see what the problem is without any configuration or state 
information. Also, log level debug 3 gives you probably more useful logs when 
investigating a problem.

Can you share (privately if you wish) the key **state** files, and the output 
of 'rndc dnssec -status' for the given zone?


Yep, nothing top secret here.  Here is rndc dnssec -status as well as the state 
file.  Judging by the lifetime / retirement - looks like I have a 2 hour window 
after the rollover ?  I suppose I can/should tweak/increase this lifetime in 
the dnssec-policy ?

--
dnssec-policy: default-nsec3
current time:  Mon Nov 21 09:50:11 2022

key: 46697 (ECDSAP256SHA256), CSK
   published:  yes - since Wed Nov 16 22:07:32 2022
   key signing:yes - since Wed Nov 16 22:07:32 2022
   zone signing:   yes - since Wed Nov 16 22:07:32 2022

   Next rollover scheduled on Tue Nov 22 18:00:00 2022
   - goal:   omnipresent
   - dnskey: omnipresent
   - ds: omnipresent
   - zone rrsig: omnipresent
   - key rrsig:  omnipresent

; This is the state of key 46697, for acuity.tech.
Algorithm: 13
Length: 256
Lifetime: 511048
KSK: yes
ZSK: yes
Generated: 20221117030732 (Wed Nov 16 22:07:32 2022)
Published: 20221117030732 (Wed Nov 16 22:07:32 2022)
Active: 20221117030732 (Wed Nov 16 22:07:32 2022)
Retired: 20221123010500 (Tue Nov 22 20:05:00 2022)
Removed: 20221203021000 (Fri Dec  2 21:10:00 2022)
DSPublish: 20221118201223 (Fri Nov 18 15:12:23 2022)
PublishCDS: 20221118041232 (Thu Nov 17 23:12:32 2022)
DNSKEYChange: 20221117051232 (Thu Nov 17 00:12:32 2022)
ZRRSIGChange: 20221118041232 (Thu Nov 17 23:12:32 2022)
KRRSIGChange: 20221117051232 (Thu Nov 17 00:12:32 2022)
DSChange: 20221119221223 (Sat Nov 19 17:12:23 2022)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: omnipresent
GoalState: omnipresent
--

--
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 - CSK rollover help

[Matthijs Mekking]

Hi,

It is hard to see what the problem is without any configuration or state 
information. Also, log level debug 3 gives you probably more useful logs 
when investigating a problem.


Can you share (privately if you wish) the key **state** files, and the 
output of 'rndc dnssec -status' for the given zone?


Best regards,

Matthijs

On 20-11-2022 00:50, vom513 wrote:

Hello,

So I reconfigured one of my domains to use dnssec-policy.  I’m using the policy 
“default” + I’ve only added nsec3 stuff.  All other timers / params are from 
default.  Working fine / as expected.

Luckily for me this is a domain that I don’t use much.  So outages and mistakes 
are easily tolerable.

After a bumpy start, I have the zone “happy” - that is, fully signed, DS in 
parent, and all timers reading “omnipresent”.

I’m trying to use this ISC KB as a guide: 
https://kb.isc.org/docs/dnssec-key-and-signing-policy

So I decided to try a rollover.  So I did: rndc dnssec -rollover -key 12345 -when 
2022112223 example.com 

This now shows up as scheduled in rndc dnssec -status.

However, I expected BIND to create a successor CSK.  Nothing in the key dir, 
nothing in logs, nothing in rndc status.

The whole point of course is to have two “overlapping” keys, two DS’es, i.e. 
two chains of trust.  And then when everything is happy timer-wise, the old key 
(and DS) can go away.

Is BIND going to do this sometime before the actual rollover ?  Or is there 
something else I need to do ?  Speaking of this - what exactly happens at the 
rollover time ?

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: Migrating to dnssec-policy - existing "stack" of future keys ?

[Matthijs Mekking]

Hi,

On 16-11-2022 18:53, vom513 wrote:

Hello,

I’m wanting to go ahead and look at migrating to dnssec-policy for my
zones.  I currently use “auto-dnssec maintain” and “inline-signing
yes”.  I also have a “stack” of ZSKs I made that all nicely overlap
with their various date settings.  I think I made these out to
sometime in 2024.


It is unclear to me what you mean with a "stack". But this kind of
planning is no longer needed with dnssec-policy.


In addition to all the info here:

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

Do I need to / should I do something to this stack of keys ?  I was
thinking maybe take the most “current” key, and remove his expiration
etc.  Then (after a backup of course), delete the other future keys
?


You should be able to have pre-generated keys though, and as long as 
they have notbeen used before (this is maintained in the state file), 
one is randomly picked to be the successor key instead of that a new one 
is generated.


f those keys have timing metadata set, the dnssec-policy will use that 
once to initialize the current state. As long as they current keys match 
the policy, it should be alright. Timing metadata that are in the past 
are used to determine the key states. Timing metadata that are in the 
future are ignored.


If there is a difference, the dnssec-policy will perform actions to get 
to the right state (things like publish and/or withdraw DNSKEY records 
from the zone, start/stop signing with certain keys).



In other words, I can’t imagine I’d want to mix the “old way” of
managing these / rollovers with the new.


I agree to that.


Hopefully this makes sense.  Thanks for any guidance or insight.
I am not entirely clear on your setup, but I hope my comments make sense 
and help you forward.


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: isc.org - error on KB article

[Matthijs Mekking]

Done, thanks for reading and reporting.

Best regards,
  Matthijs

On 17-11-2022 02:43, vom513 wrote:

ISC folks: can someone take a look at:

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

Seems one of the examples has a “-when” argument to rndc and the time is “1w”

rndc seems to want MMDDHHMMSS (UTC) instead.

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: Deprecating auto-dnssec and inline-signing in 9.18+

[Matthijs Mekking]

FYI: We are going forward with deprecating 'auto-dnssec' in 9.18+.

We might deprecate 'inline-signing' too in 9.18, but only if we have 
implemented the replacement code to configure it inside 'dnssec-policy' 
in time.


After last year's discussion on this mailing list I initially wanted to 
make creating keys inside the HSM work with dnssec-policy. But the 
OpenSSL pkcs#11 engine has no capability to do so. Now we are 
transitioning to OpenSSL 3.0 and the engine API is being replaced with 
the provider API, this task has become even more challenging.


But since there is functional parity between 'dnssec-policy' and 
'auto-dnssec', we decided that it is acceptable to deprecate the legacy 
style of DNSSEC maintenance.


You can configure dnssec-policy to do no key rollover (and do key 
maintenance/rotation in a different way) as follows:


dnssec-policy "no-auto-rotate" {
keys {
ksk lifetime unlimited algorithm 13;
zsk lifetime unlimited algorithm 13;
};
};

Best regards,

Matthijs


On 10-08-2021 10:02, Matthijs Mekking wrote:

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

--
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: 'inline-signing' might go away and be replaced by dnssec-policy ?

[Matthijs Mekking]

Since the latest release dnssec-policy requires either inline-signing 
to be set to yes, or allow dynamic updates.


I am thinking of adding inline-signing to dnssec-policy, do you think 
that would that be useful?


Matthijs,

Yes, from my point of view, that would surely be useful. I would very 
much welcome a configuration option within the 
dnssec-policy-statement, to globally enable inline-signing for all 
dnssec-signed zones.


Matthijs, regarding your question about "adding inline-signing to 
dnssec-policy": Is this something you'll be implementing in the near 
future?


tl;dr probably, for some definition of near.


I haven't made up my mind yet.

On the one hand I don't think "inline-signing" is really a *key and 
signing* policy option, so it feels misplaced.


On the other hand it is kind of cumbersome to include "inline-signing 
yes;" in all of your zones that use/inherit dnssec-policy.


I do believe the latter argument is a stronger one the "it feels wrong" 
argument though, so I am leaning more towards of adding an 
"inline-signing" option inside "dnssec-policy".



- 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 introduce automatic signing for existing signed zones?

[Matthijs Mekking]

Niall,

Thanks for reporting back. This is an omission in our KB article that I 
will fix.


- Matthijs

On 07-11-2022 18:24, Niall O'Reilly wrote:

On 7 Nov 2022, at 11:40, Niall O'Reilly wrote:


Preparation:

- Set up minimal stand-alone instance of BIND9 named,
   configured with a **dnssec-policy** for each algorithm,
   matching properties of existing DNSSEC keys, and with
   `lifetime unlimited`;
- Deliver current key files and recently-signed copy of
   zone files to this instance.


I needed an additional stage of preparation, before delivering
the key files; specifically, I needed to edit the .private
files to 'Private-key-format: v1.3' and add missing lifecycle
metadata.

After doing this, named behaved exactly as expected.

Thanks, Matthijs, for steering me in the right direction,
and for being ready to give me additional help.

/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: How to introduce automatic signing for existing signed zones?

[Matthijs Mekking]

On 07-11-2022 14:04, Matthijs Mekking wrote:

Hi Niall,

You need to share the dnssec-policy for no8.be in order to investigate 
why it doesn't show the expected behavior, but I suspect that the policy 
did not match the properties for the existing DNSSEC keys completely.


Ignore that, I saw too late there were attachments.

Are you able to share the public key and key state files with me so I 
can investigate why BIND thinks the existing keys cannot be used?


Also, the log file looks like an excerpt. A full debug (level 3) log 
would be useful too.


Best regards,

Matthijs




Best regards,

Matthijs

On 07-11-2022 12:40, Niall O'Reilly wrote:

I have a couple of zones which I want to migrate from CLI-driven
signing to BIND9 automatic signing, while avoiding any change to
the respective parent-zone DS RR.

Status quo ante:

- https://dnsviz.net/d/no8.be/dnssec/
   separate KSK, ZSK; both using alg 13
- https://dnsviz.net/d/jamm.ie/dnssec/
   2048-bit KSK, 2x 1024-bit ZSKs (live and spare); all using alg 8

Preparation:

- Set up minimal stand-alone instance of BIND9 named,
   configured with a **dnssec-policy** for each algorithm,
   matching properties of existing DNSSEC keys, and with
   `lifetime unlimited`;
- Deliver current key files and recently-signed copy of
   zone files to this instance.

Expected behaviour on starting named:

- Zones are loaded;
- Spare ZSK for jamm.ie is retired;
- Other keys for each zone are accepted and retained;
- A CDS RR is generated for each zone, matching the current DS RR.

Observed behaviour:

- `named -v` shows `BIND 9.18.8 (Stable Release) `;
- Zones are loaded;
- Spare ZSK for jamm.ie is retired;
- Other RSA/SHA-256 keys (for jamm.ie) are accepted and retained;
- A CDS RR is published for jamm.ie, matching the current DS RR;
- ECDSAP256SHA256 keys (for no8.be) are not accepted;
- New ECDSAP256SHA256 keys are created for no8.be;
- No CDS RR is generated for no8.be.

Unless I'm missing something, there seems to be a discrepancy
according to key type between the handling of RSA/SHA-256 and
ECDSAP256SHA256 keys respectively.

/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: How to introduce automatic signing for existing signed zones?

[Matthijs Mekking]

Hi Niall,

You need to share the dnssec-policy for no8.be in order to investigate 
why it doesn't show the expected behavior, but I suspect that the policy 
did not match the properties for the existing DNSSEC keys completely.


Best regards,

Matthijs

On 07-11-2022 12:40, Niall O'Reilly wrote:

I have a couple of zones which I want to migrate from CLI-driven
signing to BIND9 automatic signing, while avoiding any change to
the respective parent-zone DS RR.

Status quo ante:

- https://dnsviz.net/d/no8.be/dnssec/
   separate KSK, ZSK; both using alg 13
- https://dnsviz.net/d/jamm.ie/dnssec/
   2048-bit KSK, 2x 1024-bit ZSKs (live and spare); all using alg 8

Preparation:

- Set up minimal stand-alone instance of BIND9 named,
   configured with a **dnssec-policy** for each algorithm,
   matching properties of existing DNSSEC keys, and with
   `lifetime unlimited`;
- Deliver current key files and recently-signed copy of
   zone files to this instance.

Expected behaviour on starting named:

- Zones are loaded;
- Spare ZSK for jamm.ie is retired;
- Other keys for each zone are accepted and retained;
- A CDS RR is generated for each zone, matching the current DS RR.

Observed behaviour:

- `named -v` shows `BIND 9.18.8 (Stable Release) `;
- Zones are loaded;
- Spare ZSK for jamm.ie is retired;
- Other RSA/SHA-256 keys (for jamm.ie) are accepted and retained;
- A CDS RR is published for jamm.ie, matching the current DS RR;
- ECDSAP256SHA256 keys (for no8.be) are not accepted;
- New ECDSAP256SHA256 keys are created for no8.be;
- No CDS RR is generated for no8.be.

Unless I'm missing something, there seems to be a discrepancy
according to key type between the handling of RSA/SHA-256 and
ECDSAP256SHA256 keys respectively.

/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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[Matthijs Mekking]

On 26-10-2022 20:21, PGNet Dev wrote:

hi,

If there are currently no keys that we have to check the DS for, then 
you may still see this log line.


all my zones have now toggled rumoured -> omnipresent.  i took no 
explicit manual action other than letting an arbitrarily long-ish time 
pass.

it just happened ... eventually.


It is not arbitrary, as I said in the other thread:

BIND is waiting to make sure the new DS is also known to the validators.
The time being evaluated here is the DS TTL, plus 
parent-propagation-delay, plus retire-safety.



re: your comment "we have to check the DS for", what exec _forces_ a 
(re)check of keys' DS ?


i'd understood

   rndc dnssec -checkds published ${zone}

to do exactly that.  i.e., check 'NOW'.
and, since the DS were clearly published and available @ my each/all of 
my parental-agents{}, that the state toggle would happen, similarly, 
'NOW'. or at least NOW-ish.


is that incorrect?


Yes, because while the check happens immediately, we don't know for how 
long the DS has been in the parent. That is why there is a delay of DS 
TTL, plus parent-propagation-delay, plus retire-safety.


- 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: A beginner's guide to DNSSEC with BIND 9

[Matthijs Mekking]

On 24-10-2022 20:43, Richard T.A. Neal wrote:

Jan-Piet Mens wrote:


A Beginner's Guide to DNSSEC with BIND 9.



Well done! A few comments, if I may:


{snip}

Thanks JP, I really appreciate the feedback. I'll take all of that onboard, 
change my zones and guide from master/slave to primary/secondary, and take a 
look at TSIG as well.

As PGNet Dev said, I would also be interested to hear more about "inline-signing 
might go away". In fact when creating my first DNSSEC zone I initially *did not* 
include this statement in the zone file, but this caused named to fail to start and it 
threw the following error:

'dnssec-policy;' requires dynamic DNS or inline-signing to be configured for 
the zone

Like PGNet Dev I would also prefer to continue to hand-edit my zone files for 
the time being (rather than using a tool such as nsupdate) so I'm interested to 
hear if this will still be supported or what the roadmap is for deprecating the 
ability to hand-edit these files for DNSSEC-enabled zones.


The inline-signing feature will not go away.

When introducing dnssec-policy, my goal was to reduce the dozens of 
DNSSEC related configuration options, but despite what I thought earlier 
when I started to work on this, the inline-signing options is still needed.


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: 'inline-signing' might go away and be replaced by dnssec-policy ?

[Matthijs Mekking]

Thanks for this. It probably should be removed from the docs at this point.

When introducing dnssec-policy, my goal was to reduce the dozens of 
DNSSEC related configuration options that are scattered throughout 
named.conf and contain them in one stanza. But some options are more 
difficult to be replaced than others.


On 24-10-2022 18:16, PGNet Dev wrote:

i've read this comment


'inline-signing' might go away and be replaced by dnssec-policy


now a few times, in posts and in docs

currently, WITH 'dnssec-policy' signing enabled & in-use, i've

 zone "example.com" IN {
     type master; file "namedb/primary/example.com.zone";
     dnssec-policy "test";
     inline-signing yes;
     ...

the 'inline-signing yes;' is needed IN ADDITION to 'dnssec-policy' in 
order to _not_ overwrite original zone files/data on signing.  e.g., 
with the config above


 cd namedb/primary/
 ls -1 *example*
     example.com.zone  < THIS is the original, unsigned 
zone data

     example.com.zone.jbk
     example.com.zone.jnl
     example.com.zone.signed   < THIS is the signing-generated 
zone data, which gets propagated

     example.com.zone.signed.jnl

without it, the original "example.com.zone" is overwritten with signed 
data.


is there already config in, or planned for, 'dnssec-policy' that 
preserves that separate-file functionality, preserving the original?


There are two ways of DNSSEC maintenance in BIND. One is the 
inline-signing approach, that preserves the original zone file. The 
other is to apply the changes directly to the zone (and zone file) and 
requires the zone to allow dynamic updates.


Since the latest release dnssec-policy requires either inline-signing to 
be set to yes, or allow dynamic updates.


I am thinking of adding inline-signing to dnssec-policy, do you think 
that would that be useful?


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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[Matthijs Mekking]

On 24-10-2022 15:14, PGNet Dev wrote:

The good news it is not stuck.


What indicator flags that it IS 'stuck'?  Is it explicitly logged?


Because the keymgr logs says it is just waiting time?

2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: time says no to KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT (wait 93600 seconds)



BIND is waiting to make sure the new DS is also known to the 
validators. The time being evaluated here is the DS TTL, plus 
parent-propagation-delay, plus retire-safety. All these three values 
are configurable within dnssec-policy.


my current config has

 parent-ds-ttl  PT1H;
 parent-propagation-delay   PT1H;
 retire-safety  PT1H;

@ parental-agents, the DS is cached; ttl appears spec'd other than my 
set ttl. e.g., @ cloudflare, it's 1 day ...


in any case, all of my domains still returned "DSState: rumoured" at < 4 
days.
since then, about 1/4 of the domains have flipped from "rumoured" -> 
"omnipresent", with no manual intervention; the rest are still unchanged.


again, i've noticed no actual operational problems -- e.g., queries 
failing, etc -- other than these delays.


seems, tho, i've still got a likely misconfig somewhere in here.


I am happy to look into it, if you are willing to share the key 
**state** file in question (off-list), and dnssec-policy configuration.


A full excerpt of the debug logs around 2022-10-21T16:55:22 can also be 
useful.


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: after DS RECORD publish/verify, DSStatus stuck @ "rumoured" after manual `rndc dnssec -checkds` update ?

[Matthijs Mekking]

Hi,

On 21-10-2022 23:05, PGNet Dev wrote:

I exec

 rndc dnssec -checkds -key 63917 published example.com IN external


with dnssec loglevel -> debug, on exec, in logs

   2022-10-21T16:55:22.690603-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: examine KSK 
example.com/ECDSAP256SHA256/63917 type DS in state RUMOURED
   2022-10-21T16:55:22.690608-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: can we transition KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT?
   2022-10-21T16:55:22.690615-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: dnssec evaluation of KSK 
example.com/ECDSAP256SHA256/63917 record DS: rule1=(~true or true) 
rule2=(~true or true) rule3=(~false or false)
   2022-10-21T16:55:22.690622-04:00 ns named[36683]: 21-Oct-2022 
16:55:22.689 dnssec: debug 1: keymgr: time says no to KSK 
example.com/ECDSAP256SHA256/63917 type DS state RUMOURED to state 
OMNIPRESENT (wait 93600 seconds)


which certainly looks like a 'no'

reason is "time says no", after "dnssec evaluation".

which time is being evaluated here?


The good news it is not stuck. BIND is waiting to make sure the new DS 
is also known to the validators. The time being evaluated here is the DS 
TTL, plus parent-propagation-delay, plus retire-safety. All these three 
values are configurable within dnssec-policy.


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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[Matthijs Mekking]

Which parental-agent to use is up to you. Something you trust.

You can also configure multiple, if so then all parental agents will 
perform the DS check and only if all parental agents agree (have seen 
the DS), BIND will set the DS as "seen published in the parent" and the 
rollover will continue.


Best regards,

Matthijs


On 14-10-2022 16:33, PGNet Dev wrote:
This is a log level bug. This log happens when BIND want to check the 
parental-agents if the DS has been published. But if you don't have 
parental-agents set up, the list of keys to check will be empty. Hence 
the "not found" result.


Thanks for reporting, this will be fixed in the next release, it 
should be a debug log level.


+1 o/

i'd completely missed 'parental-agents' :-/

sounds like i likely *should* have it setup in any case; esp if using 
dnssec-policy key rollovers (i am)


reading

 
https://bind9.readthedocs.io/en/latest/chapter5.html?highlight=parental-agents#key-rollover

i get the part it plays

unclear though which specific server one should use; in the example txt,

 "Here one server, 192.0.2.1, is configured for BIND to send DS 
queries to, to check the DS RRset for dnssec-example during key 
rollovers. This needs to be a trusted server, because BIND does not 
validate the response."


atm, my registrar/TLD don't support CDS/CDNSKEY (for .com, in this case)

so my DS RECORD gets manually entered @ registrar's web portal.

then, record propagates to roots, which -- eventually -- return 
RRSIG/RRSET data on queries.


for rollover mgmt, what server should be set as parental-agent?
my registrar's?
a root?
something 'big', like cloudflare/1.1.1.1 ?
other?

--
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: new dnssec zone OK, error "zone_rekey:dns_zone_getdnsseckeys failed: not found" only in local bind logs ?

[Matthijs Mekking]

Hi,

This is a log level bug. This log happens when BIND want to check the 
parental-agents if the DS has been published. But if you don't have 
parental-agents set up, the list of keys to check will be empty. Hence 
the "not found" result.


Thanks for reporting, this will be fixed in the next release, it should 
be a debug log level.


Best regards,

Matthijs

On 14-10-2022 15:26, PGNet Dev wrote:

i run,

 named -v
     BIND 9.18.7 (Stable Release) 


i've setup dnssec-policy operation for a number of domain.

keys are all generated, KSK-derived DS Records are pushed to 
registrar->root, and all DNSSEC-analyzer tools online report all's good.


i can see no functional problems. so far. that i'm aware of.

but, in bind logs, locally, I see the following 
"zone_rekey:dns_zone_getdnsseckeys failed: not found" error,


 2022-10-14T08:47:23.569556-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.568 dnssec: info: zone example.com/IN/external: generated salt: 
82CSA124A1645B0D
 2022-10-14T08:47:23.711869-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.710 dnssec: info: zone example.com/IN/external: reconfiguring 
zone keys
??    2022-10-14T08:47:23.712653-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: error: zone example.com/IN/external: 
zone_rekey:dns_zone_getdnsseckeys failed: not found
 2022-10-14T08:47:23.712663-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: keyring: 
example.com/ECDSAP256SHA256/62137 (policy pgnd)
 2022-10-14T08:47:23.712666-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: keyring: 
example.com/ECDSAP256SHA256/17296 (policy pgnd)
 2022-10-14T08:47:23.712671-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: DNSKEY 
example.com/ECDSAP256SHA256/17296 (KSK) matches policy pgnd
 2022-10-14T08:47:23.712674-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: DNSKEY 
example.com/ECDSAP256SHA256/17296 (KSK) is active in policy pgnd
 2022-10-14T08:47:23.712677-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: DNSKEY 
example.com/ECDSAP256SHA256/62137 (ZSK) matches policy pgnd
 2022-10-14T08:47:23.712680-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: DNSKEY 
example.com/ECDSAP256SHA256/62137 (ZSK) is active in policy pgnd
 2022-10-14T08:47:23.712683-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: new successor needed for DNSKEY 
example.com/ECDSAP256SHA256/62137 (ZSK) (policy pgnd) in 2445436 seconds
 2022-10-14T08:47:23.712686-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine ZSK 
example.com/ECDSAP256SHA256/62137 type DNSKEY in state OMNIPRESENT
 2022-10-14T08:47:23.712688-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: ZSK 
example.com/ECDSAP256SHA256/62137 type DNSKEY in stable state OMNIPRESENT
 2022-10-14T08:47:23.712690-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine ZSK 
example.com/ECDSAP256SHA256/62137 type ZRRSIG in state OMNIPRESENT
 2022-10-14T08:47:23.712693-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: ZSK 
example.com/ECDSAP256SHA256/62137 type ZRRSIG in stable state OMNIPRESENT
 2022-10-14T08:47:23.712695-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine KSK 
example.com/ECDSAP256SHA256/17296 type DNSKEY in state OMNIPRESENT
 2022-10-14T08:47:23.712697-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: KSK 
example.com/ECDSAP256SHA256/17296 type DNSKEY in stable state OMNIPRESENT
 2022-10-14T08:47:23.712699-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine KSK 
example.com/ECDSAP256SHA256/17296 type KRRSIG in state OMNIPRESENT
 2022-10-14T08:47:23.712702-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: KSK 
example.com/ECDSAP256SHA256/17296 type KRRSIG in stable state OMNIPRESENT
 2022-10-14T08:47:23.712704-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: examine KSK 
example.com/ECDSAP256SHA256/17296 type DS in state RUMOURED
 2022-10-14T08:47:23.712706-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: can we transition KSK 
example.com/ECDSAP256SHA256/17296 type DS state RUMOURED to state 
OMNIPRESENT?
 2022-10-14T08:47:23.712712-04:00 ns named[14285]: 14-Oct-2022 
08:47:23.711 dnssec: debug 1: keymgr: dnssec evaluation of KSK 
example.com/ECDSAP256SHA256/17296 record DS: rule1=(~true or true) 
rule2=(~true or true) rule3=(~true or true)


for each/every dnssec-enabled domain

where, in my current named.conf,

 dnssec-policy "pgnd" {
     keys {
     ksk key-directory    lifetime unlimited    algorithm 13;
     zsk key-directory    lifetime P30D algorithm 13;
     };
     dnskey-ttl 

Re: DNSSEC signing common zone in views

[Matthijs Mekking]

Hi Josef,

First of all I would like to point out the KB article about to 
dnssec-policy, especially the part about migrating.


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

Although we try to asses the current signing situation, since there are 
no key state files it will be an educated guess. Switching to a policy 
that doesn't match your current situation might lead to withdrawing 
existing signatures and keys too soon.


Once BIND is maintaining key states, it is safe to change your 
dnssec-policy to whatever you want. BIND will gradually move to the new 
desired

policy, possibly doing key (algorithm) rollovers.

Key rollovers happen automatically, but since you are using an unlimited 
lifetime they will never be triggered unless manually with rndc.


There is one manual step that needs to be performed during CSK and KSK 
rollovers, that is updating the DS RRset to the parent. Once that is 
done you can run the related 'rndc dnssec -checkds' commands.


Or you can set up parental-agents that would check for the DS in the 
parent automatically.


As long as you use the same dnssec-policy for the zones, you can use the 
same key-directory (since 9.16.18). The key rollover would happen at the 
same time for the zone.


You can also set a different key-directory. In that case the key is not 
shared, each view of the zone would have a separate DNSSEC key.


I think it is fine using the same key-directory. The only thing is when 
you change your configuration in the future such that the dnssec-policy 
is different for each view of the zone, you have to also change the 
key-directory to be different.


Best regards,

Matthijs



On 07-09-2022 15:19, Josef Vybíhal wrote:

Hello all,
I am consolidating our old split DNS consisting of internal and
external dedicated servers(VMs) into one primary server with views
(there will be secondaries, but they are not important to the
question). The old previous configuration is using inline-signing and
auto-dnssec. I will be switching to dnssec-policy with csk. This is
fine.

My question is what would be considered best practice when I want the
zone to be signed by the same CSK in every view. Should I point both
zones to the same "key-directory", or should I use a different
directory for every view? And how would the key rollover work in such
a case?

I have tried to use the same key-directory for both zones in each
view. It seems to technically work. But maybe someone could point out
some disadvantages I will be facing in the future? Is there common
consensus on how this is supposed to be approached? Maybe I am
handling it all wrong and there is a much better way :)


The config I tested:

dnssec-policy "ACME" {
 keys { csk key-directory lifetime unlimited algorithm 13; };
 nsec3param iterations 1 optout false salt-length 16;
};

view internal {

 match-clients { internal; };

 zone "ACME.cz" {
 type primary;
 file "primary/internal/ACME.cz/ACME.cz.zone";
 inline-signing yes;
 key-directory "dnssec-keys/ACME.cz";
 dnssec-policy "ACME";
 };

};

view external {

 match-clients { external; };

 zone "ACME.cz" {
 type primary;
 file "primary/external/ACME.cz/ACME.cz.zone";
 inline-signing yes;
 key-directory "dnssec-keys/ACME.cz";
 dnssec-policy "ACME";
 };

};


---

ns1-new /var/named/dnssec-keys/ACME.cz # cat KACME.cz.+013+14237.state
; This is the state of key 14237, for ACME.cz.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20190611121855 (Tue Jun 11 14:18:55 2019)
Published: 20190611121855 (Tue Jun 11 14:18:55 2019)
Active: 20190611121855 (Tue Jun 11 14:18:55 2019)
PublishCDS: 20190612132355 (Wed Jun 12 15:23:55 2019)
DNSKEYChange: 20220907123627 (Wed Sep  7 14:36:27 2022)
ZRRSIGChange: 20220907123627 (Wed Sep  7 14:36:27 2022)
KRRSIGChange: 20220907123627 (Wed Sep  7 14:36:27 2022)
DSChange: 20220907123627 (Wed Sep  7 14:36:27 2022)
DNSKEYState: omnipresent
ZRRSIGState: omnipresent
KRRSIGState: omnipresent
DSState: rumoured
GoalState: omnipresent

# named -V
BIND 9.18.6 (Stable Release) 
running on Linux x86_64 4.18.0-372.19.1.el8_6.x86_64 #1 SMP Tue Aug 2
16:19:42 UTC 2022




Thanks,
Josef

--
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: Old DNSKEYs still in zone despite status showing hidden

[Matthijs Mekking]

Magnus,

On 11-08-2022 11:26, Magnus Holmgren wrote:

onsdag 10 augusti 2022 kl. 11:21:11 CEST skrev  Matthijs Mekking:

On 10-08-2022 11:13, Magnus Holmgren wrote:

One question: Is it
necessary to use rndc dnssec -checkds or is that only meant as a backup,
and named is supposed to query the parent for DS records automatically?


That depends if you have set up parental-agents. If not, then you need
to run 'rndc dnssec -checkds'.


I see. I find the documentation a bit sparse, however. "A parental agent is
the entity that is allowed to change a zone’s delegation information (defined
in RFC 7344)."; "Parental Agent: The entity that the Child has a relationship
with to change its delegation information." So what list of servers is it that
I'm configuring, exactly? The "hard" part is change the delegation
information, but that's done through CDS records, which it turns out our
registrar supports. Verifying that the new DS record is in place should be a
trivial matter of walking the chain from the root zone, should it not? Should
I simply list a couple of the respective TLD's name servers? The registrar
doesn't provide any special server(s) for the purpose, AFAICT.


There are two common scenarios, I think.

First is list all the public parent servers and add those to your 
parental-agents configuration. BIND will only continue the rollover if 
the new DS has been seen at all those servers.


Second is set up a local validating resolver. When the DS is validated 
by the resolver, you can assume it is published correctly in the parent.



Is the idea that you query the parental agent to see that they've picked up
the CDS and then you trust that the parent zone will be updated within the
parent-propagation-delay? That doesn't seem right; you'd want to make sure
that the new DS is visible to the world, right?


Not really.

BIND will query the parental agent to see if they published the DS 
(corresponding to the CDS, yes). So it knows for sure it is visible to 
the world.


The parent-propagation-delay is a safety delay to ensure that the DS has 
been published to all parent secondaries.



Best regards,

Matthijs



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: dnssec-policy: Old DNSKEYs still in zone despite status showing hidden

[Matthijs Mekking]

On 10-08-2022 11:21, Matthijs Mekking wrote:
The last zone, milltime.se, has become stuck. sudo rndc dnssec -status 
reports
that the old keys are removed from the zone and the new keys are 
omnipresent,
but the log says "zone milltime.se/IN (signed): Key 
milltime.se/RSASHA1/22971

missing or inactive and has no replacement: retaining signatures."

Never mind. I was too quick switching to NSEC3, which is incompatible 
with the

old key. Switching back to NSEC allowed the rollover to complete. Still,
shouldn't BIND have been able to figure this out on its own? It kept 
using
NSEC because of the incompatible key, and it kept the incompatible key 
needed
to verify the NSEC records. Catch-22? (Yes, I've read about the 
questionable

merits of NSEC3.)


I think we could improve named-checkconf to error out on a policy that 
uses NSEC3 with an incompatible algorithm yes. Thanks for the suggestion.


I jumped on this one too quickly. There is actually already a checkconf 
for this.


But your issue is slightly different. It is about configuring NSEC3 when 
the previous configuration uses an incompatible DNSKEY algorithm.


This is not easy to check with named-checkconf. But also, this is 
already caught by named.


You already witnessed some log messages indicating things are wrong: Key 
milltime.se/RSASHA1/22971 missing or inactive and has no replacement: 
retaining signatures." But perhaps you also saw this one: "zone 
milltime.se/IN (signed): NSEC only DNSKEYs and NSEC3 chains not allowed" 
which is more informative.


You recovered from this the right way: Switch back to using NSEC, until 
the old keys are gone from the zone, then you can enable NSEC3.


At first I thought BIND9 is handling this fine, but giving it another 
thought I think you are right that BIND could figure this out and rather 
than blocking signing because of the erroneous state, hold off creating 
NSEC3 chain until the offending DNSKEYs have been removed from the zone.


So here is a merge request that you can try out, or you can wait until 
this makes a 9.18 release:


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

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: Old DNSKEYs still in zone despite status showing hidden

[Matthijs Mekking]

Hi Magnus,

On 10-08-2022 11:13, Magnus Holmgren wrote:

Hi,

I migrated a couple of zones from BIND 9.16.6 on SuSE to 9.16.27 on Debian and
at the same time switched from auto-dnssec maintain to a dnssec-policy with
RSASHA256 instead of RSASHA1 (actually, I first applied a policy matching the
old keys and with unlimited lifetime to avoid confusing BIND).

Though it seems to take longer than expected to finish a key rollover, even
taking into account propagation delay, TTLs, and retire-safety, the old keys
were eventually removed from the first zone. One zone I'm still waiting for,
and that rollover started Friday. One question: Is it necessary to use rndc
dnssec -checkds or is that only meant as a backup, and named is supposed to
query the parent for DS records automatically?


That depends if you have set up parental-agents. If not, then you need 
to run 'rndc dnssec -checkds'.




The last zone, milltime.se, has become stuck. sudo rndc dnssec -status reports
that the old keys are removed from the zone and the new keys are omnipresent,
but the log says "zone milltime.se/IN (signed): Key milltime.se/RSASHA1/22971
missing or inactive and has no replacement: retaining signatures."

Never mind. I was too quick switching to NSEC3, which is incompatible with the
old key. Switching back to NSEC allowed the rollover to complete. Still,
shouldn't BIND have been able to figure this out on its own? It kept using
NSEC because of the incompatible key, and it kept the incompatible key needed
to verify the NSEC records. Catch-22? (Yes, I've read about the questionable
merits of NSEC3.)


I think we could improve named-checkconf to error out on a policy that 
uses NSEC3 with an incompatible algorithm yes. Thanks for the suggestion.



The subject of the mail seems to indicate a different problem than the 
body, or am I missing something?



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

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

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

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

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: 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: dnssec: ds showing hidden 3+ days after key roll

[Matthijs Mekking]

sec: 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,

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,

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

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

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

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

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

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

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

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