Episode 2
New records
To validate the authenticity of the DNS data, DNSSEC introduces a small number of new DNS record types.
The first thing that your DNS provider is going to do when you configure your domain with DNSSEC is to bundle all records into RRsets.
The RR in RRsets stands for resource records. A fancy way to say ‘records of the same type and name’ for a zone or domain.
RRsets bundle all records of the same type and name into a group that is digitally signed.
In the physical world, humans use signatures to bind the identity and authenticity of a message.
The same analogy can be carried out in the DNSSEC world.
The authoritative server signs each RRset with a zone-signing key pair.
We’ll be talking about more keys later, so remember these keys are used to produce and verify a signature on the zone records.
Every zone-signing key has a private and public key pair. This is the basis of asymmetric cryptography.
Private and public keys work together. Data encrypted with the private key can be decrypted or validated with the public key.
The public key can be shared with anyone. It’s public, and available to everyone.
Private keys are — you guessed it, private and shouldn’t be shared.
Don’t let the crabs get these!
Together these two keys provide two important features!
One: Verify that the content comes from the right source.
Two: Verify that the content hasn’t been altered since it was sent.
These keys aren’t used to encrypt the entire content of the records. Instead, a digital signature is produced by taking a portion of the RRSet, hashing it and encrypting it.
The hashing process is not just relevant for validation purposes.
Hashing reduces the size of the content to be sent, making the signature a fixed length.
This is important because we want to keep the DNS protocol small and lightweight.
The signatures are stored in a DNS record called an RRSIG (Resource Record Signature).
And the public key to decrypt that RRSIG record is stored in a new DNS record type called DNSKEY.
Here’s how it happens…
Some content from the RRset is hashed through a hashing algorithm.
The result is encrypted with the private section of the zone-signing key creating a RRSIG record.
Then the authoritative server sends the RRset and the RRSIG to the resolver.
The resolver takes the RRSet and hashes again, just like the authoritative server did with the same algorithm.
The resolver decrypts the signature record with the public portion of the zone-signing key into a hash.
If both hashes match, then the resolver knows that the response is coming from the expected source that hasn’t been tampered with.
A resolver that doesn’t support DNSSEC, or is missing the algorithm to support the hashing steps would ignore the signature coming back with the record.
Here’s the current flow when the DNS resolver requests the A record for www.dnsimple.com.
The authoritative server returns the A record in both an RRset and the RRSIG record.
The resolver then asks for the DNSKEY record to validate that the requested record is valid and coming from a trusted source.
The resolver validates the response through the RRset, the RRSIG, and the DNSKEY.
But what if the DNSKEY was compromised?
