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
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
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
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
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
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,
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
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:
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 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
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
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 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
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
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
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
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
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
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
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,
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
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,
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
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
'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
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
"/ **/ ** / ** .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 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
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
Dear BIND 9 users,
The BIND 9 development team has been discussing whether we should remove
the DLV code from the BIND 9 source. Reasons for doing this:
* The zone dlv.isc.org has been decommissioned some time ago.
* It will make the code much easier to maintain, which is beneficial for
users
Hi Grant,
On 5/20/19 11:44 PM, Grant Taylor via bind-users wrote:
On 5/20/19 4:34 AM, Matthijs Mekking wrote:
* It will make the code much easier to maintain, which is beneficial
for users too since that will mean in general less bugs, easier to
find bugs, and easier to extend it with new
Dear BIND 9 users,
BIND 9 has a lot of configuration options. Some have lost value over
the years, but the policy was to keep the options to not break old
configurations.
However, we also want to clean up the code at some point. Keeping these
options increases the number of corner cases and mak
Hi,
On 6/13/19 2:40 PM, G.W. Haywood via bind-users wrote:
> Hi there,
>
> On Thu, 13 Jun 2019, Matthijs Mekking wrote:
>
>> We would like to hear your feedback.
>
> Thank you for the timely heads up.
>
>> | managed-keys | 9.15/9.16 | replaced with d
st regards,
Matthijs
On 5/20/19 12:34 PM, Matthijs Mekking wrote:
> Dear BIND 9 users,
>
> The BIND 9 development team has been discussing whether we should remove
> the DLV code from the BIND 9 source. Reasons for doing this:
>
> * The zone dlv.isc.org has been decommissioned some ti
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
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 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
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
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
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
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
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 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
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
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
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
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.
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,
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 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
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
101 - 154 of 154 matches
Mail list logo
