DNSSEC DS sleutelwissel dmv CDS/CDNSKEY in NL TLD mogelijk?

[alm]

Weet iemand of RFC 8078 of RFC 7344 ondersteund is in de NL TLD en zo ja, wat dan de vereisten zijn en hoe snel een sleutelwijziging zou moeten worden opgepakt?

Het betreft het geautomatiseerd updaten van de DNSSEC DS sleutel in de TLD.

Ik heb PowerDNS Authoritative Server 4.6.0 draaien met MariaDB backend in Native modus (2 servers die via MariaDB repliceren met elkaar). Ik heb een .nl domein geregistreerd via OVH (omdat zij de mogelijkheid bieden om een DS sleutel in de TLD te laden). DNSSEC werkt volledig, maar ik wil bekijken of een sleutelwijziging ook werkt zoals beschreven in RFC 8078 of RFC 7344: https://doc.powerdns.com/...uides/kskrollcdnskey.html

Ik heb zowel CDS als CDNSKEY gepubliceerd en beiden zijn zichtbaar als ik deze opvraag via mijn eigen (publieke) servers. Deze publicatie heb ik een week geleden actief gezet, maar tot op heden blijf ik alleen de bestaande DS zien en niet de nieuwe.

Uiteraard kan ik ook handmatig een nieuwe sleutel inladen via OVH, maar ik ben gewoon benieuwd of de methode uit RFC 8078 / RFC 7344 ook (al) werkt in NL.

Ik heb op de SIDN site zitten zoeken, veel gegoogled en diverse onderzoek documenten zitten lezen, maar tot op heden heb ik het antwoord nog niet gevonden.

Als iemand hier meer van weet dan verneem ik het graag.

[Frankyy]

Dit werkt nog niet als ik de volgende pagina er bij pak:
https://www.sidn.nl/en/modern-internet-standards/dnssec

RFC 8078 defines a mechanism for a registrant to automatically add new DNSSEC key material to the parent zone. However, RFC 8078 is a relatively new protocol that isn't yet widely supported or used.

Met name:

At the moment, new public KSKs usually have to be submitted to parent zone operators manually, e.g. using a DNSKEY/DS record dialogue in a web interface. However, as a registrant, you can automate the process by publishing the new public key yourself in-band, in the form of a CDNSKEY and/or CDS record (Child DNSKEY/DS). Parent zone operators or registrars periodically scan child zones (delegated zones) to check whether new keys are available.

[alm]

Heel erg duidelijk zijn ze nu ook weer niet:

How are the parent zone's DS records automatically updated?
RFC 8078 defines a mechanism for a registrant to automatically add new DNSSEC key material to the parent zone. However, RFC 8078 is a relatively new protocol that isn't yet widely supported or used.

Following initial or rollover installation of a new KSK pair, the public key has to be submitted to the parent zone's operator. An associated DS record (a hash of the public key in question) is then published in the parent zone, thus completing the DNSSEC chain of trust. That enables a validating resolver to be sure that the key pair used to sign the secure DNS records does indeed belong to the relevant zone.

At the moment, new public KSKs usually have to be submitted to parent zone operators manually, e.g. using a DNSKEY/DS record dialogue in a web interface. However, as a registrant, you can automate the process by publishing the new public key yourself in-band, in the form of a CDNSKEY and/or CDS record (Child DNSKEY/DS). Parent zone operators or registrars periodically scan child zones (delegated zones) to check whether new keys are available.

However, that method works only for delegated zones that are already DNSSEC-enabled, because trust in new key material depends on the digital signature attached to the CDNSKEY/CDS records. Therefore, the initial submission of key material (before a chain of trust has been completed) is always a manual process (although RFC 8078 does outline a couple of semi-automated alternatives).

Dus ze zeggen dat het initieel niet werkt, maar als een zone eenmaal een geldige DS heeft dat het daarna wel zou kunnen werken...

Some or all of the DS records in the parent zone can be deleted by publishing a CDNSKEY/CDS record containing zero values.

Therefore, RFC 8078 provides a mechanism for the exchange of key material between parent and child zones, similar to that provided for in RFC 5011, but operating in the opposite direction (complementary).

Ze zouden duidelijker mogen zijn of het met .nl wel of niet werkt. Omdat het niet duidelijk is lijkt het er nu op dat ze alleen het proces van RFC8078 beschreven hebben. Als er nu duidelijk in had gestaan dat ze het niet supporten nog dan was het duidelijk geweest.

[mdavids]

Kort antwoord: nee, SIDN ondersteunt dit nog niet.

[alm]

Bedankt, dan is dat in ieder geval duidelijk en verklaart het waarom het niet werkt.