Re: dnssec-policy - KSK rollover

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

Re: dnssec-policy - KSK rollover

OK - so I read RFC7344... Automating DNSSEC Delegation Trust Maintenance There are two interesting paragraphs. _/5.  CDS/CDNSKEY Publication/_/ // //   The Child DNS Operator publishes CDS/CDNSKEY RRset(s).  In order to// //   be valid, the CDS/CDNSKEY RRset(s) MUST be compliant with the rul

Re: dnssec-policy - KSK rollover

:-) Will let you know in a year! ps - please, please keep the CDS's in the child zone - reflecting the current KSK's!  (etc) On 2022/11/24 09:50, Matthijs Mekking wrote: Hi, I think this should work with some caveats. First, If you migrate to dnssec-policy (that is the zone is already

Re: dnssec-policy - KSK rollover

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

dnssec-policy - KSK rollover

Hi people, I have read https://kb.isc.org/docs/dnssec-key-and-signing-policy I have put the following policy in my named.conf file:- dnssec-policy "ecdsa256-policy" {     signatures-refresh 5d;     signatures-validity 14d;     signatures-validity-dnskey 14d;     dnskey-ttl 3600;     publish-saf

Re: Root zone DNSSEC KSK rollover event - 2018/10/11, 16:00 UTC

On 28/09/2018 10:55, Anand Buddhdev wrote: > On 11 October, the old key won't be removed. On that day, the new key > will start signing the DNSKEY RRset. The old key (id 19036), will remain > in the root zone; it just won't sign the DNSKEY RRset. Eventually, in > the first quarter of 2019, it will

Re: Root zone DNSSEC KSK rollover event - 2018/10/11, 16:00 UTC

On 28/09/2018 11:37, Ray Bellis wrote: Hi Ray, > At this time the old key will be removed from the root zone leaving only > the new key (id 20326) in the zone. If your DNS servers don't know and > trust the new key at that point then DNSSEC validation errors will occur. On 11 October, the old k

Root zone DNSSEC KSK rollover event - 2018/10/11, 16:00 UTC

This is a reminder for users of BIND that the most critical phase of the rollover of the root zone's DNSSEC KSK is scheduled to happen at 16:00 UTC on Thursday 11th October. At this time the old key will be removed from the root zone leaving only the new key (id 20326) in the zone. If your DNS se

Re: [BIND] RE: KSK Rollover

On Fri, Sep 07, 2018 at 06:15:59PM +0200, Mark Elkins wrote: > I kinda also wonder why the command simply doesn't output to stdout by > default. The *only* reason I've ever run the command "rndc secroots" is > to look at the output, that is, checking for the correct DNSKEY > root-anchors - which I

Re: [BIND] RE: KSK Rollover

I'm aware of: rndc managed-keys status I'm also aware of:  rndc secroots - (a Hypen at the end of "rndc secroots" will send output to stdout) I'm just not sure how long the 'hyphen' argument has been around for but vaguely remember a similar discussion from long ago. It looks like someone else al

Re: [BIND] RE: KSK Rollover

Mark Elkins wrote: > I kinda also wonder why the command simply doesn't output to stdout by > default. Historical reasons :-) BIND 9.11 and later have `rndc managed-keys` which is rather more user-friendly. I get the impression that the root rollover guides are using `rndc secroots` because that

Re: [BIND] RE: KSK Rollover

t=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0 >>> >>> >>> I left all of the permissions the same and I think they should be lenient >>> enough: >>> [root@ns3 named]# ls -lh named.secroots >>> -rw-rw-rw-. 1 named named 0 Sep 6 13:

Re: [BIND] RE: KSK Rollover

>> enough: >> [root@ns3 named]# ls -lh named.secroots >> -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots >> >> >> >> >> -Original Message- >> From: Hugo Salgado-Hernández [mailto:hsalg...@nic.cl] >> Sent: Thursday, September

Re: [BIND] RE: KSK Rollover

supported releases. > > > Ultimately when I ran "rndc secroots" it created the output file here: > > /tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots > > > The data in the file seems to be as desired if I understand t

Re: [BIND] RE: KSK Rollover

0 > > > I left all of the permissions the same and I think they should be lenient > enough: > [root@ns3 named]# ls -lh named.secroots > -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots > > > > > -Original Message- > From: Hugo Salgado-Hernández [ma

RE: [BIND] RE: KSK Rollover

#x27;permissive=0' so it suggests a SELinux-enforcing environment. Stuart From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Brent Swingle Sent: Friday, 7 September 2018 12:05 PM To: bind-users@lists.isc.org Subject: Re: [BIND] RE: KSK Rollover This matter has been res

Re: [BIND] RE: KSK Rollover

quot; it created the output file here: /tmp/systemd-private-b2ebff459df9471e8bf444e2d2b1116e-named.service-HX1NF5/tmp/named.secroots The data in the file seems to be as desired if I understand the KSK Rollover test correctly, I should see 20326 which pertains to the new key: [root@ns3 tmp]# cat n

RE: [BIND] RE: KSK Rollover

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, 2018-09-06 at 20:58 +, Brent Swingle wrote: > I left all of the permissions the same and I think they should be > lenient enough: > [root@ns3 named]# ls -lh named.secroots > -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots Does th

RE: [BIND] RE: KSK Rollover

croots -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots -Original Message- From: Hugo Salgado-Hernández [mailto:hsalg...@nic.cl] Sent: Thursday, September 06, 2018 3:39 PM To: Brent Swingle Cc: Evan Hunt ; bind-users@lists.isc.org Subject: Re: [BIND] RE: KSK Rollover Hi Brent. In

Re: [BIND] RE: KSK Rollover

riginal Message- > From: Evan Hunt [mailto:e...@isc.org] > Sent: Thursday, September 06, 2018 1:22 PM > To: Brent Swingle > Cc: bind-users@lists.isc.org > Subject: Re: KSK Rollover > > On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote: > > This is the comm

RE: KSK Rollover

- From: Evan Hunt [mailto:e...@isc.org] Sent: Thursday, September 06, 2018 1:22 PM To: Brent Swingle Cc: bind-users@lists.isc.org Subject: Re: KSK Rollover On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote: > This is the command that does not work and the output received: > [r

Re: KSK Rollover

On Thu, Sep 06, 2018 at 05:34:21PM +, Brent Swingle wrote: > This is the command that does not work and the output received: > [root@ns2 ~]# rndc secroots > rndc: 'secroots' failed: permission denied > [root@ns2 ~]# Have you set up your server to accept rndc commands? If not, run "rndc-confge

Re: KSK Rollover

ursday, September 6, 2018 12:36 PM To: bind-users@lists.isc.org Subject: KSK Rollover I recently received an email indicating that our DNS servers are not properly equipped for the planned KSK Rollover that is coming. It leads off with this line "On 11 October 2018, ICANN will change or

KSK Rollover

I recently received an email indicating that our DNS servers are not properly equipped for the planned KSK Rollover that is coming. It leads off with this line "On 11 October 2018, ICANN will change or "roll over" the DNSSEC key signing key (KSK) of the DNS root zone."

Re: dnssec KSK rollover

Actually I have one more question just to make sure I'm not overlooking anything for the KSK rollover. The instructions here: https://www.icann.org/dns-resolvers-checking-current-trust-anchors say that I need to, in addition to setting validation to "auto" run: rndc secroots. W

Re: dnssec KSK rollover

Thanks Tony! This was very helpful. On Thu, Aug 23, 2018 at 8:01 AM Tony Finch wrote: > project722 wrote: > > > > 1) I am still seeing the "no valid signature found" messages in my > > bind.log. > > > ;; validating ncentral.teklinks.com/A: no valid signature found > > In this case that's becaus

Re: dnssec KSK rollover

project722 wrote: > > 1) I am still seeing the "no valid signature found" messages in my > bind.log. > ;; validating ncentral.teklinks.com/A: no valid signature found In this case that's because ncentral.teklinks.com is signed but there's no DS in the parent zone, so it's insecure. If you run de

