Re: [KASP] Key rollover

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.

Re: [KASP] Key rollover

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

Re: [KASP] Key rollover

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

Re: isc stork agent and named chroot

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:

Re: (use-)alt-transfer-source deprecated

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

Re: Determine parental-agents automatically

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

Re: KASP: sharing policy and keys between views

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

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

Re: Fully automated DNSSEC with BIND 9.16

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

Re: Piggybacking on a zone’s dnssec-policy using auto-dnssec: How can one do this after Bind 9.19?

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

Re: Piggybacking on a zone’s dnssec-policy using auto-dnssec: How can one do this after Bind 9.19?

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

Re: Old ZSK refuses to retire

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

Re: dnssec-policy change from ZSK/KSK to CSK failed (bogus DNSSEC for zone)

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

Re: dnssec not automatically updating on 1 server

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

Re: DNSSEC doubt

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

Re: Master file permission denied

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

Re: extended dns error

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.

Re: DNSSec Setup ARM Manual vs KB article on adding inline-signing for non-dynamic zones

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.

Re: dnssec-policy syntax error in options but not in view

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

Re: question about DNSSEC with PKCS11

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.

Re: KASP Rollover = Immediate Loss of DNSKEY (Why Do Inactive Keys Disappear?)

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

Re: How to update zone with dnssec-policy (error with nsupdate: RRset exists)

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

Re: Old link in DNSSEC Guide for number of TLDs with DNSSEC

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

Re: KASP Key Rollover: ZSK Disappears Immediately

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

Re: Switching to a different dnssec-policy broke my zone.

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

Re: migration from auto-dnssec to dnssec-policy deletes keys immediately

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

Re: Problem upgrading to 9.18 - important feature being removed

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

Re: Problem upgrading to 9.18 - important feature being removed

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

Re: Problem upgrading to 9.18 - important feature being removed

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

Re: Problem upgrading to 9.18 - important feature being removed

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

Re: [DNSSEC] testing KASP

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

Re: checkds - min. version for this ?

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

Re: Deleting a key

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

Re: dnssec-policy & views

Hi Graham, On 2/29/20 5:27 PM, Graham Clinch wrote: > How does the new-in-9.16 dnssec-policy interact with views - in > particular for key generation/rollover? > > For example, we have a zone defined in multiple views with different > contents (and thus not suitable for in-view), being signed by

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

Hi Håkan, First of all, thanks for trying out the new dnssec-policy feature. I'll admit there is insufficient documentation and tooling around migration to dnssec-policy, possibly there is a bug too. Existing keys do not have a .state file, and so named will try to match those keys with the poli

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

is not yet suitable for your use case. We will implement NSEC3 for dnssec-policy in 9.17 and backport it to 9.16. Best regards, Matthijs On 3/25/20 8:50 PM, Shumon Huque wrote: > On Wed, Mar 25, 2020 at 9:04 AM Matthijs Mekking <mailto:matth...@isc.org>> wrote: > > Hi Håkan, &

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

ec-policy x" with "inline-signing no" does > not seem to be handled gracefully. > This makes me suspect that it's not an intended scenario, is that correct? > > > /Håkan > > On 2020-03-25 16:57, Håkan Lindqvist via bind-users wrote: >> On 2020-03-25 14

Re: Full automatic DNSSEC for hosted zones/domains

Hi Matthias, The answer is almost, as long as the zone has a DNSSEC policy configured: zone "newdomain.de" { type master; file "../master/newdomain.de"; dnssec-policy default; } The only thing not yet fully automated is submitting the DS to the parent. You can do that as soon as named p

Re: Full automatic DNSSEC for hosted zones/domains

Hi Philippe, On 4/7/20 3:46 PM, Philippe Maechler wrote: > Hello bind users > >> The answer is almost, as long as the zone has a DNSSEC policy configured: >> >> zone "newdomain.de" { >> type master; >> file "../master/newdomain.de"; >> dnssec-policy default; >> } >> >> The only thing not ye

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

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

Re: BIND-9.16.1 & KASP

