Up Your Defenses: DNSSEC Signing Demystified
The risk of DNS spoofing and cache poisoning attacks calls for cryptographic countermeasures. Enter DNSSEC signing.
In "Tightening the Cyber Screws" with #DNSSEC, we discussed the merits of using cryptographic keys to sign DNS responses. In this post, we dive into the nitty-gritty of the implementation.
Here is how not to do it.
To fully implement DNSSEC, you will need both DNSKEY and DS records to ensure that your DNS data is securely signed and that the chain of trust is established from the parent zone down to your domain.
DNSKEY Records in DNS zone
DNSKEY Records contain the public keys used to verify the digital signatures of your DNS records: the Zone Signing Key (ZSK) and the Key Signing Key (KSK). These records are published in your DNS zone (for example on Route53).
DS Records in parent zone
DS Records contain a hash of your DNSKEY records and are used to establish a chain of trust between your domain and its parent zone. These records are stored in the parent zone (for example .com) at your registrar and point to your DNSKEY records.
"Tightening the Cyber Screws" with #DNSSEC
Hardening a server on the sysadmin level is only a small fraction of what needs to be done to secure it, whether you run in the cloud or on premises. In the cloud, it gets tricky, though, as you have to contend with restrictions on #pentesting and the like—unless you own your cloud, that is (Aloha to Amazon, the owner of AWS—yes, we are looking at you, …
DNSSEC introduces several new DNS record types, such as RRSIG (signature), DNSKEY (public key), and DS (delegation signer). These records store cryptographic signatures that DNS clients can verify.
To configure DNSSEC, you will perform edits in two distinct places: in the DNS config of your hosted zone (AWS Route53 for example) and in the dashboard of your domain name registrar.
Set up DNSSEC for your hosted zone
In DNS settings of your (cloud) hosting provider, navigate to the DNS configuration of your hosted zone and enable DNSSEC signing.
On AWS, you can enable DNSSEC signing through the AWS Management Console, CLI, or SDKs. Route 53 generates the DNSKEY records for you, including the public keys corresponding to the KSK and ZSK.
To complete the setup, you need to establish a chain of trust by creating a Delegation Signer (DS) record at your domain registrar. This DS record contains a hash of your KSK public key and links your DNSSEC-signed zone to the parent zone. Your DNSKEY records are in the DNSSEC Signing Tab.
In AWS Management Console for Route53, enabling DNSSEC signing initiates a configuration wizard that wants to guide you through the process.
In this step, you have to allow AWS to “create the key-signing key (KSK)” for your hosted zone based on a “customer managed customer master key (CMK)” of your choice (kudos on semantic redundancy to whoever came up with this nomenclature). Either you already have one of those or you will have to agree to creating one. Multiple KSKs can be derived from one CMK.
In other words: Route 53 wants to automatically create the KSK for your hosted zone based on the customer managed CMK of your choice that will be stored in the Key Management Service on AWS (AWS KMS). Important: You may not change permissions or other configurations for the customer managed CMK after Route 53 uses it to create the KSK.
The pricing is a mix of two flat rates and usage-based fees payable per batch of requests. Creating the KSK enables signing.
That’s it for your hosted zone. The configuration is not yet functional, though.
The DNSKEY records will be listed under the DNSSEC signing section in Route53. These records include the public keys for the Key Signing Key (KSK) and the Zone Signing Key (ZSK).
Next, you need to figure out how to configure the setup at your domain registrar. On AWS, you need to click on View Information to create DS record, then look up the information in the section Establish Chain of Trust.
Keeping secrets
When using DNSSEC (Domain Name System Security Extensions), certain pieces of information must be kept a secret to ensure the security and integrity of the DNS data.
Key Signing Key (KSK)
The private part of the KSK is secret. This key is used to sign the Zone Signing Key (ZSK), which in turn signs the DNS records. The public part of the KSK is published in the DNS to allow resolvers to verify the signatures.
Customer Managed Key (CMK)
Similar to the KSK, the private key of the CMK is also kept secret. This key is used for cryptographic operations, such as signing DNS records. The public key is used to verify these operations and is not secret.
Chain of Trust
The Delegation Signer (DS) records are not secret but are critical for establishing the chain of trust. These records are published in the parent zone and contain a hash of the KSK’s public key.
Private Keys of Intermediate Keys, if such exist in the chain of trust, are also secret.
DNSSEC at the domain registrar
Your domain registrar holds the parent zone. The DS Record of your zone belongs here. If the dashboard does not offer editing capabilities and there is no API, you will have to create a support ticket and wait for the implementation by your registrar.
Once this step is complete, you should put health checks in place to help ensure that no errors go unnoticed.
What’s next?
DANE, or DNS-based Authentication of Named Entities for SMTP. Stay tuned.