Re: dnssec KSK rollover

Hi Tony, I've removed the config for managed keys out of my named.conf, moved any files called bind.keys out from my named working directory, and restarted Bind. I see where Bind created to files - managed-keys.bind and managed-keys.bind.jnl. So, I think I'm on the right track. That said, two thin

Re: dnssec KSK rollover

project722 wrote: > > In my named.conf I changed: > > dnssec-validation yes; > > to > > dnssec-validation auto; Good :-) Next thing to do is delete all trace of managed-keys or mkeys files or trusted-keys configuration, then restart `named`. It will automatically create managed-keys files with t

dnssec KSK rollover

from your network received at the DNS root name servers [1], we believe that there may be at least one recursive resolver (also referred to as a recursive name server or caching name server) with DNSSEC validation enabled in AS11272 that is unprepared for the KSK rollover. If that resolver is not upda

Re: getting two rrsigs for dnskey after ksk rollover

> On 20 Sep 2017, at 15:32, rams wrote: > > We are getting two RRSIGs and 3 DNSKEY [ 1-256 and 2-257] when we do KSK > rollover. Is it correct we are returning two RRSIGs for DNSKEY? Yes :-) There are multiple ways to do a KSK rollover: you are doing a double-KSK rollov

getting two rrsigs for dnskey after ksk rollover

Greetings!!! We are getting two RRSIGs and 3 DNSKEY [ 1-256 and 2-257] when we do KSK rollover. Is it correct we are returning two RRSIGs for DNSKEY? Regards, Ramesh ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe

Re: botched KSK rollover

On 21/08/2017 14:23, Matthew Pounsett wrote: On 21 August 2017 at 07:18, Phil Mayers > wrote: Gandi are another excellent registrar that I can recommend. They have a comprehensive API for all their features, including uploading DNSSEC public keys a

Re: botched KSK rollover

On 21 August 2017 at 07:18, Phil Mayers wrote: > > Gandi are another excellent registrar that I can recommend. They have a > comprehensive API for all their features, including uploading DNSSEC public > keys and consequent creation of the DS record. > > I'm hoping CDS eventually makes this all ob