Mark, On 4/13/20 8:54 PM, Evan Hunt wrote: > On Mon, Apr 13, 2020 at 02:22:53PM +0200, Mark Elkins wrote: >> Question - What are the "TYPE65534" records? What are they saying? I am >> using "DiG 9.16.1" so surprised it doesn't know. > > This is a mechanism named uses to keep track of the status

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

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

Re: KASP Inactive/Retired timestamps

Hi Gregory, Thanks for trying out out the new KASP. Let me try to answer your questions below. On 5/20/20 2:37 AM, Gregory Shapiro via bind-users wrote: > After the fantastic ISC DNSSEC webinar series last month, I began > using KASP for my DNSSEC signed zones. I have noticed an odd > behavior w

Re: DNSSEC migration sanity check

Hi John, It all depends on the key material that is used to sign your zone. It looks like you have to update the DNSKEY RRset, so I assume the vendors are responsible for signing and each have their own key material. In order to let the world know you are going to use new keys you will have to pr

Re: kasp-policy and catalog zones

Hi Christian, There are no plans for this. While technically a secondary can have a "dnssec-policy" statement (acting as a bump-in-the-wire signer), signing a zone is mainly a primary server responsibility and a policy configuration does not need to be transferred to its secondaries. For now I w

Re: auto RRSIG enable

And in 9.16 you can use the following line to sign your zones: dnssec-policy default; And you can create your own dnssec-policy if you need a different signing configuration. Best regards, Matthijs On 11/2/20 7:20 AM, Nyamkhand Buluukhuu wrote: > Hello, > > Yes you can define below configu

Re: ISC DNSSEC Guide - Working with the Parent Zone

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

Re: ISC DNSSEC Guide - Working with the Parent Zone

07:33:24 2020 zone signing: yes - since Wed Dec 23 09:38:24 2020 Next rollover scheduled on Wed Dec 30 07:33:24 2020 - goal: omnipresent - dnskey: omnipresent - ds: rumoured - zone rrsig: rumoured - key rrsig: omnipresent Daniel On 23

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

Hi Thomas, Your policy requests four keys in two algorithms: rsasha1 and ecdsap256sha256. The keys that are being retired are of algorithm rsasha256. Because the existing algorithms don't match the policy, they are being retired. In other words, it doesn't look like the existing keys were of

Re: Updating a DNSSEC config to use a different algorithm

Hi, Depends on what your DNSSEC configuration is. Are you using dnssec-signzone/named? auto-dnssec maintain? inline-signing? dnssec-policy? dnssec-keymgr? Yes there are a lot of ways to maintain DNSSEC in BIND. The recommended way forward is to use dnssec-policy. Migrating to it may still be

Re: Updating a DNSSEC config to use a different algorithm

On 01-02-2021 17:34, @lbutlr wrote: On 01 Feb 2021, at 07:14, Matthijs Mekking wrote: Depends on what your DNSSEC configuration is. Are you using dnssec-signzone/named? auto-dnssec maintain? inline-signing? dnssec-policy? dnssec-keymgr? These are all good questions, and when I set this up

Re: Updating a DNSSEC config to use a different algorithm

On 02-02-2021 14:40, @lbutlr wrote: On 02 Feb 2021, at 02:23, Matthijs Mekking wrote: 1. Create a dnssec-policy that matches your current keys (so in your case algorithm 7, also make sure you use the same length). So I guess something like: dnssec-policy alg13-ksk-unlimited-zsk-60day

Re: Updating a DNSSEC config to use a different algorithm

Hi, On 02-02-2021 18:16, @lbutlr wrote: On 02 Feb 2021, at 07:36, Matthijs Mekking wrote: If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ suits you better? The PDF works fine, and I can search for "dnssec" and "policy" but it is using so

Re: DNSKEY failure

Hi, On 05-02-2021 10:23, @lbutlr wrote: So, with my test domain that is using dsnssec-policy default dnsviz reports "DNSKEY: No response was received from the server over UDP" But: dig +norec +dnssec +bufsize=512 +ignore dnskey Shows a DNSKEY record. It would be useful to also provide the

Re: DNSSEC and NSEC missing ZSK?

