Your question is very broad and not very related to programming.
Like Calle said you are mostly correct already so let me just pinpoint some parts to fix.
First, the important part to remember is that all of this is based on asymetric cryptography: each key is a public and private part. The public part is published in DNSKEY RRs, and also with some hashing in DS records, while the private part is used to compute the RRSIG records. Anyone using the public key would be able to verify that the signatures in the RRSIG records were indeed signed by some specific private key, while never having access to it.
Now on some of your points:
In the zone level, the process works using one or more pair of keys. First the zone server has the ZSK (zone signing key) and it signs the queried data using the private ZSK. After, it sends the public ZSK, the data (RRSET) and the signed data (RRSIG) to the DNS resolver.
At the autoritative nameservers for a given zone, you start with the content of the zone, unsigned. In the old days without DNSSEC this was exactly what was published.
Now you have these three options at least:
- an external process takes the zone and signs it; it all depends on how your keys are managed: if they are in an HSM then you need to send the records there to be signed as, by design, the private key (needed to sign records) never leaves the hardware module. See the OpenDNSSEC software for example.
- the resolver itself, on loading or through separate tools can sign the zone itself and even manage the keys (as they are changed regularly); see this example in Bind.
- or, nothing is signed beforehand, and the resolver will generate (and cache for some time) the
RRSIG records at the moment the query arrive.
See how one big provider does it.
Of course, each solution has its advantages and drawbacks. They all exist on the field.
But now you have to trust in the public ZSK. The solution? To have another key, the KSK (key signing key).
The KSK/ZSK split is not really about trust, just key material management.
Let us go back a little. The whole setup of DNSSEC could work theoretically exactly the same way with only one key in each zone.
But in practice it is often more keys.
First, keys need to be changed regularly. There is no specific reason or end of life for them, it is just the assumption that if we want to defend against offline keys cracking we just need to change them regularly. Keys are published without details on their duration (contrary to signatures in RRSIGs) but each DNSSEC signed zone should have a DPS (DNSSEC Practice Statement) that delves, among other things, into the duration of validity for each key (see this other answer of me for more details on DPS).
Of course to prepare for key rollovers, you publish a new key in the DNS in advance, for cache to learn about it, and before starting to sign with it (or at least before stopping to sign with the older one).
So you already can have to handle multiple keys at the same time.
Now you are in the middle of two opposite constraints: you would like to keep using one key for as long as possible to have less handling (and if the key is handled externally the less you have to use it the better it is) since it also exists at the parent zone through the DS record, and as the same time you know that for better security setup you need to use it for a time period as short as possible and renew it often.
You resolve this conendrum by doing a KSK/ZSK split.
Why? Because you can attach different lifetime to each key. The KSK is the one that will also exist in the parent zone through the DS record so typically something that you do not want to change too often. Typically a KSK will be the most secure key (the most protected one) and will "last" for 1 or 2 years (this has to be detailed in the DPS). Then, ZSKs, used for really signing the records in the zone can be keys generated more often, like 1 or 2 months, since changes in them need only to be reflected in the zone itself, there is no need to change anything at the parent zone.
See for example the IANA Root Zone Key ceremony: there is only one root key (absolute trust), and it may change in the future (it was already planned for last October, but then get postponed); anyway twice per year there is a specific key ceremony done in some datacenter and what will exactly happen here? The DNS root zone operator, VeriSign, comes with a specific number of keys (which are the future ZSKs in fact) worth some time (basically until the next ceremony, with some margin, based on the typical ZSKs lifetime as detailed in the relevant DPS), and then the root KSK is properly used, with many witnesses at many levels, to sign those ZSKs. The KSK can then be put back away in storage and never used again (until the next ceremony) and the DNS operator can then start the publish the ZSK, one by one, with their relevant signature.
Again, this is custom but certainly not mandatory. Some zones (like .CO.UK, see how it has only one DNSKEY record) decided to use only one key, and this is called CSK for Common Signing Key, meaning it is at the same time a zone-signing key and a key-signing key (since it signs itself and it is also the one used for the parent DS).
It is done by making the child server hash its public KSK and sending it to its parent, that stores it as a DS (delegate signature). It is done early and I don't know how.
Each zone has to send to its parent, either one (or multiple) KSKs (public part of course) and let the parent compute the relevant DS to publish in its zone, or just send the DS record directly. It is the same problem at each node in the DNS tree, except for the root of course. And the child needs to do that far in advance of using the relevant key to sign anything as he often does not control how much time the parent will take before starting to publish the key.
It is the same of each node in the DNS tree, theoretically because in practice this transfer of information has to be done out-of-band from DNS (except in the CDS/CDNSKEY, see below), and this can be different at each node. It often involves at least some purely human interaction, which explains why the ZSK/KSK split is pleasing, as it lower the frequency with which you need to do anything to replace the KSK.
For example, for TLDs, they need to enter a process at IANA website, to give their new DS records and then wait some time for IANA to process and verify it before it is published in the root zone.
For 2LD (Second Level Domain Names), they typically go to their registrar and through some website or API they provide the information that the registrar will send to the registry so that it can publish it.
Nowadays, the registrar-registry dialogue is made using a protocol called EPP (Extensible Provisioning Protocol) and it has a specific extension for DNSSEC called secDNS.
This extension allows the registrar, on behalf of its client, to send either (based on registry policy):
- the
DS record (as 4 separate parameters)
- the
DNSKEY record (as 4 separate parameters), from which the registry will compute itself the appropriate DS record to publish
- the
DS record with an enclosed (related) DNSKEY record so that the registry can double check if the DS was correctly computed and that it will indeed match some DNSKEY record that the domain has published already
(it is more or less in descending order of frequency of cases on the field).
This solves the provisioning issue. As for nodes lower down the tree you have then less and less standard mechanisms.
There is also another path, this time to use the DNS itself to provision things instead of out-of-band, with the CDS/CDNSKEY records as described in RFC 7344 and RFC 8078. The leading C stands for Child, and then you get again DS or DNSKEY because the core idea is to let a node publish such record in its own zone and then just let the parent zone do DNS queries to pick it up and then provision the parent zone with it.
Of course, this does create some problems at least for the bootstraping.
And these mechanisms are not used too much right now. Specially for the case of DNS hoster not being the registrars themselves, there are various work in progress and ideas so that external parties could influence this and make changes in the parent zone without having to intervene at the EPP level from the registrars to the registry. If you are interested in these topics, please have a look for example at https://www.dk-hostmaster.dk/en/news/cloudflare-integrates-dk-hostmasters-dnssec-setup or https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/
As for:
Also if someone could explain to me the DNSSEC architecture and key management I would be glad as well.
This is really too broad.
I do not know what you mean by the DNSSEC architecture: there is no one size fits all approach, you will need to at least consider the volume of your zone (number of records to sign), the frequency to which you resign, if not on the fly, and then the associated key rotations, and how and where your keys are stored.
The key management is not any more a point specific to DNSSEC. An X.509 PKI Certificate Authority will have almost the same problems regarding the security of its private key and how it uses it to sign others keys (which would be in fact certificates in this case).