Re: botched KSK rollover

On 18/08/17 16:25, Carl Byington wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Sigh, it sure would be nice if I had a registrar with a means to automate DS submission. You might want to look at gkg.net Gandi are another excellent registrar that I can recommend. They have a compre

Re: [ot] botched KSK rollover

You might want to look at gkg.net fyi @ Gandi rich DNS(SEC) API with XML-RPC call support & docs for python, php, nodejs, perl, ruby & c http://doc.rpc.gandi.net/domain/reference.html ___ Please visit https://lists.isc.org/mailman/listinfo/bin

[ot] Re: botched KSK rollover

On Fri, Aug 18, 2017 at 08:25:00AM -0700, Carl Byington wrote: > > Sigh, it sure would be nice if I had a registrar with a means > > to automate DS submission. > > You might want to look at gkg.net I've been planning to do that for a long time, I guess this is a reason to move on that. I was in

Re: botched KSK rollover

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > Sigh, it sure would be nice if I had a registrar with a means to > automate DS submission. You might want to look at gkg.net -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlmXBrwACgkQL6j7milTFsFd5QCfZMqbWV/Jd8vmr

Re: botched KSK rollover

> I added a week to inactivation, > > # dnssec-settime -I+1w Knodns4.us.+005+60073.key > > I thought I should then try deactivating the new one, I am not sure whether this is really what you wanted to achieve, but in any case "dnssec-settime -i ... -S ..." only sets publication and activation da

botched KSK rollover

Oops. I had it all figured out about 2 months ago and had generated new keys for ZSK (which I rolled over right away) and KSK. The KSK change was slated for yesterday, but I forgot to get the DS to the parent zone before the inactivation of the previous KSK. Sigh, it sure would be nice if I h

Re: KSK rollover, set revoke bit unconditionally ? (cfr RFC5011)

On Fri, 5 Nov 2010, Marc Lampo wrote: > > in RFC5011, section 6.6, "Trust Point Deletion" (== KSK rollover), Trust point deletion isn't the same as a normal KSK rollover. It's a special procedure to make validators remove a trust anchor while maintaining the security

KSK rollover, set revoke bit unconditionally ? (cfr RFC5011)

Hello, in RFC5011, section 6.6, "Trust Point Deletion" (== KSK rollover), there is an unconditional statement to set the REVOKE bit on the "old" KSK, once the parent zone publishes the DS record of the new KSK. I / we at EURId / are interested to learn if this uncondit

Re: Automating a KSK rollover

On Sat, Jul 04, 2009 at 10:36:40PM -0700, Shane W wrote a message of 18 lines which said: > Is there some sort of standardized way as yet to communicate key > changes to an upstream zone or in this case a lookaside provider? There is a standard registrar2registry interface, an extension of EP

Re: Automating a KSK rollover

. One day - I'd expect this to be built into Registry/Registrar EPP type interfaces - fine except I like to host my own DNS. On Sat, 2009-07-04 at 22:36 -0700, Shane W wrote: > Hello all, > > So I just did a KSK rollover, just to get a feel for how > it's done, updating dlv.is

Re: DLV validation fails after ksk rollover

On Tue, Jun 23, 2009 at 10:10 PM, Mark Andrews wrote: > Yes the updates are slow because we had some disasters with the > automation but we intend to turn that on again soon.  That being > said you really do need to check that the new data has been published > before you start the wait periods.  Th

Re: DLV validation fails after ksk rollover

In message , R Dicair e writes: > On Tue, Jun 23, 2009 at 8:10 PM, Mark Andrews wrote: > > > >Even if the update were published on the master instananeo= > usly > >you still need to wait for the zone to transfer to all the > >slaves and for the old DLV records to timeout of

Re: DLV validation fails after ksk rollover

adding keys in or you need to wait for old DNSKEY RRset to >        timeout before you change your DNSKEY RRset.  You tried to >        change both at once and that will never work. I recognize I shouldn't have removed the old keys from DLV as soon as I'd put the new ones up, I di

Re: DLV validation fails after ksk rollover

In message , Chris Tho mpson writes: > On Jun 23 2009, R Dicaire wrote: > > >Hi folks...Yesterday I performed a DNSSEC KSK rollover, updated DLV > >with the new keys, and confirmed successful updates to DLV via their > >script. According to DLV all zones are good. Upon co

Re: DLV validation fails after ksk rollover

On Jun 23 2009, R Dicaire wrote: Hi folks...Yesterday I performed a DNSSEC KSK rollover, updated DLV with the new keys, and confirmed successful updates to DLV via their script. According to DLV all zones are good. Upon completing this, I then removed the old keys from the DLV db for each zone

DLV validation fails after ksk rollover

Hi folks...Yesterday I performed a DNSSEC KSK rollover, updated DLV with the new keys, and confirmed successful updates to DLV via their script. According to DLV all zones are good. Upon completing this, I then removed the old keys from the DLV db for each zone I have registered. Now when I