On 17-05-2025 06:39, Crist Clark wrote:
Tired of looking at the log messages warning me that inline-signing will
be the default in 9.20. I want to convert my 9.18 to using
inline-signing. Right now all of the zones use dnssec-policy and are
dynamic.
I tried just simply adding the "inlien-si
On 4/9/25 02:29, Bagas Sanjaya wrote:
On Tue, Apr 08, 2025 at 07:38:44AM -0500, Matthijs Mekking wrote:
This time I was able to reproduce, thanks.
The reason why the key created by dnssec-keygen is retired because named
thinks it was in use already. When there is key timing metadata, the
successor in key
rollovers.
Try generating the key with dnssec-keygen -G. This will create a key
without setting timing metadata.
I will update the documentation accordingly.
Best regards,
Matthijs
On 4/8/25 05:43, Bagas Sanjaya wrote:
On Mon, Apr 07, 2025 at 09:28:07AM -0500, Matthijs Mekking
Hi,
I have tried to reproduce but when I am issuing a rollover it selects
the key I generate previously, as expected.
If you believe this is a genuine bug, please support a bug report:
https://gitlab.isc.org/isc-projects/bind9/-/issues/new?issuable_template=Default
and fill in the steps how
You can set 'purge-keys' to a value you feel comfortable with. By
default it is set to 90 days, so after 90 days the key is completely
hidden, it will be removed from disk.
Best regards,
Matthijs
On 19-03-2025 09:29, adrien sipasseuth wrote:
Hello,
I use Bind 9.20.4, with KASP policy to set
sign my zone?
This happens anyway during a Double-DS rollover scheme, so I don't think
it is bad practice. A resolver may have to do a bit more work, but
negligible in my opinion.
- Matthijs
On 26-02-2025 00:13, Bernd Naumann wrote:
On 24.02.25 9:47 AM, Matthijs Mekking wrote:
Hi Be
On 24-02-2025 11:51, Bernd Naumann wrote:
...
In 9.18, I would suggest to disable inline-signing and just add the
DNSKEY record to the zone. Don't put the key files for the stand-by key
in the 'key-directory', this should only hold signing keys.
Jep I've done that; except "Don't put the ke
Hi Bernd,
On 24-02-2025 10:12, Bernd Naumann wrote:
Hi Matthijs, thanks for your response.
On 24.02.25 9:47 AM, Matthijs Mekking wrote:
Hi Bernd,
Non-signing keys (for example a stand-by key), is a bit tricky in
dnssec-policy and not fully supported.
Yeah I figured that in the mean time
Hi Bernd,
Non-signing keys (for example a stand-by key), is a bit tricky in
dnssec-policy and not fully supported.
In 9.18, I would suggest to disable inline-signing and just add the
DNSKEY record to the zone. Don't put the key files for the stand-by key
in the 'key-directory', this should o
Hi,
The timings are based on RFC 7583 and "Flexible and Robust Key Rollover
in DNSSEC". They may help a great deal in understanding the time states.
https://datatracker.ietf.org/doc/html/rfc7583
https://nlnetlabs.nl/downloads/publications/satin2012-Schaeffer.pdf
See below for inline answers.
Hi Emmanuel,
Please see https://gitlab.isc.org/isc-projects/bind9/-/issues/5137
- Matthijs
On 06-02-2025 10:45, Emmanuel Fusté wrote:
Hello,
BIND 9.20.5 is supposed to implement EDE 22 reporting (No reachable
authority)
Ubuntu 22.04 / ISC BIND packages
I have a domain for which the two DNS
If the RRset in the answer or authority section triggers additional
processing, and the RRset has more than 13 different names, we skip
additional processing for that RRset.
So it can add more than 13 records to the additional section.
You are right that we also no longer do additional data pr
Hi,
To automate this you need to configure parental-agents.
From 9.20.0 you can use the new 'checkds' option to automatically
populate parental-agents.
Best regards,
Matthijs
On 11/8/24 12:23, Τάσος Λολότσης wrote:
Hello
Thank you very much for the reply. I thought this was happening
au
If you provide the output of `rndc dnssec -status` it might give a hint
why the keys are still published.
I suspect that BIND needs to be told that the DS has been withdrawn for
the parent zone (assuming you don't have parental-agents set up).
For future algorithm rollovers: You can just chan
Danilo
On 2. 10. 24 15:13, Matthijs Mekking wrote:
Hi,
The change from rumoured to omnipresent is TTL dependent. To be
precise: it is the sum of the configured parent-ds-ttl,
parent-propagation-delay, and retire-safety.
- Matthijs
On 10/2/24 14:55, Danilo Godec via bind-users
change be immediate or is it also TTL dependent?
Regards,
Danilo
On 2. 10. 24 13:10, Matthijs Mekking wrote:
Hi Danilo,
When you enable DNSSEC for the first time, first the DNSKEY and the
signatures need to be introduced in the zone, and propagated to the
world. The propagation depe
Hi Danilo,
When you enable DNSSEC for the first time, first the DNSKEY and the
signatures need to be introduced in the zone, and propagated to the
world. The propagation depends on the TTL values, and these are derived
from the dnssec-policy configuration. By default it takes more than a
day
On 10/1/24 09:44, Klaus Darilion wrote:
Hi Matthijs!
I always had the impression that dnssec-signzone is a stand-alone
utility and signing is done either with dnssec-signzone or with
Bind's dnssec-policy. Does it really work to use dnssec-signzone on a
zone and journal that is managed by name
Hi Klaus,
With dnssec-policy you can specify the salt length, not a specific salt.
You can still use dnssec-signzone -3 to manually set a salt.
Best regards,
Matthijs
On 9/30/24 22:38, Klaus Darilion via bind-users wrote:
Hello!
With "auto-dnssec maintain;" I was used to specify the NSEC3 s
Hi Erik,
There is no configuration option for enabling multi-signer in BIND.
BIND 9.20 is able to deal with multi-signer setups, but as Mark
mentioned earlier, all the coordination needs to be done outside the
name server.
You may consider MUSIC for this:
https://github.com/DNSSEC-Provision
Hi Casey,
Don't muck around with dnssec-settime. As Peter mentioned earlier, your
key seems to be in rollover, awaiting DS publication. I'll repeat what
he said:
The DS for the new key is only rumored. If you have seen the DS in the
parent, tell BIND so:
rndc dnssec -checkds -key 48266
On 7/18/24 15:53, vom513 wrote:
Hello all,
I could have sworn I saw mention on this list at some point of this (just can’t
find it in the archives).
I currently run a 9.18.x BIND and I use parental agents for automatic key
rollover. I have a script that builds these and I included them in my
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 ecds
g 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<--
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
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 configuratio
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
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 us
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
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
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
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
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
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.
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 t
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.
Upgrade to 9.18, because 9.16 does not support extended DNS errors.
See
https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_date&state=all&label_name%5B%5D=Extended%20DNS%20Errors&first_page_size=20
For which errors are supported.
Best regards, Matthijs
On 7/11/23 11:10, sami.ra.
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 :-(
--
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
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?)
P
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
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"
l
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
> Ni
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/bin
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
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
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
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
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 configuratio
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:
t 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
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 jan
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.
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
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 late
"/ **/ ** / ** .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 <m
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
c
'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 s
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 w
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 s
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//
//
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
> cor
ov 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,
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 g
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
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 YY
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 'a
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 ver
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-po
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 sa
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:
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
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/s
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 b
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:
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
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 contin
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 re
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
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
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
missi
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
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:4
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
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:
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 Fi
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)
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
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-u
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.
ent 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
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,
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
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
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 wrot
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 key
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
6: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 w
rn 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
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 t
1 - 100 of 154 matches
Mail list logo
