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
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=flo
js
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
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 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
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
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
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
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
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
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
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?)
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"
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
>
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.
.
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
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
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
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:
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.or
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. 202
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
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
;/ **/ ** / ** .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
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
'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
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
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
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
>
v 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
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
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
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
{
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.
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
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
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
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.
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
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
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
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
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
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
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
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
mi
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
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
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
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
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
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
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.
t 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 Mekk
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
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
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
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
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
ighonker.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
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
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
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
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
gards,
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 a
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 132 matches
Mail list logo
