ICANN Schedules DNSSEC Root Key Rollover
The Internet Corporation for Assigned Names and Numbers (ICANN) has announced that the DNS root zone DNSSEC key will be rolled over on October 11, 2018 at 4pm UTC (12 noon EDT). The original plan to roll the root zone key one year ago was postponed due to a concern about the lack of resolver readiness at the time for the new root key. Validating resolvers must possess the current root zone key as a trust anchor in order to validate DNSSEC signatures.
There are two different types of DNSSEC keys. Zone signing keys, ZSKs, sign resource record sets (RRSets) within a given zone and may generally be modified at will by a zone administrator, i.e., without affecting validation of other Internet DNS zones. Key signing keys, KSKs, on the other hand, sign the zone keys themselves, the DNSKEY RRSet, and changes in KSKs can impact Internet DNS resolution if performed without coordination. This is due to the fact that the DNSSEC trust model mirrors the DNS domain tree.
Just as the very process of resolving domain names entails navigating down the DNS domain tree by name (by each label between the dots in the domain name), the DNSSEC chain of trust traverses the same path, though logically in the "upward" direction. When a domain name is resolved, let's say www.example.com, the resolution answer includes the corresponding RRSet's digital signature as requested by a validating resolver. The signature is validated using example.com's ZSK, which itself is validated by the KSK. DNSSEC utilizes public key cryptography, signing RRsets with hidden private keys to produce published signatures, which can be validated with corresponding public keys as published in the zone as DNSKEY records.
If the validating resolver trusts example.com's KSK, i.e., if the KSK is configured as a trust anchor, the secure resolution process would complete successfully then and there. But with millions of DNS domains, it would be untenable configuring every zone's KSKs as trust anchors. Fortunately, example.com's parent zone, .com, can form a chain of trust by virtue of the Delegation Signer (DS) record. As long the DS record in .com corresponds to the KSK in example.com, the chain of trust linkage exists. Of course, it too must be validated as signed by .com's ZSK and KSK. Likewise, the root zone contains a DS for .com, which is signed with the root zone's ZSK and KSK. At this point, my validating resolver can consider resolution data for www.example.com secure because all signatures have been validated up the chain of trust to the root zone KSK, which is a configured trust anchor.
Securely resolving all Internet DNS data is performed with the configuration of the proper root zone KSK as a trust anchor, and the correct signing of the queried RRSet, keys, and DS records up the domain tree from the authoritative zone to the root zone. If any linkages fail to validate or are unsigned, secure resolution will fail. If the incorrect root zone KSK is configured as a trust anchor, all secure resolution will fail. So it's imperative that validating resolvers possess the correct root zone KSK as a trust anchor.
So how does this affect you? If you manage a validating resolver or recursive DNS server, please assure your trust anchor configuration is up-to-date. If your DNS server supports automated trust anchor updates, as specified in RFC 5011, you are prepared. ICANN published instructions for various DNS implementations to check and if necessary update your trust anchor configuration. Though steps for Diamond IP's DNS implementation are not listed, you simply need to login to IPControl, navigate to Management > DNS Servers, and for each recursive server, select the Options tab and verify that the "DNSSEC validation" option is set to "auto."
There are two different types of DNSSEC keys. Zone signing keys, ZSKs, sign resource record sets (RRSets) within a given zone and may generally be modified at will by a zone administrator, i.e., without affecting validation of other Internet DNS zones. Key signing keys, KSKs, on the other hand, sign the zone keys themselves, the DNSKEY RRSet, and changes in KSKs can impact Internet DNS resolution if performed without coordination. This is due to the fact that the DNSSEC trust model mirrors the DNS domain tree.
Just as the very process of resolving domain names entails navigating down the DNS domain tree by name (by each label between the dots in the domain name), the DNSSEC chain of trust traverses the same path, though logically in the "upward" direction. When a domain name is resolved, let's say www.example.com, the resolution answer includes the corresponding RRSet's digital signature as requested by a validating resolver. The signature is validated using example.com's ZSK, which itself is validated by the KSK. DNSSEC utilizes public key cryptography, signing RRsets with hidden private keys to produce published signatures, which can be validated with corresponding public keys as published in the zone as DNSKEY records.
If the validating resolver trusts example.com's KSK, i.e., if the KSK is configured as a trust anchor, the secure resolution process would complete successfully then and there. But with millions of DNS domains, it would be untenable configuring every zone's KSKs as trust anchors. Fortunately, example.com's parent zone, .com, can form a chain of trust by virtue of the Delegation Signer (DS) record. As long the DS record in .com corresponds to the KSK in example.com, the chain of trust linkage exists. Of course, it too must be validated as signed by .com's ZSK and KSK. Likewise, the root zone contains a DS for .com, which is signed with the root zone's ZSK and KSK. At this point, my validating resolver can consider resolution data for www.example.com secure because all signatures have been validated up the chain of trust to the root zone KSK, which is a configured trust anchor.
Securely resolving all Internet DNS data is performed with the configuration of the proper root zone KSK as a trust anchor, and the correct signing of the queried RRSet, keys, and DS records up the domain tree from the authoritative zone to the root zone. If any linkages fail to validate or are unsigned, secure resolution will fail. If the incorrect root zone KSK is configured as a trust anchor, all secure resolution will fail. So it's imperative that validating resolvers possess the correct root zone KSK as a trust anchor.
So how does this affect you? If you manage a validating resolver or recursive DNS server, please assure your trust anchor configuration is up-to-date. If your DNS server supports automated trust anchor updates, as specified in RFC 5011, you are prepared. ICANN published instructions for various DNS implementations to check and if necessary update your trust anchor configuration. Though steps for Diamond IP's DNS implementation are not listed, you simply need to login to IPControl, navigate to Management > DNS Servers, and for each recursive server, select the Options tab and verify that the "DNSSEC validation" option is set to "auto."
Comments
Post a Comment