With DNSSEC, a DNS response now contains not only an answer but also a digital signature over that data made by the private key of the zone where the data originates. Validating this signature requires the zone’s public key – which DNSSEC conveniently stores in the DNS – so obtaining the required key for validation is simple. But how do you trust that key? Who vouches for its authenticity?
In the X.509 certificate world, this vouching is the job of a CA. An X.509 certificate is a CA’s digitally signed statement that a particular entity has a specific public key. If you trust a CA’s public key, then you trust the certificates signed with the CA’s corresponding private key.
DNSSEC has no equivalent of a CA. Instead, the only entity that can vouch for a zone’s public key is that zone’s parent in the DNS hierarchy. For example, only the .com zone can vouch for the public key of the example.com zone, and only the root zone can vouch for the .com zone’s public key. The root zone is the top of the DNS hierarchy, so it has no parent to vouch for its key. Instead, the root zone’s key must be configured as a “trust anchor”. A trust anchor is a key that is declared trustworthy, rather than deriving its trustworthiness by being signed by another key.
So to validate a digital signature over DNS data, you start at the root’s trust anchor and build a “chain of trust” – with parent zones vouching for child zones – until you reach and trust the public key of the zone the data came from. Then you use that key to validate the data’s signature. (The actual process, not surprisingly, is a bit more complicated. There are usually two keys, not just one, for each zone, but a chain of trust starting at the root is the important concept here.)
This description of the DNSSEC trust model illustrates the importance of the root zone’s key: it is the starting point of the chain of trust. In DNSSEC terminology, the key used as a trust anchor is usually a kind of key called a key-signing key, or KSK. Any device performing DNSSEC validation needs to have the root zone’s KSK configured as a trust anchor. DNSSEC validation is usually performed by recursive name servers, which are operated by Internet Service Providers (ISPs) and enterprises, so these devices, and many others, have the root zone KSK configured.