Why DNSSEC Matters and How It Works
Key Points
- DNSSEC protects users from DNS‑based attacks that hijack traffic by injecting malicious DNS responses, which can steal credentials or cause financial loss.
- It provides three core security guarantees: origin authentication, data integrity checking, and authenticated denial of existence.
- With DNSSEC enabled, each step in the lookup chain (root, TLD, and domain name server) is cryptographically validated, ensuring the resolver communicates with legitimate servers and receives authentic answers.
- Authenticated denial of existence allows resolvers to securely confirm that a queried domain name truly does not exist, preventing spoofed “non‑existent” responses.
Sections
- Why DNSSEC Matters for Security - The speaker explains how DNSSEC authenticates DNS responses to prevent attackers from hijacking domain lookups and redirecting users to malicious sites, highlighting its importance and basic steps to implement it.
- DNSSEC Query Validation Process - The speaker outlines how DNSSEC authenticates each DNS lookup—from root to TLD to domain servers—and uses public‑key cryptography to provide authenticated denial of existence for non‑existent names.
- DNSSEC Chain of Trust Explained - The passage outlines how DNSSEC uses RRSIG records signed with a zone signing key, a key‑signing key (KSK) validated by DS records at each delegation level—from root to TLD to domain—to ensure origin authentication and integrity of DNS responses.
- Deploying DNSSEC: Key Setup and DS Record - The speaker outlines the process of configuring DNSSEC—including manual or managed key deployment, thorough testing with validation tools, and finally publishing the DS record at the registrar to activate domain protection.
Full Transcript
# Why DNSSEC Matters and How It Works **Source:** [https://www.youtube.com/watch?v=Fk2oejzgSVQ](https://www.youtube.com/watch?v=Fk2oejzgSVQ) **Duration:** 00:11:16 ## Summary - DNSSEC protects users from DNS‑based attacks that hijack traffic by injecting malicious DNS responses, which can steal credentials or cause financial loss. - It provides three core security guarantees: origin authentication, data integrity checking, and authenticated denial of existence. - With DNSSEC enabled, each step in the lookup chain (root, TLD, and domain name server) is cryptographically validated, ensuring the resolver communicates with legitimate servers and receives authentic answers. - Authenticated denial of existence allows resolvers to securely confirm that a queried domain name truly does not exist, preventing spoofed “non‑existent” responses. ## Sections - [00:00:00](https://www.youtube.com/watch?v=Fk2oejzgSVQ&t=0s) **Why DNSSEC Matters for Security** - The speaker explains how DNSSEC authenticates DNS responses to prevent attackers from hijacking domain lookups and redirecting users to malicious sites, highlighting its importance and basic steps to implement it. - [00:03:10](https://www.youtube.com/watch?v=Fk2oejzgSVQ&t=190s) **DNSSEC Query Validation Process** - The speaker outlines how DNSSEC authenticates each DNS lookup—from root to TLD to domain servers—and uses public‑key cryptography to provide authenticated denial of existence for non‑existent names. - [00:06:22](https://www.youtube.com/watch?v=Fk2oejzgSVQ&t=382s) **DNSSEC Chain of Trust Explained** - The passage outlines how DNSSEC uses RRSIG records signed with a zone signing key, a key‑signing key (KSK) validated by DS records at each delegation level—from root to TLD to domain—to ensure origin authentication and integrity of DNS responses. - [00:09:28](https://www.youtube.com/watch?v=Fk2oejzgSVQ&t=568s) **Deploying DNSSEC: Key Setup and DS Record** - The speaker outlines the process of configuring DNSSEC—including manual or managed key deployment, thorough testing with validation tools, and finally publishing the DS record at the registrar to activate domain protection. ## Full Transcript
Today we're going to be talking about DNSSEC,
or DNS security.
You may have heard of this before, but you're wondering why do I care?
And what can I do with it?
Once you understand that, you'll probably want to know how you get started.
And we'll be covering all three of those things today.
So let's first talk about why you need DNSSEC.
Imagine that one of your users
is trying to get to your website, let's say ibm.com.
They type in ibm.com in their browser.
And it goes to their resolver, their DNS resolver.
Their DNS resolver talks to the the root zone.
It talks to the TLD zone for .com.
TLD for .com.
And then it talks to the IBM.com name server
and it gets back in answer.
But what can happen, what an attacker can do
is they can reroute traffic on the internet.
It's not easy to do, but it has been done in the wild,
and they can direct the resolver,
instead of going to ibm.com, to go to the bad DNS server.
The bad DNS server can then return -
so it doesn't go here, instead it goes to the bad DNS server -
can then return a bad IP address
back to your user, and then they're sent to the bad website.
At the bad website their credentials can be harvested
for malicious ends because their password is taken.
Maybe you're a financial institution and someone can empty their bank accounts.
Everything, bad things happen if you allow an attacker
to insert a bad DNS server in the midst of the transaction,
which sends the user to a malicious website.
DNSSEC was created to prevent this type of thing from happening.
DNSSEC does three things.
First, it does origin authentication.
Second, it implements data integrity checking.
And third, it implements authenticated denial of existence.
And we'll talk about what each of these things are
in a little more depth as we go through this.
So that's why you should care about DNSSEC
and what DNSSEC can do for you.
Now let's get into some details about how DNSSEC works.
So imagine you're a user again.
Up here.
He he's also looking for ibm.com.
And he also talks to his resolver.
Goes out to the root zone,
to the TLD authoritative server,
and to the ibm.com server.
But now we have DNSSEC enabled, so when he goes to there
it is validated.
And so we validated that we're talking to the root server.
So we've got the origin authentication.
And we validate that the answer we got back
is the correct answer.
Then he talks to the TLD server.
And, same thing, validates he's talking to the correct server.
So stopping the bad DNS server from being injected into the conversation
and he validates he gets the right answer back.
And finally we talked to the ibm.com server
and validate that we get the correct answer back.
That's a high level explanation of how DNSSEC works
and why you should care about it.
The one thing I haven't talked about yet is authenticated denial of existence.
So let me just mention that real quickly here.
The idea of authenticated denial of existence
is if I ask for a name that doesn't exist, let's say foo.ibm.com,
and then I talk to the ibm.com name server.
It's going to return to me an answer.
It's going to say foo doesn't exist.
I don't know what foo is.
How do I know that foo really doesn't exist?
And that's what authenticated denial of existence does.
It's a method so that the resolver can validate that when
the ibm.com server says foo doesn't exist,
it really knows that foo doesn't exist,
and it's able to put a check mark on that as well.
So now let's dive a little bit deeper into how DNSSEC really works.
There's one technology that undergrids all of DNSSEC,
and that's public key cryptography system, PKCS.
That's the idea that you can have a public private key pair
such that when you encrypt something with the private key,
which you keep private,
and publish the public key out on the internet, or give it to other people,
that when they decrypt the item with the public key,
it validates that the owner of the private key was the one that created that item.
And it can be used for a number of functions.
There's other videos you can watch that go into a lot more detail about PKCS,
but essentially it allows us to implement
the origin authentication, data integrity, and authenticated denial of existence checks.
Let's talk about exactly how that works.
So there is a new record type
that was introduced to DNS called the DNS key.
The DNS key has two subtypes.
One is called a KSK.
And the other is called the ZSK.
The ZSK, we'll talk about first, is used to sign the zone.
That's why it's a 'Z', for Zone Signing Key.
And the way that works is if I have a record in the zone,
let's say ibm.com is my record in my zone.
It's got an IP address, say 9.9.9.1, let's say is the IP address.
Then I want to have a way to validate
that this is really the correct answer or the right answer
when it's returned back to the user.
So we created this record type called an RRSIG.
And it's a way to cryptographically sign or authenticate
that this is the answer, so that when this answer was returned,
it really is the answer from this server,
so the origin authentication, and it hasn't been changed.
The RRSIG was created using the public key in the zone signing key.
Now, then the question is,
how do I know that this is really the public key of the ibm.com server?
That's where the KSK comes in.
The KSK is also a public key.
It's used to sign the zone signing key.
Then we get into the chain of trust.
The KSK is known to belong to ibm.com.
Because I've put what's called a DS record up at the TLD.
The DS record stands for Delegation Signer.
That is a hash of this KSK.
So that when the resolver is going through the chain,
going through its resolution chain,
and it gets to the TLD level,
it pulls down the delegation signer record.
Then it next goes to the ibm.com level,
it pulls a copy of the KSK and then compares the two.
And if they match then it knows that the KSK
at the ibm.com level really does belong to ibm.com,
and thus we've validated that we're talking to the correct server.
The same thing happens to the next level up.
The root has a DS record that points at the TLD.
The same process occurs.
The DS record is read,
compared to the KSK at the TLD level,
and then everything is validated.
Up at the root there's actually a file that is downloaded offline
by the ... when you set up a resolver, you download that file
to start the chain of trust and validate
that you're really talking to the legitimate root server.
One more record type that was created for DNS SEC
is called the NSEC record.
For "next secure".
The NSEC record is what's used for this authenticated denial of existence.
It's the record type that's returned when the answer is unknown.
And it validates that yes, indeed, we don't have a record type named Foo.
So that's how DNSSEC works in detail.
Those are all the new record types that you need to worry about.
Now, let's talk about how you can get started on your own to implement DNSSEC.
The first thing you want to do is you want to sign the zone.
What that means is you create the all the new record types I mentioned here.
You create a ZSK.
You create a KSK.
And then you create the RRSIGs.
Depending on your software, the way you do this will be different.
For some open source software, if you're running your own DNS,
this will be a manual process.
For some of the manage DNS services out there,
you'll essentially flip a switch and all this will be done for you.
Then second step is you want to test.
This is a really important point.
I would highly recommend that after you set up all the keys,
all the new records that you test,
there's a number of open source tools out on the internet
and websites that you can go to that will validate
that your DNSSEC is set up correctly and you have no errors.
Test, make sure you get rid of all the errors,
and then finally you want to go to your registrar and set up the DS record.
That's what actually enables DNSSEC.
Up until this point DNSSEC, all the records are there,
but the resolvers are not actually validating the answers
because they need the DS record to do that validation.
So until you put that DS record in place, nothing's live.
The system is just ready to go.
As soon as you contact your registrar and put the DS record in place,
the whole thing spins up, and now DNSSEC is in operation.
And whenever a user goes to a validating resolver,
DNSSEC will be checked
and it will prevent the scenario that we saw over here
where a malicious player inserted a bad DNS server
and redirected your server to a malicious site.
So I hope you can get started on DNSSEC
and protect your websites and applications.
If you like this video and want to see more like it,
please like and subscribe.
If you have any questions or want to share your thoughts about this topic,
please leave a comment below.