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// // be valid, the CDS/CDNSKEY RRset(s) MUST be compliant with the rules// // in Section 4.1. *When the Parent DS is in sync with the CDS/CDNSKEY*/*/ /**/ RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s);/*/ // the Child can determine if this is the case by querying for DS// // records in the Parent./ _/6.1.1. CDS/CDNSKEY Polling/_/ // // This is the only defined use of CDS/CDNSKEY resource records in this// // document. There are limits to the scalability of polling techniques;// // thus, some other mechanism is likely to be specified later that// // addresses CDS/CDNSKEY resource record usage in the situation where// // polling runs into scaling issues. Having said that, polling will// // work in many important cases such as enterprises, universities, and// // smaller TLDs. In many regulatory environments, the Registry is// // prohibited from talking to the Registrant. In most of these cases,// // the Registrant has a business relationship with the Registrar, so the// // Registrar can offer this as a service.// // //*If the CDS/CDNSKEY RRset(s) do not exist, the Parental Agent MUST*/*/ /**/ take no action. Specifically, it MUST NOT delete or alter the/**/ /**/ existing DS RRset./* I'm confused. There is no text describing how a Key Rollover might work. The Child can delete the CDS once it believed the Parent has activated the appropriate DS. There is no discussion on how a Parent will know to remove that DS record... unless it is via asking the Child for all existing DNSKEY records of type 257 and then recalculating the DS records and working out what is missing. Then we don't need CDS records at all - just Poll for DNSKEY records? Note that the child can delete the CDS **RRset** once it believes the parent is in sync (not just a single CDS record). The parent should remove the existing DS record if it encounters a CDS/CDNSKEY RRset that does not have a corresponding record for the given DS record. The only corner case is that there is no way to signal that all DS records must be removed from the parent (i.e. going insecure) in RFC 7344. That is defined in RFC 8078. Hope this helps taking away your confusion. I think I really prefer the simplicity of mirroring the CDS's of a Child > into the DS's on the Parent. Makes handling of Null CDS records easier. Me too :) Best regards, Matthijs -- 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-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 rules// // in Section 4.1. *When the Parent DS is in sync with the CDS/CDNSKEY*/*/ /**/ RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s);/*/ // the Child can determine if this is the case by querying for DS// // records in the Parent./ _/6.1.1. CDS/CDNSKEY Polling/_/ // // This is the only defined use of CDS/CDNSKEY resource records in this// // document. There are limits to the scalability of polling techniques;// // thus, some other mechanism is likely to be specified later that// // addresses CDS/CDNSKEY resource record usage in the situation where// // polling runs into scaling issues. Having said that, polling will// // work in many important cases such as enterprises, universities, and// // smaller TLDs. In many regulatory environments, the Registry is// // prohibited from talking to the Registrant. In most of these cases,// // the Registrant has a business relationship with the Registrar, so the// // Registrar can offer this as a service.// // //*If the CDS/CDNSKEY RRset(s) do not exist, the Parental Agent MUST*/*/ /**/ take no action. Specifically, it MUST NOT delete or alter the/**/ /**/ existing DS RRset./* I'm confused. There is no text describing how a Key Rollover might work. The Child can delete the CDS once it believed the Parent has activated the appropriate DS. There is no discussion on how a Parent will know to remove that DS record... unless it is via asking the Child for all existing DNSKEY records of type 257 and then recalculating the DS records and working out what is missing. Then we don't need CDS records at all - just Poll for DNSKEY records? I think I really prefer the simplicity of mirroring the CDS's of a Child into the DS's on the Parent. Makes handling of Null CDS records easier. On 2022/11/24 09:50, Matthijs Mekking wrote: Hi, I think this should work with some caveats. This is true for BIND 9, as it will publish the CDS for as long as the DS should be in the parent. But it doesn't have to be the case. The RFC (7344) says: When the Parent DS is in sync with the CDS/CDNSKEY RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s); the Child can determine if this is the case by querying for DS records in the Parent. -- Mark James ELKINS - Posix Systems - (South) Africa m...@posix.co.za Tel: +27.826010496 -- 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-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
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
> corresponding DS record from the parent.
This is true for BIND 9, as it will publish the CDS for as long as the
DS should be in the parent. But it doesn't have to be the case. The
RFC (7344) says:
When the Parent DS is in sync with the CDS/CDNSKEY
RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s);
the Child can determine if this is the case by querying for DS
records in the Parent.
Personally I like to keep the CDS in the child zone, so you can see if
the parent is in sync, that is why I implemented it in BIND 9 to keep
the CDS.
Best regards,
Matthijs
On 23-11-2022 18:24, Mark Elkins via bind-users wrote:
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-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime 370d algorithm ecdsa256; // < this part
in particular!
zsk lifetime 34d algorithm ecdsa256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
I also have some external code that goes trawling for CDS records and
puts into a parent whatever it finds in the child - that in this case
is signed with the above policy stanza.
If the child creates a new CDS - my external scripts will find it and
pop it into the parent as a DS record.
If the child looses a CDS record - my external script will remove the
corresponding DS record from the parent.
Basically - whatever is in the child as a CDS will be in the parent
as a DS.
A null CDS removes all DS records - but that's not my question.
Is there anything else I need to do? Any additional rndc's ??
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@posix.co.za Tel: +27.826010496
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@posix.co.za Tel: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
Posix SystemsVCARD for MJ Elkins
--
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-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
> corresponding DS record from the parent.
This is true for BIND 9, as it will publish the CDS for as long as the
DS should be in the parent. But it doesn't have to be the case. The RFC
(7344) says:
When the Parent DS is in sync with the CDS/CDNSKEY
RRset(s), the Child DNS Operator MAY delete the CDS/CDNSKEY RRset(s);
the Child can determine if this is the case by querying for DS
records in the Parent.
Personally I like to keep the CDS in the child zone, so you can see if
the parent is in sync, that is why I implemented it in BIND 9 to keep
the CDS.
Best regards,
Matthijs
On 23-11-2022 18:24, Mark Elkins via bind-users wrote:
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-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime 370d algorithm ecdsa256; // < this part in
particular!
zsk lifetime 34d algorithm ecdsa256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
I also have some external code that goes trawling for CDS records and
puts into a parent whatever it finds in the child - that in this case is
signed with the above policy stanza.
If the child creates a new CDS - my external scripts will find it and
pop it into the parent as a DS record.
If the child looses a CDS record - my external script will remove the
corresponding DS record from the parent.
Basically - whatever is in the child as a CDS will be in the parent as a DS.
A null CDS removes all DS records - but that's not my question.
Is there anything else I need to do? Any additional rndc's ??
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@posix.co.za Tel: +27.826010496
--
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-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-safety 1h;
retire-safety 1h;
purge-keys 10d;
keys {
ksk lifetime 370d algorithm ecdsa256; // < this part in
particular!
zsk lifetime 34d algorithm ecdsa256;
};
zone-propagation-delay 300s;
max-zone-ttl 86400s;
parent-propagation-delay 1h;
parent-ds-ttl 3600;
};
I also have some external code that goes trawling for CDS records and
puts into a parent whatever it finds in the child - that in this case is
signed with the above policy stanza.
If the child creates a new CDS - my external scripts will find it and
pop it into the parent as a DS record.
If the child looses a CDS record - my external script will remove the
corresponding DS record from the parent.
Basically - whatever is in the child as a CDS will be in the parent as a DS.
A null CDS removes all DS records - but that's not my question.
Is there anything else I need to do? Any additional rndc's ??
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@posix.co.za Tel: +27.826010496
--
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
