What is DNSSEC (Domain Name System Security Extensions)?

Summary

This video explains the importance of DNSSEC (DNS Security Extensions) in preventing attacks where users are redirected to malicious websites. It describes how DNSSEC ensures origin authentication, data integrity, and authenticated denial of existence using public key cryptography. The video details key record types like the DNS Key, ZSK (Zone Signing Key), KSK (Key Signing Key), and NSEC, explaining how they work together to validate DNS responses. Finally, the video guides users on implementing DNSSEC by signing the zone, testing for errors, and setting up a DS record with a registrar.

Takeaways

• 🔒 DNSSEC (DNS Security) is essential for securing DNS queries by ensuring users reach legitimate websites.
• 💻 Attackers can reroute DNS traffic to malicious servers, leading to credential theft and other malicious activities.
• ✅ DNSSEC provides three key protections: origin authentication, data integrity, and authenticated denial of existence.
• 🌐 DNSSEC verifies each step in the DNS query process, ensuring that users communicate with legitimate servers.
• 🔐 Authenticated denial of existence ensures that non-existent domain requests (e.g., foo.ibm.com) are validated and proven not to exist.
• 🔑 DNSSEC relies on public key cryptography (PKCS) using public/private key pairs to ensure trust and authenticity.
• 📝 New DNS record types introduced by DNSSEC include DNSKEY, RRSIG, KSK (Key Signing Key), ZSK (Zone Signing Key), and NSEC.
• 🔗 The chain of trust is established through delegation signer (DS) records, ensuring that each server in the query chain is legitimate.
• ⚙️ To implement DNSSEC, you need to sign your zone, test your setup, and then submit a DS record to your registrar to enable DNSSEC.
• 🛠️ Testing your DNSSEC configuration is crucial to ensuring that all keys and records are properly set up before going live.

Q & A

What is DNSSEC and why is it important?

DNSSEC stands for DNS Security Extensions and is important because it helps prevent attacks where traffic is rerouted to malicious DNS servers. It ensures that users are connected to the correct server by providing origin authentication, data integrity, and authenticated denial of existence.

What kind of attack does DNSSEC help to prevent?

DNSSEC helps to prevent man-in-the-middle attacks where an attacker reroutes DNS traffic to a malicious DNS server. This can lead to users being directed to fraudulent websites where their credentials and sensitive data may be stolen.

How does DNSSEC provide origin authentication?

DNSSEC uses public key cryptography to validate the origin of DNS responses. When a DNS query is made, DNSSEC verifies that the response came from the correct, authenticated DNS server using a public-private key pair.

What are the three main functions of DNSSEC?

The three main functions of DNSSEC are: 1) Origin authentication, 2) Data integrity checking, and 3) Authenticated denial of existence.

What is 'authenticated denial of existence' in DNSSEC?

Authenticated denial of existence is a feature of DNSSEC that verifies when a requested DNS name doesn't exist. It ensures that the DNS server is correctly confirming the non-existence of a domain, preventing attackers from fabricating such responses.

What role does public key cryptography play in DNSSEC?

Public key cryptography underpins DNSSEC by ensuring that DNS responses are signed with a private key and can be validated by anyone with the corresponding public key. This ensures that the response has not been tampered with and comes from a legitimate source.

What is the difference between a KSK and a ZSK in DNSSEC?

In DNSSEC, a KSK (Key Signing Key) is used to sign the Zone Signing Key (ZSK), while the ZSK is responsible for signing the zone data itself. The KSK helps establish a chain of trust by being recognized at a higher level (TLD) and signing the ZSK.

What is an RRSIG record, and how does it relate to DNSSEC?

An RRSIG record is used in DNSSEC to cryptographically sign DNS responses. It ensures that the response has not been altered and verifies the origin of the data.

How does DNSSEC establish a chain of trust?

DNSSEC establishes a chain of trust through the use of DS (Delegation Signer) records at each DNS level. The DS record at one level points to the KSK at the next level, allowing DNS resolvers to verify that the DNS response is coming from an authenticated server.

What is the process for enabling DNSSEC for your domain?

To enable DNSSEC, you first need to sign the zone by creating a ZSK, KSK, and RRSIG. Then, test the setup to ensure there are no errors. Finally, contact your registrar to add the DS record. Once the DS record is in place, DNSSEC becomes active, and DNS responses are validated.

Outlines

00:00

🔐 Introduction to DNSSEC and Its Importance

This paragraph introduces the topic of DNSSEC (DNS Security Extensions) and explains why it matters. It starts by describing a typical DNS resolution process, where a user's request to access a website (like ibm.com) is intercepted by DNS servers. The paragraph highlights a potential security issue where an attacker can reroute traffic to a malicious DNS server, leading to credential theft and other malicious activities. DNSSEC is designed to prevent this by ensuring origin authentication, data integrity, and authenticated denial of existence.

05:01

🔑 Public Key Cryptography in DNSSEC

This section focuses on how DNSSEC works by leveraging public key cryptography (PKCS). It explains the concept of a public-private key pair, where the private key encrypts the data, and the public key decrypts it. This ensures that the data is genuine and comes from a legitimate source. The paragraph introduces the DNS key record types: the KSK (Key Signing Key) and ZSK (Zone Signing Key). The ZSK signs the zone's records, while the KSK signs the ZSK to establish a chain of trust, preventing attackers from tampering with DNS data.

