Why you probably need two DNSSEC keys per zone
If you've endeavored to or are considering digitally signing your DNS information, congratulations! You are helping to make the Internet safer. And you're doing yourself a favor in authenticating your own domain namespace. This will make it nearly impossible for an attacker, using DNS alone at least, to steer would-be web visitors to an impostor site which could damage your reputation, customer satisfaction and your brand. Of course, this defense only applies to visitors using DNS resolvers or recursive servers that perform DNSSEC validation, which hopefully will encompass most if not all Internet users in a matter of time (don't worry, unlike my proclivity for predicting full IPv6 deployment, albeit inaccurately, I don't plan to predict full DNSSEC deployment, but it's pretty easy so let's get on with it people!).
Most vendor implementations including ISC's BIND, PowerDNS, Microsoft and KnotDNS automate DNSSEC signing to varying degrees. Some IPAM vendors that support these DNS products including Diamond IP also fully automate DNSSEC signing (I did say it was easy, didn't I?). The process of signing your zone creates digital signatures which in turn are transmitted with the corresponding requested DNS resource record information to the requesting validating resolver. to authenticate the received information. This means the recipient, the resolver, can validate that the DNS data (resource record set, one or more resource records of the requested name, type and class) received over the network is exactly as it was published by the corresponding zone administrator, both authenticating the origin of the data and validating that it was not modified en route from the authoritative DNS server to your resolver.
Validation is one thing; trust is another. Any domain owner, even a bad guy, can sign arbitrary and perhaps falsified resource record sets (RRSets) using their own private/public key pair. The signature on an RRSet is generated using the private key, while the recipient can validate the signature using the corresponding public key as published in the same zone. Thus a recipient of an RRSet for a given DNS zone can validate the signature given the RRSet and the public key. The validating resolver needs to know in advance that the public key used to validate the signature can be trusted. Imagine having to establish a trust relationship with every domain owner in order to identify a trusted key for every zone on the Internet! Not the least bit feasible. But there's a better way.
DNSSEC defines a chain of trust where a trusted key from a given zone can validate those of a child zone. This means that if you trust the key of the parent zone, you can trust the key of each validated signed child zone. This validation comes in the form of a Delegation Signer (DS) resource record. The DS record conveys a hash of the child's key signing key (KSK), one of the two key types per zone...more on that in a moment. Thus I can trust the child zone's KSK if I trust the parent zone's key that signed the DS record corresponding to the child. So the parent vouches for the child by including and signing the DS record, and this process extends the DNSSEC chain of trust from parent to child. Now this extension can be repeated for child zones of the now trusted child zone, and the chain of trust can extend down the domain tree indefinitely.
As you've likely surmised from this (it's ok if you haven't!), I only need to trust the key of the root zone of the DNS in order to validate any signed RRSet from any zone as long as the RRSet signature can be validated up the chain of trust (by traversing keys and DS records) to the root key. What a relief! By configuring your validating resolvers with the root zone KSK as trusted, i.e., as a trust anchor, any DNSSEC-signed RRsets can be validated through this chain of trust model. So a bad guy signing falsified RRSets may fool a validator with a valid signature, his or her key will not be linked to the parent zone, given the absence of a signed DS record, so the RRSet would be deemed invalid. But this also necessitates proper updating of the trusted root zone KSK when it's changed (check out this post to make sure you're ready for the change coming on October 11, 2018).
OK so the chain of trust links a DS in a parent zone with a KSK in a child zone. So why do I need two keys per zone again? Yes, back to our original point. Like passwords, keys should be changed periodically. But when I change a KSK, I need to ask my parent zone administrator to update and sign the corresponding DS record in the parent zone. This inter-zone coordination process, like any process involving two independent parties for that matter, usually takes some time to complete. The parent zone administrator won't necessarily drop what they were working on to change your DS record and re-sign their zone. There may be a schedule to which the parent zone administrator adheres for zone changes. The delay could be troublesome if you need to change keys quickly due to policy or key compromise.
Thus operational pragmatism led to a separation of keys: one to sign the keys themselves (the DNSKEY RRSet) and another to sign the rest of the zone's RRSets. The former is referred to as the KSK and latter the zone signing key or ZSK. The ZSK can be changed arbitrarily by a zone administrator without affecting other zones in the DNS. Most administrators prefer to use a modest length key for the ZSK to optimize signing performance, while changing the key frequently to reduce exposure to compromise.
The KSK is typically created as a longer key that is computationally harder to crack and can remain intact for a year or longer. So an annual change of a KSK only annoys your parent zone administrator annually! Of course there is now a means for a child zone to publish a new KSK (and/or corresponding DS) in its zone for the parent to query and update without manual intervention. If your parent zone administrator supports querying for CDNSKEY (child DNSKEY) or CDS (child DS), then this parent update process can be automated with minimal annoyance!
This, in a nutshell, is why we commonly speak of using two keys, a KSK and a ZSK per zone: to enable a shorter nimble ZSK to sign zone information with the ability to change frequently while using a more robust KSK to sign the ZSK and link the chain of trust. Our chain of trust validation process now technically involves two key validations per zone: the trusted KSK validates the DNSKEY RRSet including the ZSK, which in turn validates the child zone's DS signature, which in turn validates the child zone's KSK, which validates the child zone DNSKEY RRSet including the child's ZSK and so on.
Changing keys of either type is a process in itself given the caching of retrieve DNS information and is termed key rollover. But we'll leave that as a potential topic for a future post. RFC 6781 describes this and other factors motivating the use of two keys per zone if you'd like to read more about this approach.
Most vendor implementations including ISC's BIND, PowerDNS, Microsoft and KnotDNS automate DNSSEC signing to varying degrees. Some IPAM vendors that support these DNS products including Diamond IP also fully automate DNSSEC signing (I did say it was easy, didn't I?). The process of signing your zone creates digital signatures which in turn are transmitted with the corresponding requested DNS resource record information to the requesting validating resolver. to authenticate the received information. This means the recipient, the resolver, can validate that the DNS data (resource record set, one or more resource records of the requested name, type and class) received over the network is exactly as it was published by the corresponding zone administrator, both authenticating the origin of the data and validating that it was not modified en route from the authoritative DNS server to your resolver.
Validation is one thing; trust is another. Any domain owner, even a bad guy, can sign arbitrary and perhaps falsified resource record sets (RRSets) using their own private/public key pair. The signature on an RRSet is generated using the private key, while the recipient can validate the signature using the corresponding public key as published in the same zone. Thus a recipient of an RRSet for a given DNS zone can validate the signature given the RRSet and the public key. The validating resolver needs to know in advance that the public key used to validate the signature can be trusted. Imagine having to establish a trust relationship with every domain owner in order to identify a trusted key for every zone on the Internet! Not the least bit feasible. But there's a better way.
DNSSEC defines a chain of trust where a trusted key from a given zone can validate those of a child zone. This means that if you trust the key of the parent zone, you can trust the key of each validated signed child zone. This validation comes in the form of a Delegation Signer (DS) resource record. The DS record conveys a hash of the child's key signing key (KSK), one of the two key types per zone...more on that in a moment. Thus I can trust the child zone's KSK if I trust the parent zone's key that signed the DS record corresponding to the child. So the parent vouches for the child by including and signing the DS record, and this process extends the DNSSEC chain of trust from parent to child. Now this extension can be repeated for child zones of the now trusted child zone, and the chain of trust can extend down the domain tree indefinitely.
As you've likely surmised from this (it's ok if you haven't!), I only need to trust the key of the root zone of the DNS in order to validate any signed RRSet from any zone as long as the RRSet signature can be validated up the chain of trust (by traversing keys and DS records) to the root key. What a relief! By configuring your validating resolvers with the root zone KSK as trusted, i.e., as a trust anchor, any DNSSEC-signed RRsets can be validated through this chain of trust model. So a bad guy signing falsified RRSets may fool a validator with a valid signature, his or her key will not be linked to the parent zone, given the absence of a signed DS record, so the RRSet would be deemed invalid. But this also necessitates proper updating of the trusted root zone KSK when it's changed (check out this post to make sure you're ready for the change coming on October 11, 2018).
OK so the chain of trust links a DS in a parent zone with a KSK in a child zone. So why do I need two keys per zone again? Yes, back to our original point. Like passwords, keys should be changed periodically. But when I change a KSK, I need to ask my parent zone administrator to update and sign the corresponding DS record in the parent zone. This inter-zone coordination process, like any process involving two independent parties for that matter, usually takes some time to complete. The parent zone administrator won't necessarily drop what they were working on to change your DS record and re-sign their zone. There may be a schedule to which the parent zone administrator adheres for zone changes. The delay could be troublesome if you need to change keys quickly due to policy or key compromise.
Thus operational pragmatism led to a separation of keys: one to sign the keys themselves (the DNSKEY RRSet) and another to sign the rest of the zone's RRSets. The former is referred to as the KSK and latter the zone signing key or ZSK. The ZSK can be changed arbitrarily by a zone administrator without affecting other zones in the DNS. Most administrators prefer to use a modest length key for the ZSK to optimize signing performance, while changing the key frequently to reduce exposure to compromise.
The KSK is typically created as a longer key that is computationally harder to crack and can remain intact for a year or longer. So an annual change of a KSK only annoys your parent zone administrator annually! Of course there is now a means for a child zone to publish a new KSK (and/or corresponding DS) in its zone for the parent to query and update without manual intervention. If your parent zone administrator supports querying for CDNSKEY (child DNSKEY) or CDS (child DS), then this parent update process can be automated with minimal annoyance!
This, in a nutshell, is why we commonly speak of using two keys, a KSK and a ZSK per zone: to enable a shorter nimble ZSK to sign zone information with the ability to change frequently while using a more robust KSK to sign the ZSK and link the chain of trust. Our chain of trust validation process now technically involves two key validations per zone: the trusted KSK validates the DNSKEY RRSet including the ZSK, which in turn validates the child zone's DS signature, which in turn validates the child zone's KSK, which validates the child zone DNSKEY RRSet including the child's ZSK and so on.
Changing keys of either type is a process in itself given the caching of retrieve DNS information and is termed key rollover. But we'll leave that as a potential topic for a future post. RFC 6781 describes this and other factors motivating the use of two keys per zone if you'd like to read more about this approach.
Comments
Post a Comment