DNS 101 Miniseries - #6 - How DNSSEC Works within a Zone

Summary

Highlights

• Discover DNSSEC's role in validating Resource RecordSets, ensuring data isn't compromised. 🕵️‍♂️
• Learn about RRSIGs which store digital signatures to uphold DNS integrity. ✍️
• Understand the critical functions of Zone Signing Keys and Key Signing Keys in DNS security. 🔐
• Explore DNSKEY records' function in publicly storing keys needed for signature verifications. 🔑
• Get ready for the next video, which will delve into the DNSSEC trust chain from parent to child zones. ▶️

Key Takeaways

• DNSSEC focuses on data integrity within a zone, validating Resource RecordSets (RRSETs) rather than individual records. 🔄
• The RRSIG digital signature ensures that resources haven't been tampered with by confirming their integrity. 🔏
• Zone Signing Keys (ZSK) and Key Signing Keys (KSK) play major roles in securing and validating DNS data. 🔑
• The DNSKEY record stores public keys, crucial for signature verification without compromising security. 🚀
• A chain of trust from parent to child zones strengthens DNSSEC's global reliability. 🌐

Overview

Chapters

• 00:00 - 00:30: Introduction to DNSSEC in a Zone The chapter introduces DNSSEC (Domain Name System Security Extensions) in the context of a zone, focusing on how it allows a DNSSEC resolver or client to validate resource records within the zone. The emphasis is on data integrity, with a mention that future content will cover the chain of trust and origin authentication provided by DNSSEC in greater detail.
• 00:30 - 01:00: Prerequisites and Introduction to RRSET The chapter covers the prerequisites and an introduction to a Resource Record Set (RRSET) in the context of digital signing within DNSSEC. It emphasizes the necessity of understanding DNS, hashing, and digital signing by recommending viewers to watch previous explanatory videos linked in the description. The chapter aims to further explain DNSSEC, beginning with the introduction of the concept of RRSET, supported by visual representations.
• 01:00 - 01:30: Example of Resource Records in a Zone The chapter begins with the introduction of a DNS zone example using icann.org, known for being DNSSEC enabled. It explains the concept of Resource Records within this zone, starting with www.icann.org, which is a CNAME Record. The key point highlighted is that CNAME Records point at other records, and in this instance, they point to two other records, one of which is an A Record, associated with IPv4.
• 01:30 - 02:30: Understanding RRSET and Its Importance in DNSSEC The chapter entitled 'Understanding RRSET and Its Importance in DNSSEC' explains the concept of Resource Record Sets (RRSET) within the context of Domain Name System Security Extensions (DNSSEC). The discussion involves differentiating various types of DNS records, including the AAAA Record for IPv6 and MX Records which direct email traffic to mail servers. The chapter highlights that an RRSET is a collection of DNS records of the same name and type.
• 02:30 - 03:00: How DNSSEC Validates RRSETs This chapter discusses how DNSSEC validates Resource Record Sets (RRSETs). It explains that while some records exist as individual RRSETs, records like MX Records with the same name belong to a single RRSET. The concept of RRSETs involves grouping resource records to simplify management. In the context of DNSSEC, this grouping is essential for maintaining manageability.
• 03:00 - 04:00: Preventing Unauthorized Changes with DNSSEC The chapter discusses the concept of RRSETs (Resource Record Sets) in DNS (Domain Name System) and their role within DNSSEC (Domain Name System Security Extensions). It highlights the importance of being able to verify the validity of resource records, which DNSSEC facilitates. The purpose of DNSSEC is to prevent unauthorized changes by ensuring the authenticity of these records, addressing the limitation that there is currently no way to inherently confirm if resource records are valid without it.
• 04:00 - 06:00: The Role of RRSIG and Zone Signing Key (ZSK) The chapter begins by discussing the concept of Resource RecordSets (RRSETs), which are crucial to DNSSEC validation. Unlike processes that operate on individual records, DNSSEC validates the integrity of sets of records known as RRSETs. The chapter uses the example of the icann.org zone to illustrate how RRSETs function within DNSSEC, highlighting the process and importance of data integrity validation within DNS. This sets the stage for understanding more about the roles of RRSIG and the Zone Signing Key (ZSK) in ensuring secure DNS transactions.
• 06:00 - 09:00: Verification Process in DNSSEC with DNSKEY This chapter explains the importance of the verification process in DNSSEC, particularly focusing on DNSKEY. It describes a scenario where Resource Records, like MX RRSET, can be altered by malicious actors to misguide email delivery. DNSSEC counters this by employing two key features: RRSIG, which involves digital signatures to secure the RRSET using a combination of public and private keys, thus ensuring the authenticity and integrity of the data.
• 09:00 - 11:30: Understanding Key Signing Key (KSK) The chapter discusses the Zone Signing Key (ZSK), emphasizing the importance of keeping its private part offline and secure, as it is sensitive and not stored within the zone. It is crucial to prevent public access to this private key. Additionally, there's a mention of how an RRSIG contains a digital signature of an RRSET.
• 11:30 - 13:30: Trust Chain in DNSSEC The chapter discusses the concept of trust chain in DNSSEC, focusing on the process of signing RRSET. It introduces a hypothetical tool named Digital-Signature-O-Tron-9000, used to emphasize the importance of signing using the private part of the Zone Signing Key (ZSK). The chapter highlights the critical nature of safeguarding this private key as it's integral to generating a trustworthy signature.
• 13:30 - 15:30: Summary of DNSSEC within a Zone The chapter discusses how DNS Security Extensions (DNSSEC) can be utilized within a DNS zone. It explains that DNSSEC-specific records, such as RRSIG (Resource Record Signature), are stored alongside normal DNS records. While regular DNS clients only see the standard records, DNSSEC-enabled clients can view both the regular records and their associated cryptographic signatures. The chapter emphasizes the importance of digital signing and hashing within DNSSEC, noting that any change to a Resource Record Set (RRSET) necessitates the regeneration of its RRSIG to maintain security.

DNS 101 Miniseries - #6 - How DNSSEC Works within a Zone Transcription

• 00:00 - 00:30 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.
• 00:30 - 01:00 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.
• 01:00 - 01:30 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
• 01:30 - 02:00 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.
• 02:00 - 02:30 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
• 02:30 - 03:00 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
• 03:00 - 03:30 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,
• 03:30 - 04:00 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.
• 04:00 - 04:30 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.
• 04:30 - 05:00 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,
• 05:00 - 05:30 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
• 05:30 - 06:00 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,
• 06:00 - 06:30 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.
• 06:30 - 07:00 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.
• 07:00 - 07:30 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
• 07:30 - 08:00 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.
• 08:00 - 08:30 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
• 08:30 - 09:00 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
• 09:00 - 09:30 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.
• 09:30 - 10:00 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,
• 10:00 - 10:30 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
• 10:30 - 11:00 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?
• 11:00 - 11:30 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
• 11:30 - 12:00 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.
• 12:00 - 12:30 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
• 12:30 - 13:00 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,
• 13:00 - 13:30 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.
• 13:30 - 14:00 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
• 14:00 - 14:30 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.
• 14:30 - 15:00 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
• 15:00 - 15:30 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
• 15:30 - 16:00 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.
• 16:00 - 16:30 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.
• 16:30 - 17:00 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.
• 17:00 - 17:30 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,
• 17:30 - 18:00 and when you're ready, I'll look forward to you joining me in the next.