10:02

🔄 Implementing and Testing DNSSEC

The final paragraph outlines how to implement DNSSEC in practice. It advises on generating the necessary keys (ZSK, KSK) and signing the DNS zone. Additionally, it emphasizes the importance of testing the setup to ensure there are no errors. Once testing is complete, the DNSSEC system becomes live after registering the DS (Delegation Signer) record with the DNS registrar, enabling DNSSEC validation for resolvers. The paragraph concludes by encouraging users to protect their websites with DNSSEC and mentions steps to go live and prevent DNS hijacking.

Keywords

💡DNSSEC

DNSSEC (Domain Name System Security Extensions) is a security protocol that adds layers of authentication to the DNS system. In the video, DNSSEC is introduced as a solution to prevent attackers from rerouting traffic to malicious websites. It ensures the integrity of DNS responses by verifying the authenticity of the source and preventing tampering with the data.

💡DNS Resolver

A DNS resolver is a server that queries other DNS servers to resolve a domain name into an IP address. In the video, it's explained how a user's DNS resolver communicates with different DNS zones, including the root zone and TLD zone, to obtain the correct IP address. DNSSEC helps protect this communication from being compromised.

💡Origin Authentication

Origin authentication is one of the key functions of DNSSEC, ensuring that DNS responses come from the legitimate source. This prevents attackers from injecting false DNS information into the communication. In the video, origin authentication is highlighted as crucial in validating the authenticity of DNS servers at different levels (root, TLD, and domain).

💡Data Integrity

Data integrity, another function of DNSSEC, ensures that DNS responses are not altered in transit. The video explains how DNSSEC uses cryptographic signatures (RRSIG records) to verify that the data returned from a DNS query hasn't been modified, ensuring the user receives the correct IP address.

💡Authenticated Denial of Existence

Authenticated denial of existence is a mechanism in DNSSEC that allows a DNS server to prove that a domain name doesn't exist. In the video, this concept is explained using the example of 'foo.ibm.com,' where DNSSEC ensures the user can trust that the non-existent domain really doesn't exist, using NSEC records.

💡Public Key Cryptography System (PKCS)

PKCS is the underlying technology for DNSSEC, enabling the use of public and private key pairs to secure DNS transactions. The video explains that PKCS is central to origin authentication, data integrity, and authenticated denial of existence, providing a method to validate that responses come from the correct source.

💡Zone Signing Key (ZSK)

The Zone Signing Key (ZSK) is a key used in DNSSEC to sign the records in a DNS zone, ensuring their authenticity. The video explains how ZSK is used to sign DNS records, such as the IP address for a domain, and how it works together with the KSK to create a chain of trust.

💡Key Signing Key (KSK)

The Key Signing Key (KSK) is another key in DNSSEC, used to sign the ZSK. The video details how the KSK, through the use of a DS record at the TLD level, helps validate that the ZSK belongs to the correct domain, ensuring the overall chain of trust from the root server to the domain level.

💡RRSIG

RRSIG is a DNSSEC record type that provides a cryptographic signature for DNS records. The video discusses how RRSIG is used to validate the authenticity and integrity of DNS responses by ensuring that the information returned from the DNS server hasn't been tampered with.

💡Delegation Signer (DS) Record

The DS record is a type of DNSSEC record that links the KSK to the parent zone, such as the TLD zone. The video explains how DS records are used to establish a chain of trust, ensuring that the DNS server being queried is legitimate by comparing the DS record with the KSK at the domain level.

💡NSEC Record

NSEC (Next Secure) is a DNSSEC record type used to provide authenticated denial of existence. In the video, NSEC is described as the mechanism that allows a DNS server to cryptographically prove that a domain name, like 'foo.ibm.com,' does not exist within a zone, preventing spoofing of non-existent domains.

Highlights

Introduction to DNSSEC and why it's important for preventing DNS attacks.

Example scenario of how DNS can be hijacked to direct users to malicious websites.

DNSSEC provides three main security benefits: origin authentication, data integrity, and authenticated denial of existence.

Explanation of how DNSSEC ensures that users are directed to the correct DNS resolver and website.

Authenticated denial of existence ensures that non-existent domain names are correctly validated.

DNSSEC relies on public key cryptography (PKCS) to secure DNS transactions.

Introduction of the DNSKEY record with two subtypes: KSK (Key Signing Key) and ZSK (Zone Signing Key).

The ZSK is used to sign the zone, validating the authenticity of DNS responses.

The KSK signs the ZSK, establishing a chain of trust between DNS records.

The DS (Delegation Signer) record ensures that DNS keys belong to the correct domain.

Chain of trust validation occurs at each DNS level, from the root zone down to the specific domain.

The NSEC record is used for authenticated denial of existence, verifying that non-existent records truly do not exist.

To implement DNSSEC, zones must be signed using ZSK, KSK, and RRSIG records.

After creating and testing DNSSEC records, the final step is to set up the DS record with a domain registrar to enable validation.

DNSSEC ensures that users are protected from being redirected to malicious websites, securing the overall DNS resolution process.

Transcripts

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.