Welcome back, and in this video,
I want to step through how DNSSEC works inside a zone.
Specifically how it allows a DNSSEC resolver or client
to validate any resource Records within a zone.
This video is focusing
on the data integrity part of DNSSEC.
And coming up after this is another video
where I'll cover the chain of trust
and origin authentication benefits
which DNSSEC provides in a lot more detail.
Now because this video covers digital signing within DNSSEC,
it's important that you've watched my previous videos
on DNS, on HASHING and on digital signing.
If you haven't, all of those videos will be linked
in the description.
If you have, then let's jump in and get started.
Now, to understand DNSSEC, I first need to introduce a term
and that's a Resource RecordSet, or RRSET.
Let's look visually at what this is.
We'll start with a DNS zone of icann.org
and I'm using this as an example in this lesson,
as it's one which I know to be DNSSEC enabled.
Now, inside this zone, we have a number of Resource Records.
First, www.icann.org, which is a CNAME Record.
And remember, CNAMEs point at other records.
And in this case, it points at two other records.
One of them is an A Record, so IPv4
and the other is an AAAA Record, which is IPv6.
Now finally, we have four MX Records for the domain
pointing at four different mail exchange servers.
Now, each of these are Resource Records.
I'm showing a total of seven.
So what's a Resource RecordSet?
Well, a Resource RecordSet or RRSET is any records
of the same name and the same type.
So in the case of the left three,
this means each of them is their own RRSET.
But in the case of the MX Records,
they all have the same name, so icann.org,
and they're all MX Records
and this means that all four of these are inside one RRSET.
RRSETs are just sets of resource records.
They make it easier to deal with records in groups
versus single records.
And in the case of DNSSEC, it keeps things manageable
in other ways, but more on that in a second.
Now, this is what an RRSET might look like,
if you actually interact with DNS.
Notice how all the names are the same
and all the types are the same.
So why do you need to know this?
Well, because RRSETs are used within DNSSEC.
Right now, there's no way to tell
if any of these resource records are valid.
DNSSEC provides this functionality,
but it's not individual Resource Records
which are validated by DNSSEC.
It's Resource RecordSets or RRSETs.
Now let's take a look at how this works.
So DNS allows us to validate data integrity
of RecordSets within DNS.
It doesn't work on individual records,
rather it works on sets of records, RRSETs.
Let's take a look at how.
So we start with the same icann.org zone and inside here,
I'm going to step through one RRSET example.
The set of four Resource Records,
which make up the MX RRSET.
Right now, without DNSSEC,
if a bad actor found a way to change
or make you think that these records have changed,
then email delivery could in theory be redirected.
DNSSEC helps prevent that using two features.
First, we have RRSIG, which stores a digital signature
of an RRSET using public and private pairs of keys.
This one key pair is known as the Zone Signing Key or ZSK.
The private part of this key pair is sensitive
and it's not actually stored within the zone.
It's kept offline, it's kept separated,
but you need to know that it exists.
Like any private key, you need to keep this key safe
and not accessible from the public domain.
So once again, an RRSIG
contains a digital signature of an RRSET.
So we take the RRSET, which is plain text.
We run it through a signing process.
Let's call this the Digital-Signature-O-Tron-9000.
In reality, it's just a standard cryptographic process.
This process uses the private part of the ZSK
to create a signature,
and this is why it's important
to keep the private part of this key safe.
This output, the signature,
can be stored alongside the plain text RRSET
in the zone using the same name,
but the record type is RRSIG.
Any normal DNS clients will only see the RRSET.
Any DNSSEC clients will see the RRSET
and the corresponding RRSIG.
Now, this uses digital signing and HASHING.
If the RRSET changes,
the RRSIG has to be regenerated in order to be valid.
If the RRSET changes without a corresponding change
to the RRSIG, the result is an invalid signature.
And so you can tell
if anything is changed without the approval
of the person controlling the private Zone Signing Key.
And this is because only the private part
of the Zone Signing Key can be used to sign RRSETS
creating an RRSIG.
Assuming that you trust that the private Zone Signing Key
is in safe hands, then you know
that if there's a valid RRSIG for a corresponding RRSET,
that RRSET is in a valid state created by the zone admin.
And if it changes, you can tell.
Now, the important question is how can a DNS client
or resolver verify the RRSIG?
For that, there's another piece to the DNSSEC puzzle.
We need the public part of the Zone Signing Key
to be able to verify signatures
or RRSIGs created using the private part.
Lucky for us, public parts of the key pairs
aren't sensitive and don't need to be guarded.
We just need a way to make them available.
So consider this scenario.
We have the same icann.org domain.
We also have a DNSSEC resolver here at the bottom.
How do we know it's a DNSSEC resolver?
You'll just have to trust me,
but it is a super smart resolver.
Now, inside the zone, we have the MX RRSET
for the icann.org zone.
We also have the MX RRSIG, which remember,
is a signature at the RRSET
created using the private part of the Zone Signing Key.
Inside a DNSSEC-enabled zone, you'll find another record,
the DNSKEY Record.
The DNSKEY Record stores public keys.
These public keys can be used to verify
any RRSIGs in the zone.
DNSKEY Records can store the public key
for the Zone Signing Key, so the ZSK,
and also a different type of key,
the Key Signing Key or KSK.
But more on this in a second.
We're going to do this step by step.
This is what a DNSKEY Record might look like.
And because it can store different public keys,
there's a flag value.
A value of 256 means that it's a Zone Signing Key,
and a value of 257 means it's a Key Signing Key.
So the top one here, this is the Zone Signing Key,
and it's this value, which is the last piece of the puzzle.
It means the DNS resolver can take the RRSET,
which remember, is the plain text part
and using this together
with the matching RRSIG and the DNSKEY Record,
it can verify that both the RRSIG matches the RRSET
and the signature was generated
using the private part at the Zone Signing Key.
And the result of this
is that our DNSSEC capable resolver at the bottom
can verify the RRSET is valid and hasn't been compromised.
Now this is all assuming, and this is a big assumption
that we trust the DNSKEY,
specifically the Zone Signing Key.
You have to trust that only the zone admin
has the private part of the key and you also have to trust
that it's the correct Zone Signing Key.
If you do, you can trust the RRSIG
and matching RRSET are valid.
Now, a real world comparison of this
would be to imagine if somebody shows you an ID card
which has their photo on it.
The photo ID only proves their identity
if you trust the photo ID is real
and it was created by a genuine authority entity.
In humans, this trust is a bit vague.
That's why fake IDs are such a problem.
This isn't a problem with DNSSEC because as you'll see,
we have a chain of verifiable trust
all the way to the DNS Root.
The DNSKEY Record also requires a signature
and this means a matching RRSIG Record
to validate that it hasn't been changed.
The DNSKEY Records though,
these are signed with a different key,
the Key Signing Key, or KSK.
So as the name suggests,
this key isn't used for signing anything in the zone.
Instead, it's used for signing keys.
So the Zone Signing Key
is used for signing everything in a zone.
So to create most RRSIG Records, except the DNSKEY Records.
These are signed by the Key Signing Key
creating the DNSKEY RRSIG Record.
Now, I get it.
I've just introduced another type of key.
So let's look at how this all fits together
within a DNS zone.
At this point, I want to cover
two really important points about DNSSEC.
First, how does a Key Signing Key
fit into all this and why do we have them?
And second, what mechanism allows us to trust a zone?
We know that RRSIG Records
let DNSSEC resolvers verify RecordSets,
but how do we know the keys used within a zone
themselves can be trusted?
To illustrate both of these,
let's start with the same icann.org zone,
and then off to the right side, a related area,
but containing more sensitive things.
This might be a physical key store, like a file safe
or a HSM device.
Contained in here, to start with,
is the private Zone Signing Key,
and this is used together
with an RRSET Record to create a corresponding RRSIG Record.
Then, the public part of this Zone Signing Key
is stored in the DNSKEY Record.
The flag of 256 tells us that it's a Zone Signing Key.
At this point, I want to pause and take a quick detour.
If this was all that we had, so the DNSKEY,
we couldn't trust it.
Somebody could swap out the DNSKEY Record,
putting a new public key in there,
use the private part of that fake key
to regenerate a fake RRSIG,
adjust the RRSET and take over email for this domain.
We need a way of ensuring the Zone Signing Key is trusted.
If we didn't have some kind of trust chain,
we would need to manually trust every zone within DNS
and that would defeat the purpose
of having a globally-distributed system.
So, the way that this works is that this zone,
so icann.org is linked cryptographically
to the parent zone, which is .org.
So just like with normal DNS
where NameServer Records are used in the org zone
to delegate to domains such as icann.org,
the org parent zone also has a way to explicitly state
that we can trust icann.org as a zone.
And I'll talk about exactly how this works
in the next video.
For now, I want to focus on this zone.
Now, if we used a single key,
so just the Zone Signing Key, that would work,
but this would mean
if we ever wanted to change the Zone Signing Key,
then we would have to involve the .org parent zone.
Best practice is that we want to be cycling keys
fairly often and doing that where it also requires updates
up the chain would become inefficient.
And so we have this new key pair,
the Key Signing Key, or KSK.
Now, there's a private part and a public part.
The private part is used to sign DNSKEY RecordSets,
which creates an RRSIG of the DNSKEY.
And this makes it easy to change the Zone Signing Key
used for a zone.
We just have to regenerate all of the RRSIG Records,
update the DNSKEY RecordSet,
and then regenerate the RRSIG of the DNSKEY RecordSet
using the private Key Signing Key.
All of this is inside our zone only.
It doesn't involve the parent zone in any way.
We store the public part of the Key Signing Key
in the DNSKEY RecordSet, but now we have a new problem.
How can we trust the Key Signing Key?
Well, spoiler, it's referenced from the parent zone.
In this case, .org.
So remember how I said that the DNSKEY RecordSet
stored both Zone Signing and Key Signing Public Keys?
Well, this is the main point of trust for the zone.
This is how trust is conveyed into the zone.
Because the parent zone links to the public Key Signing Key
of our zone, assuming we can trust the .org parent zone
because it references our zone's Key Signing Key,
we can trust our zone's Key Signing Key.
This Key Signing Key signs our Zone Signing Key
and the Zone Signing Key
signs all of the RRSETs to create RRSIGs.
We have a chain of trust created
between two different layers of DNS, specifically DNSSEC.
Now, we're at the point now where you should understand
how DNSSEC validates things within a single zone,
how it uses RRSIGs to validate RRSETs,
how it uses the DNSKEY Records to get the Public Keys
to do that validation using the Zone Signing Key,
how a Key Signing Key is used to create an RRSIG
at the DNSKEY, which allows the validation
of that DNSKEY Record,
and how the parent domain or parent zone
trusts the public Key Signing Key
of the child domain or zone.
Now, you don't know how this trust occurs yet.
That's something I'm going to be talking about
in the next video.
I've also stepped through why two different keys are needed.
Using a Zone Signing Key for signing within a zone
and a Key Signing Key for signing that key.
That allows an admin split.
The Key Signing Key can be referenced from the parent zone
while the Zone Signing Key
is used exclusively within the zone.
And this means that a Zone Signing Key can be changed
without requiring any changes to the parent zone.
So what position does that put us in.
With this functionality using DNSSEC,
what have we gained in the way of additional security?
Well, we can now verify the integrity of data
within this specific DNS zone.
So we've eliminated the DNS cache poisoning example.
Assuming we trust the Key Signing Key,
and also assuming the Key Signing Key hasn't been changed
as part of an exploit, then we can trust
all of the information contained within a zone.
Now, in the next video,
I'm going to step you through exactly how DNSSEC
creates this chain of trust
and this allows a parent zone to indicate
that it trusts the Key Signing Key
used within a child's zone.
And this same architecture at every level of DNSSEC
means that we can create
this entire end-to-end chain of trust,
which can be verified cryptographically.
Now at this point,
that's all I wanted to cover in this video.
In the next video, I'm going to step through
how this trust from a parent zone to a child zone
is handled within the DNSSEC hierarchy.
And we'll go through how the query flow works step by step.
For now though, go ahead and complete this video,
and when you're ready,
I'll look forward to you joining me in the next.