Re: [KASP] setup KASP in master / slave architecture
Hi Matthijs,
thank you, so just to confirm something like this should work :
Master :
dnssec-policy "test" {
keys {
ksk lifetime P3D algorithm rsasha256 2048;
zsk lifetime P2D algorithm rsasha256 1024;
};
};
zone "**" {
type master;
file "/***/*.db";
notify yes;
key-directory "/**/**/";
inline-signing yes;
dnssec-policy test;
};
And my Slaves :
zone "**" {
type slave;
masters { ** ; };
file "/ **/ ** / ** .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 a écrit :
> 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
> > community user support.
> >
> >
> > I would like to set up DNSSEC using KASP.
> >
> > I have an architecture with a master and several slaves.
> >
> > Here is my policy and zone configuration:
> >
> > dnssec-policy "test" {
> >
> > keys {
> >
> > ksk lifetime P3D algorithm rsasha256 2048;
> >
> > zsk lifetime P2D algorithm rsasha256 1024;
> >
> > };
> >
> > };
> >
> > zone "**" {
> >
> > type master;
> >
> > file "/***/*.db";
> >
> > notify yes;
> >
> > key-directory "/**/**/";
> >
> > inline-signing yes;
> >
> > dnssec-policy test;
> >
> > };
> >
> >
> > after restart, it seems ok, keys are generated on master, no errors in
> > logs etc.
> >
> > I copied this policy, the keys and the zone configuration on each of my
> > slaves then I restarted my slaves everything seems ok (in the logs).
> >
> > except that now I wonder if the keys on each of my slaves will be
> > generated independently from those of my master.
> >
> >
> > In this case, I will end up with different keys for the same zone
> > depending on the slave1 / slave2 etc / master. I suppose that it is not
> > good because we should have for the same zone, a pair of keys and this
> > one should be copied on each slaves?
> >
> > There some tuto / documentation about how to setup KASP in master /
> > slaves topology ?
> >
> >
> > Sorry if it's not enough clear...
> >
> >
> > Thank you
> >
> > *Adrien SIPASSEUTH*
> >
> >
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: [KASP] setup KASP in master / slave architecture
Hi,
It seems to work! Thank you!
To summarize:
On the master side I have the following configuration:
dnssec-policy "test" {
keys {
ksk lifetime P3D algorithm rsasha256 2048;
zsk lifetime P2D algorithm rsasha256 1024;
};
};
zone "**" {
type master;
file "/***/*.db";
notify yes;
key-directory "/**/**/";
inline-signing yes;
dnssec-policy test;
};
on the slaves side I have the following configuration:
zone "**" {
type slave;
masters { ** ; };
file "/ **/ ** / ** .db";
};
the keys are generated on the master but not on the slaves.
so I don't understand how the slaves can read their zone file which ends in
".signed" because they don't have the keys ? (but it's work with dig, i see
DS with the right ZSK)
Regards
Adrien
Le ven. 9 déc. 2022 à 10:02, Matthijs Mekking a écrit :
> Hi,
>
> No.
>
> You don't need DNSSEC maintenance on your secondary zones if you already
> have set it on your primary zones. So
>
> zone "***" {
>type secondary;
>primaries { ***; };
> file "***.db";
> };
>
> is enough.
>
> Best regards,
>
> Matthijs.
>
> On 12/9/22 09:58, adrien sipasseuth wrote:
> > Hi Matthijs,
> >
> > thank you, so just to confirm something like this should work :
> > Master :
> > dnssec-policy "test" {
> > keys {
> > ksk lifetime P3D algorithm rsasha256 2048;
> > zsk lifetime P2D algorithm rsasha256 1024;
> > };
> > };
> >
> > zone "**" {
> > type master;
> > file "/***/*.db";
> > notify yes;
> > key-directory "/**/**/";
> > inline-signing yes;
> > dnssec-policy test;
> > };
> >
> > And my Slaves :
> > zone "**" {
> > type slave;
> > masters { ** ; };
> > file "/ **/ ** / ** .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:matth...@isc.org>> a écrit :
> >
> > 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
> > > community user support.
> > >
> > >
> > > I would like to set up DNSSEC using KASP.
> > >
> > > I have an architecture with a master and several slaves.
> > >
> > > Here is my policy and zone configuration:
> > >
> > > dnssec-policy "test" {
> > >
> > > keys {
> > >
> > > ksk lifetime P3D algorithm rsasha256 2048;
> > >
> > > zsk lifetime P2D algorithm rsasha256 1024;
> > >
> > > };
> > >
> > > };
> > >
> > > zone "**" {
> > >
> > > type master;
> > >
> > > file "/***/*.db";
> > >
> > > notify yes;
> > >
> > > key-directory "/**/**/";
> > >
> > > inline-signing yes;
> > >
> > > dnssec-policy test;
> > >
> > > };
> > >
> > >
> > > after restart, it seems ok, keys are generated on master, no
> > errors in
> > > logs etc.
> > >
> > > I copied this policy, the keys and the zone configuration on each
> > of my
> > > slaves then I restarted my slaves everything seems ok (in the
> logs).
> > >
> > > except that now I wonder if t
Re: [KASP] setup KASP in master / slave architecture
Hi,
I deleted my zone file .db on my slaves and I forced a transfer from
the master.
Now it seems to work, I do have the RRSIG associated with my RRset A when I
do a dig from my slave.
When I test my dig from my internal network I actually don't have the ad
flag. But from the google resolver (https://dns.google/) I have the flag.
To summarize:
- on my master : declaration of my policy and I use it in my zone
configuration
- on the slaves : configuration of my zone, standard without mentioning
dnssec-policy
What I observe:
- on the master: files .db, .db.jbk,
.db.signed,.db.signed.jnl and my keys
- on the slaves: files .db
I don't understand why there is no .db.signed file on my slave
knowing that a dig from a slave does return RRSIG.
zone "**" {
type slave;
masters { ** ; };
file "/ **/ ** / ** .db";
};
Should I specify the .db or the .db.signed ? On the master
or/and ths slaves ?
Regards,
Adrien
Le jeu. 15 déc. 2022 à 19:10, Darren Ankney a
écrit :
> I have a simple “mylocal” zone setup with a primary and secondary server.
>
> my primary has this .jnl file:
>
> mylocal.jnl
>
>
> My secondary has this similar .jnl file:
>
>
> mylocal.saved.jnl
>
>
> which I believe was distributed via zone transfer. You find no such
> similar files on your secondary?
>
>
> If you
>
>
> dig @ .. A +dnssec +multiline
>
>
> where is the IP of your recursive server and
> .. is something in the domain you are trying to
> verify the DNSSEC is working.
>
>
> Does your flags line look something like this?
>
>
> ;; flags: qr rd ra ad;
>
>
> Per the manual:
>
>
> The important detail in this output is the presence of the ad flag in the
> header. This signifies that BIND has retrieved all related DNSSEC
> information related to the target of the query (ftp.isc.org) and that the
> answer received has passed the validation process described in How Are
> Answers Verified?. We can have confidence in the authenticity and integrity
> of the answer, that ftp.isc.org really points to the IP address
> 149.20.1.49, and that it was not a spoofed answer from a clever attacker.
>
>
>
>
> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#using-dig-to-verify
>
> My “flags” line does not show the “ad” flag as this is just a set of
> private servers on a local lan. I can’t submit the DNSSEC details upstream
> as described here:
>
>
> https://bind9.readthedocs.io/en/v9_18_9/dnssec-guide.html#uploading-information-to-the-parent-zone
>
>
> On Dec 15, 2022, at 12:05 PM, adrien sipasseuth <
> sipasseuth.adr...@gmail.com> wrote:
>
> Hi,
>
> Ok, I got confused, no need for the keys on the slavs actually.
>
> On the other hand, my slaves should generate the .signed, .signed.jnl and
> .jbk files of my zones, no? currently it is not my case, should I copy them
> from the master?
>
> moreover, when I test a "dig A" I don't have the associated RRSIG when I
> do my "dig A" on a slave while on the master I do.
>
> Regards,
> Adrien
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: [KASP] setup KASP in master / slave architecture
Hi, Ok, I got confused, no need for the keys on the slavs actually. On the other hand, my slaves should generate the .signed, .signed.jnl and .jbk files of my zones, no? currently it is not my case, should I copy them from the master? moreover, when I test a "dig A" I don't have the associated RRSIG when I do my "dig A" on a slave while on the master I do. Regards, Adrien Le lun. 12 déc. 2022 à 12:59, Darren Ankney a écrit : > > > the keys are generated on the master but not on the slaves. > so I don't understand how the slaves can read their zone file which ends > in ".signed" because they don't have the keys ? (but it's work with dig, i > see DS with the right ZSK) > > Regards > > Adrien > > > Because the zone is signed with DNSSEC but not encrypted. DNSSEC is only > providing authentication of the source of the zone, not hiding the contents > (https://www.rfc-editor.org/rfc/rfc4033). For the primary -> secondary > zone transfer, you should setup TSIG authentication if you haven’t already > to ensure that only your secondary can perform a zone transfer ( > https://www.rfc-editor.org/rfc/rfc2931 and > https://bind9.readthedocs.io/en/v9_18_9/chapter7.html#tsig). > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[KASP] setup KASP in master / slave architecture
Hello,
Lokking for some guidance, sorry if i use the wrong way to contact community
user support.
I would like to set up DNSSEC using KASP.
I have an architecture with a master and several slaves.
Here is my policy and zone configuration:
dnssec-policy "test" {
keys {
ksk lifetime P3D algorithm rsasha256 2048;
zsk lifetime P2D algorithm rsasha256 1024;
};
};
zone "**" {
type master;
file "/***/*.db";
notify yes;
key-directory "/**/**/";
inline-signing yes;
dnssec-policy test;
};
after restart, it seems ok, keys are generated on master, no errors in logs
etc.
I copied this policy, the keys and the zone configuration on each of my
slaves then I restarted my slaves everything seems ok (in the logs).
except that now I wonder if the keys on each of my slaves will be generated
independently from those of my master.
In this case, I will end up with different keys for the same zone depending
on the slave1 / slave2 etc / master. I suppose that it is not good because
we should have for the same zone, a pair of keys and this one should be
copied on each slaves?
There some tuto / documentation about how to setup KASP in master / slaves
topology ?
Sorry if it's not enough clear...
Thank you
*Adrien SIPASSEUTH*
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
[KASP] Key rollover
Hello,
I put the management of DNSSEC with KASP, the zone is well functional. (dig
with "AD" flag etc)
On the other hand, I can't see when the key rollover period for my KSK is
over (2 KSKs with a dig DNSKEY...)
Without KASP, it was easy because I generated the second KSK key but with
KASP, it is managed automatically.
So, I have to adapt my scripts to check that there is :
- a used KSK key and a next KSK key
- Or only one KSK key used (if we are not in rollover phase)
Except that with my current policy, I never see 2 KSKs via a "dig
DNSKEY...".
here is my policy :
dnssec-policy "test" {
keys {
ksk lifetime P7D algorithm ecdsa256;
zsk lifetime P3D algorithm ecdsa256;
};
purge-keys 1d;
publish-safety 3d;
retire-safety 3d;
};
I see either my KSK in use or my next KSK (via "dig DNSKEY...") but never
both at the same time.
Is this a normal behavior or am I doing it wrong?
Regards, Adrien
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: [KASP] Key rollover
Hello Matthijs,
Indeed I had not published the DS at my registar because I thought that the
second KSK would have appeared anyway at the time of the rollover.
I published the DS yesterday and I reported to BIND with the command you
gave me. I didn't find any error in the logs so everything must have been
fine!
here is the state file of the KSK in use :
; This is the state of key 46358, for ***.
Algorithm: 13
Length: 256
Lifetime: 604800
Predecessor: 28887
KSK: yes
ZSK: no
Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
DNSKEYState: omnipresent
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
>From my understanding, 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 janv. 2023 à 09:13, Matthijs Mekking a écrit :
> 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.
>
> Best regards,
>
> Matthijs
>
> On 1/17/23 09:38, adrien sipasseuth wrote:
> > Hello,
> >
> > I put the management of DNSSEC with KASP, the zone is well functional.
> > (dig with "AD" flag etc)
> >
> > On the other hand, I can't see when the key rollover period for my KSK
> > is over (2 KSKs with a dig DNSKEY...)
> >
> > Without KASP, it was easy because I generated the second KSK key but
> > with KASP, it is managed automatically.
> >
> > So, I have to adapt my scripts to check that there is :
> > - a used KSK key and a next KSK key
> > - Or only one KSK key used (if we are not in rollover phase)
> >
> > Except that with my current policy, I never see 2 KSKs via a "dig
> > DNSKEY...".
> > here is my policy :
> >
> > dnssec-policy "test" {
> > keys {
> > ksk lifetime P7D algorithm ecdsa256;
> > zsk lifetime P3D algorithm ecdsa256;
> > };
> > purge-keys 1d;
> > publish-safety 3d;
> > retire-safety 3d;
> > };
> >
> > I see either my KSK in use or my next KSK (via "dig DNSKEY...") but
> > never both at the same time.
> >
> > Is this a normal behavior or am I doing it wrong?
> >
> > Regards, Adrien
> >
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: [KASP] Key rollover
Hello,
I don't why DSState: hidden, it's ok with some online check tools like :
- https://dnssec-analyzer.verisignlabs.com/
- https://zonemaster.net/fr/run-test
my master is hidden, it can be related ? How i can debug this DSState:
hidden ?
I found this command to check actual status : rndc dnssec -status **
This is the output :
key: 46358 (ECDSAP256SHA256), KSK
published: yes - since Tue Jan 17 17:55:03 2023
key signing:yes - since Tue Jan 17 17:55:03 2023
Next rollover scheduled on Tue Jan 24 17:55:03 2023
- goal: omnipresent
- dnskey: omnipresent
- ds: hidden
- key rrsig: omnipresent
...
Regards Adrien
Le mar. 24 janv. 2023 à 09:27, Matthijs Mekking a écrit :
> Hi Adrien,
>
> I don't think it is fine yet. I see in your state file the following line:
>
> > DSState: hidden
>
> This means the DS is not published according to BIND.
>
> > From my understanding, 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?
>
> In addition to the DNSKEY TTL yes. The successor KSK should be
> pre-published the sum of dnskey-ttl, publish-safety, and
> zone-propagation-delay, prior to its retirement.
>
> Best regards,
>
> Matthijs
>
> On 1/24/23 09:08, adrien sipasseuth wrote:
> > Hello Matthijs,
> >
> > Indeed I had not published the DS at my registar because I thought that
> > the second KSK would have appeared anyway at the time of the rollover.
> >
> > I published the DS yesterday and I reported to BIND with the command you
> > gave me. I didn't find any error in the logs so everything must have
> > been fine!
> >
> > here is the state file of the KSK in use :
> > ; This is the state of key 46358, for ***.
> > Algorithm: 13
> > Length: 256
> > Lifetime: 604800
> > Predecessor: 28887
> > KSK: yes
> > ZSK: no
> > Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
> > Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
> > Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
> > Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
> > Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
> > DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
> > PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
> > DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
> > KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
> > DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
> > DNSKEYState: omnipresent
> > KRRSIGState: omnipresent
> > DSState: hidden
> > GoalState: omnipresent
> >
> > From my understanding, 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 janv. 2023 à 09:13, Matthijs Mekking > <mailto:matth...@isc.org>> a écrit :
> >
> > 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 <http://example.com>' or set up
> > parental-agents to do it for you.
> >
> > Best regards,
> >
> > Matthijs
> >
> > On 1/17/23 09:38, adrien sipasseuth wrote:
> > > Hello,
> > >
> > > I put the management of DNSSEC with KASP, the zone is well
> > functional.
> > > (dig with "AD" flag etc)
> > >
> > > On the other hand, I can't see when the key rollover period for
> > my KSK
> > > is over (2 KSKs with a dig DNSKEY...)
> > >
> > > Without KASP, it was easy because I generated the second KSK key
> but
> > > with KASP, it is managed automatically.
> > >
> > > So, I have to adapt my scripts to check that there is :
> > > - a used KSK key and a next KSK key
> > > - Or only one KSK key used (if we are not in rollover phase)
> > >
> > > Except that with my current policy, I never see 2 KSKs via a "dig
> > > DNSKEY...".
> > > here i
Re: [KASP] Key rollover
24 17:55:03 2023)
DSChange: 20230124165503 (Tue Jan 24 17:55:03 2023)
DNSKEYState: rumoured
KRRSIGState: rumoured
DSState: hidden
GoalState: omnipresent
Regards Adrien
Le mar. 24 janv. 2023 à 15:18, adrien sipasseuth <
sipasseuth.adr...@gmail.com> a écrit :
> Hello,
>
> I don't why DSState: hidden, it's ok with some online check tools like :
> - https://dnssec-analyzer.verisignlabs.com/
> - https://zonemaster.net/fr/run-test
>
> my master is hidden, it can be related ? How i can debug this DSState:
> hidden ?
>
> I found this command to check actual status : rndc dnssec -status
> **
> This is the output :
>
> key: 46358 (ECDSAP256SHA256), KSK
> published: yes - since Tue Jan 17 17:55:03 2023
> key signing:yes - since Tue Jan 17 17:55:03 2023
>
> Next rollover scheduled on Tue Jan 24 17:55:03 2023
> - goal: omnipresent
> - dnskey: omnipresent
> - ds: hidden
> - key rrsig: omnipresent
> ...
>
> Regards Adrien
>
> Le mar. 24 janv. 2023 à 09:27, Matthijs Mekking a
> écrit :
>
>> Hi Adrien,
>>
>> I don't think it is fine yet. I see in your state file the following line:
>>
>> > DSState: hidden
>>
>> This means the DS is not published according to BIND.
>>
>> > From my understanding, 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?
>>
>> In addition to the DNSKEY TTL yes. The successor KSK should be
>> pre-published the sum of dnskey-ttl, publish-safety, and
>> zone-propagation-delay, prior to its retirement.
>>
>> Best regards,
>>
>> Matthijs
>>
>> On 1/24/23 09:08, adrien sipasseuth wrote:
>> > Hello Matthijs,
>> >
>> > Indeed I had not published the DS at my registar because I thought that
>> > the second KSK would have appeared anyway at the time of the rollover.
>> >
>> > I published the DS yesterday and I reported to BIND with the command
>> you
>> > gave me. I didn't find any error in the logs so everything must have
>> > been fine!
>> >
>> > here is the state file of the KSK in use :
>> > ; This is the state of key 46358, for ***.
>> > Algorithm: 13
>> > Length: 256
>> > Lifetime: 604800
>> > Predecessor: 28887
>> > KSK: yes
>> > ZSK: no
>> > Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
>> > Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
>> > Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
>> > Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
>> > Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
>> > DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
>> > PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
>> > DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
>> > KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
>> > DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
>> > DNSKEYState: omnipresent
>> > KRRSIGState: omnipresent
>> > DSState: hidden
>> > GoalState: omnipresent
>> >
>> > From my understanding, 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 janv. 2023 à 09:13, Matthijs Mekking > > <mailto:matth...@isc.org>> a écrit :
>> >
>> > 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 <http://example.com>' or set up
>> > parental-agents to do it for you.
>> >
>> > Best regards,
>> >
>> > Matthijs
>> >
>> > On 1/17/23 09:38, adrien sipasseuth wrote:
>> > > Hello,
>> > >
>> > > I put the management of DNSSEC with KASP, the zone is well
>> > functional.
>> > > (dig with "AD" flag etc)
Re: [KASP] Key rollover
Hello,
I waited 24 hours and then put my zone back in dnssec.
after 24 everything seems ok... at least by doing a "rndc dnssec -status
"
everything is in omnipresent:
Next rollover scheduled on Fri Feb 10 09:15:51 2023
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
so it works BUT I need to know more than 48h in advance that the rollover
is starting to submit the new KSK to my registar.
How can I set this up if it's not with "public-safety"?
Regards,
Adrien
Le mer. 25 janv. 2023 à 11:34, Matthijs Mekking a écrit :
>
>
> On 1/24/23 15:18, adrien sipasseuth wrote:
> > Hello,
> >
> > I don't why DSState: hidden, it's ok with some online check tools like :
> > - https://dnssec-analyzer.verisignlabs.com/
> > <https://dnssec-analyzer.verisignlabs.com/>
> > - https://zonemaster.net/fr/run-test <https://zonemaster.net/fr/run-test
> >
>
> DSState: hidden is what BIND thinks. Note that it does not query yet to
> determine the DSState.
>
>
> >
> > my master is hidden, it can be related ? How i can debug this DSState:
> > hidden ?
>
> It has nothing to do with hidden primaries.
>
>
> > I found this command to check actual status : rndc dnssec -status
> **
> > This is the output :
> >
> > key: 46358 (ECDSAP256SHA256), KSK
> >published: yes - since Tue Jan 17 17:55:03 2023
> >key signing:yes - since Tue Jan 17 17:55:03 2023
> >
> >Next rollover scheduled on Tue Jan 24 17:55:03 2023
> >- goal: omnipresent
> >- dnskey: omnipresent
> >- ds: hidden
> >- key rrsig: omnipresent
>
> It is hard to determine why your DS is hidden. If all other elements are
> omnipresent, the DS should be rumoured (because you may submit it to the
> parent).
>
> I have a feeling this is because your publish-safety is 3 days. It takes
> an additional 3 days before continuing with the rollover, thus also with
> "making the DS known to the world". In other words, I think BIND does
> not yet think it is safe to publish the DS, hence DS is hidden.
>
> I understand this may not reflect the real world, and perhaps it 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...@isc.org>> a écrit :
> >
> > Hi Adrien,
> >
> > I don't think it is fine yet. I see in your state file the following
> > line:
> >
> > > DSState: hidden
> >
> > This means the DS is not published according to BIND.
> >
> > > From my understanding, 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?
> >
> > In addition to the DNSKEY TTL yes. The successor KSK should be
> > pre-published the sum of dnskey-ttl, publish-safety, and
> > zone-propagation-delay, prior to its retirement.
> >
> > Best regards,
> >
> > Matthijs
> >
> > On 1/24/23 09:08, adrien sipasseuth wrote:
> > > Hello Matthijs,
> > >
> > > Indeed I had not published the DS at my registar because I
> > thought that
> > > the second KSK would have appeared anyway at the time of the
> > rollover.
> > >
> > > I published the DS yesterday and I reported to BIND with the
> > command you
> > > gave me. I didn't find any error in the logs so everything must
> have
> > > been fine!
> > >
> > > here is the state file of the KSK in use :
> > > ; This is the state of key 46358, for ***.
> > > Algorithm: 13
> > > Length: 256
> > > Lifetime: 604800
> > > Predecessor: 28887
> > > KSK: yes
> > > ZSK: no
> > > Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
> > > Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
> > > Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
> > > Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
> > > Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
&g
Re: [KASP] Key rollover
Hi, "You configure parental agents and named will check which DS’s are published. Named won’t complete the roll until it knows the new DS is published." => what is parental agent ? i don't find this term in Bind documentation. >From what I understand, you have to specify to Bind that the new DS is published with the command: rndc dnssec -checkds -key published "If it was me, I'd set the KSK to not roll-over automatically, and instead create a recurring reminder for yourself to initiate the KSK roll-over manually? That way you'd never get caught out with a KSK roll-over happening when you weren't prepared for it? " => I don't know if I can get a policy for ZSK and a manual method for KSK. >From what I understand if I want to use a policy I have to remove "auto-dnssec maintain;" which is necessary for the manual method right? In the meantime, I wonder if I can't stay on the manual method even with a bind 9.18? I read that the auto-dnssec directive might disappear in favor of dnssec-policy. Does that mean that it might not be possible to do it manually anymore? source here => https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy Regards, Adrien Le jeu. 9 févr. 2023 à 10:35, Mark Andrews a écrit : > You configure parental agents and named will check which DS’s are > published. Named won’t complete the > roll until it knows the new DS is published. > > > On 9 Feb 2023, at 19:49, Nick Tait via bind-users < > bind-users@lists.isc.org> wrote: > > > > On 9/02/23 05:17, adrien sipasseuth wrote: > >> so it works BUT I need to know more than 48h in advance that the > rollover is starting to submit the new KSK to my registar. > >> > >> How can I set this up if it's not with "public-safety"? > > If it was me, I'd set the KSK to not roll-over automatically, and > instead create a recurring reminder for yourself to initiate the KSK > roll-over manually? That way you'd never get caught out with a KSK > roll-over happening when you weren't prepared for it? > > -- > > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[DNSSEC] testing KASP
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 ecdsa256 2048;
zsk lifetime P1D algorithm ecdsa256 2048;
};
// Key timings
purge-keys P4D;
// Signature timings
signatures-refresh PT50M;
signatures-validity PT1H;
signatures-validity-dnskey PT1H;
// Zone parameters
max-zone-ttl PT1H;
parent-ds-ttl PT1H;
};
I would like automaticly update new DS to my registar, to do it this my
logic :
For each file en .state
If is KSK with "DSState: rumoured" or "DSState: hidden"
If not in my registar (dig ds +dnssec +multiline)
Publish on my Registar(api register)
Notify Bind(bind rndc dnssec -checkds -key published
)
Do y need to withdraw the old key too immediatly ? anything else to do ?
# question 2 #
If i want to unsigned a zone, i change my policy to "insecure" which is
default but file like .signed still exist, Bind doesn't remove it ?
# question 3 #
In state file, when the remove date issue, can i just remove the key,
anything else to do ?
Regards,
Adrien SIPASSEUTH
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: [DNSSEC] testing KASP
Only if KSK has DSState: rumoured. If the DSState is hidden it means
that it is not expected to be in the parent (for example because the
DNSKEY has not yet been fully propagated).
> Do you need to withdraw the old key too immediatly ? anything else to do ?
>>> Do you mean withdraw the old DS?
Yes, the old DS should be not yet withdraw because some RRSIG could be
still valid ? or can i withdraw the old DS / KSK immediatly ?
In my logic :
For each file en .state
If is KSK with "DSState: rumoured" or "DSState: hidden"
If not in my registar (dig ds +dnssec +multiline)
Publish on my Registar(api register)
Notify Bind(bind rndc dnssec -checkds -key
published )
Notify Bind(bind rndc dnssec -checkds -key
withdraw )
In my understanding, i shouldn't do "Notify Bind(bind rndc dnssec -checkds
-key withdraw )" and wait until all RRSIG sign (with
the old KSK) expire. In that case, how can i check this ? (some dig command
? or check state file for "DSState: unretentive" ?)
regards,
Adrien
Le ven. 17 mai 2024 à 15:13, Matthijs Mekking a écrit :
> 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 ecdsa256 2048;
> > zsk lifetime P1D algorithm ecdsa256 2048;
> > };
> >
> > // Key timings
> > purge-keys P4D;
> >
> > // Signature timings
> > signatures-refresh PT50M;
> > signatures-validity PT1H;
> > signatures-validity-dnskey PT1H;
> >
> > // Zone parameters
> > max-zone-ttl PT1H;
> > parent-ds-ttl PT1H;
> >
> > };
> >
> > I would like automaticly update new DS to my registar, to do it this my
> > logic :
> >
> > For each file en .state
> > If is KSK with "DSState: rumoured" or "DSState: hidden"
> > If not in my registar (dig ds +dnssec +multiline)
> > Publish on my Registar(api register)
> > Notify Bind(bind rndc dnssec -checkds -key published
> > )
>
> Only if KSK has DSState: rumoured. If the DSState is hidden it means
> that it is not expected to be in the parent (for example because the
> DNSKEY has not yet been fully propagated).
>
>
> > Do y need to withdraw the old key too immediatly ? anything else to do ?
>
> Do you mean withdraw the old DS?
>
> I would use similar logic but then use "unretentive" instead of
> "rumoured". Following the example above:
>
> For each file en .state
>If is KSK with "DSState: unretentive"
>If in my registar (dig ds +dnssec +multiline)
>Withdraw on my Registar(api register)
>Notify Bind(bind rndc dnssec -checkds -key withdrawn
>
>
> > # question 2 #
> > If i want to unsigned a zone, i change my policy to "insecure" which is
> > default but file like .signed still exist, Bind doesn't remove
> it ?
>
> Correct. If all DNSSEC records have been removed, it is safe to remove
> the "dnssec-policy" configuration from your named.conf and then remove
> the .signed file.
>
> Unsigning your zone also takes time.
>
>
> > # question 3 #
> >
> > In state file, when the remove date issue, can i just remove the key,
> > anything else to do ?
>
> When all states are "hidden" it is safe to remove the key.
>
> Best regards,
>
> Matthijs
>
>
> > Regards,
> > Adrien SIPASSEUTH
> >
> >
> >
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