Hi, On 08-02-2021 12:20, @lbutlr wrote: I feel I am getting close. I got the digest generated for hover.com and updated the DNS on the test zone, but I am getting errors on verify that I don't understand. #v+ # dnssec-verify -I text -o example.com /etc/namedb/working/example.com.signed Loadin

Re: Still seeing some ALG-7 DNSSE

Most likely you have to delete those files manually. In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By default the keys are retained for 90 days after their latest usage. So in that case keys will be cleaned up automatically. If you run a lower version, or if you set "p

Re: Still seeing some ALG-7 DNSSE

On 11-04-2021 01:22, @lbutlr wrote: On 06 Apr 2021, at 01:13, Matthijs Mekking wrote: In 9.16.13, a new "dnssec-policy" option is introduced, "purge-keys". By default the keys are retained for 90 days after their latest usage. So in that case keys will be clea

Re: Zone 126.0.0.1 has 0 SOIA records

Perhaps inspect the zone file? Also the CDS/CDNSKEY consistency checks stick out. Perhaps remove them from the unsigned zone files? Best regards, Matthijs On 12-04-2021 14:52, @lbutlr wrote: I restored a backup of my named.conf after a little bit of an oops. The file is the same exact file

Re: Ask for automated KSK roll with DS checking

On 14-04-2021 22:30, Greg Rivers via bind-users wrote: On Wednesday, 14 April 2021 15:00:38 CDT Bob Harold wrote: Does anyone have an automated KSK roll process, that checks for the DS record at the parent, that they can share? As far as I can tell, the automated signing in BIND will roll th

Re: Ask for automated KSK roll with DS checking

On 15-04-2021 16:35, Bob Harold wrote: On Thu, Apr 15, 2021 at 8:50 AM Bob Harold <mailto:rharo...@umich.edu>> wrote: On Thu, Apr 15, 2021 at 2:57 AM Matthijs Mekking mailto:matth...@isc.org>> wrote: On 14-04-2021 22:30, Greg Rivers via bind-users wrote

Re: Ask for automated KSK roll with DS checking

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

Re: 'managed-keys' is deprecated ??

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 Popovitc

Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

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 a

Re: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

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

Re: dnssec-guide erratum

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

Re: DNSSEC questions

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

Deprecating auto-dnssec and inline-signing in 9.18+

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

Re: Deprecating auto-dnssec and inline-signing in 9.18+

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 be

Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+

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

Re: AW: AW: Deprecating auto-dnssec and inline-signing in 9.18+

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 arti

Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+

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 migr

Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+

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

Re: AW: Deprecating auto-dnssec and inline-signing in 9.18+

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 bo

Re: Can't get Bind to publish CDS/CDNSKEY using dnssec-policy

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

Re: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes

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

Re: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes

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

Re: bind extended dns error

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,

Re: Question about "max-zone-ttl" in dnssec-policy

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 t

Fwd: Question about "max-zone-ttl" in dnssec-policy

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 are

Re: DNSSEC questions

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 rec

Re: DNSSEC questions

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 sig

Re: dnssec-policy is not signing anymore

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 "

Re: dnssec: ds showing hidden 3+ days after key roll

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

Re: dnssec: ds showing hidden 3+ days after key roll

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

Re: dnssec: ds showing hidden 3+ days after key roll

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

Re: dnssec: ds showing hidden 3+ days after key roll

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

Re: Changing ZSK-lifetime in dnssec-policy is not applied

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

Re: Changing the DNSSEC algorithm

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

Re: Signatures expired?

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

Re: How to prevent gratuitous publication of CDS/CDNSKEY records

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

Re: dnssec-policy makes BIND touch all key files every hour

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,

Re: dnssec-policy makes BIND touch all key files every hour

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

Re: dnssec-policy makes BIND touch all key files every hour

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.

Re: Confused by parental-source documentation

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

Re: understanding keymgr handling of KSK

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

Re: why did it take 26 hours for DSState to change to omnipresent?

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)

Re: Primary zone not fully maintained by BIND

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

Re: Primary zone not fully maintained by BIND

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:

Re: Primary zone not fully maintained by BIND

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

Re: DNSSEC transition from manually signed zone to dnssec-policy "standard" failed

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

  1   2   >