All.
Because the parent has a DS
record which is, in summary, a hash of the KSK. Hence, when following the chain of trust the recursive resolve will fetch that DS
record from parent, and will fetch the DNSKEY
record from child, and will check that there is at least one key in the DNSKEY
record matching the DS
record and then continue the validation (or else fail it immediately there).
Per §2.1.1. of RFC4034, each DNSKEY
record has a flags attribute that will allow a resolver to know if this given crypto material is for a zone key or a key signing key.
Note that the KSK/ZSK split is common, but not the only case. You have also a CSK situation with C=Common where you have a single key, that both signs directly all other records and also has a matching DS
record at parent.
Both are valid setups, with different benefits and drawbacks.
Also note that the DNSKEY
record set can even contain keys not yet used for signing nor being at parent in a DS
record, which happens for example during rotation (you first need to introduce the key in the zone and let resolvers cache it, then after some time you can begin signing with it, and then again after some time you can enable the relevant DS
record if needed).