The NÚKIB (National Cyber and Information Security Agency) has issued a public notice with a protective measure for securing electronic mail. For entities under the ZKB (Cybersecurity Act), the implementation is mandatory, but for others it is recommended. Published on 10/11/2021 on the official notice board, including an FAQ and methodology. There is also a point that all DNS records related to electronic mail must be protected using DNSSEC. And boundary SMTP servers validate records using DNSSEC.
What is DNSSEC
Documentation
The article contains various links to RFC documents and special descriptions. Here are some more general information:
- CZ.NIC DNSSEC
- CZ.NIC About DNSSEC
- CZ.NIC How to Implement DNSSEC
- Root.cz Series: DNSSEC and Secure DNS
- Microsoft Windows Server Overview of DNSSEC
There are also various online tools:
- Visual analysis of the DNSSEC authentication chain
- VeriSign labs DNSSEC Analyzer
- Zonemaster DNS (DNSSEC) test
- CZ.NIC Open DNSSEC Validating Resolvers
- Dig web interface
- MXToolBox SuperTool
Briefly, how DNSSEC works
DNSSEC is an extension of the Domain Name System (DNS) specified in a series of IETF RFCs (the primary ones are RFC4033, RFC4034 and RFC4035, supplemented by a number of others, such as RFC6781). It uses asymmetric cryptography, which works with a public and private key (key pair), for digital signing of data. Some general information about cryptography is provided in the article A general introduction to data encryption.
Very simplified, the domain owner generates a key pair. The private key is used to sign data (records) in the domain (zone). The public key is used to verify the signatures, and is published in a special record (DNSKEY
) in the domain. To establish trust, its hash is published (DS
record) for the domain at the parent authority (e.g., CZ.NIC). If it cannot be published, it must be set as a Trust Anchor (fixed points of trust) on all Resolvers that are to verify the domain.
The goal is to obtain certainty that the returned record comes from its owner (authoritative name server) and has not been forged or tampered with along the way (Man-in-the-Middle attacks, DNS cache poisoning and answer forgery, which lead to traffic redirection (hijack traffic) to the attacker's server).
Using DNSSEC, we sign the zone (sign a zone with DNSSEC). This means that all records in the zone (domain) are signed with the private key. The signature is stored in a special DNS record (RRSIG
). The signing is performed (automatically) by the authoritative DNS server (Name Server). Activating DNSSEC does not change the basic operation of DNS queries and responses.
The client, supporting DNSSEC, can perform the verification itself or use a Resolver (typically a DNS server) and trust its responses that the record has been verified. In the DNS query, it receives the requested record and its signature. It first verifies the validity of the key and then the signature using it.
The point is that a certain domain, where we translate a domain name to an IP address (generally search for a specific record), must be signed. On the Internet, only a portion of domains are signed, and even a number of large companies do not use DNSSEC (e.g., www.google.com, www.microsoft.com). The second part is that our client must use DNSSEC verification, and if the signature is not in order, it should not use the address. Domains that are not signed are not verified. In practice, various errors can cause the record verification to fail, so validating clients ignore records that are otherwise correct.
Implementing DNSSEC
Enabling and using DNSSEC can be done on two sides, generally and simplified on the server (signing, in response) or on the client (verification, in the query) (depending on what we want to use, who we are)
- Authoritative Name Server - if we are the administrator of the DNS server where a certain domain (zone) is located, we sign the zone so that our records can be verified; we are the provider of data from the domain
- Client (Recursive Name Server) - if we are the administrator in a company or a user, we want to verify DNS responses if they are signed (DNSSEC validation), we must activate DNSSEC verification on clients, or also set up verification on the Recursive Name Server
For DNSSEC to work in practice, it must be used on both sides.
When we want to implement DNSSEC on a domain, i.e., sign our zone, there may be two practical variants (at least that's how I see it, most documentation focuses only on the first one, or the second one).
- public domain on the Internet - it belongs to the namespace of the Internet, which begins with the root zone (.), trust is handled within the DNS tree
- private or internal (non-public) domain - we operate a separate namespace (Private DNS zone) on internal DNS servers, we must use a Trust Anchor
DNS query with DNSSEC
When we send a query for a record in a signed zone, we set the EDNS DNSSEC OK (DO) bit. The DNS server then adds additional DNSSEC records to the response (they may be longer than the standard DNS message size, which is why EDNS is also required). In simple terms, when we ask for a Host Address, we get the A record and also the RRSIG record.
DNSSEC validation on the client
For testing (performing) DNSSEC queries, we can use the Linux tool dig
(use +dnssec
in the query). If we're working in Windows, we can use an online version, for example, the Dig web interface. To search for some DNSSEC record types, we can use the MXToolBox SuperTool. We can also use the PowerShell cmdlet Resolve-DnsName
(with the -DnssecOk
switch).
If we want to use DNSSEC validation in Windows, we have two options. We can use a web browser plugin that performs the validation itself and displays the result in the browser. The second option is to use a validating DNS Server (Security-Aware Recursive Name Server) and set it to not return the result (return SERVFAIL) if the verification fails (generally, to perform the verification). To set this up, we must use the Name Resolution Policy Table (NRPT), which is configured using Group Policy.
CZ.NIC describes certain options in the Open DNSSEC Validating Resolvers.
Standard DNS lookup process from the client
A simplified description of how the DNS query and response process with DNSSEC works. We assume that the client is a Non-Validating Security-Aware Stub Resolver. For the query, it uses a (Validating) Security-Aware Recursive Name Server (its DNS server). No data is cached and all zones are signed using DNSSEC. In simpler terms, everyone in the example supports and uses DNSSEC, and the DNS server performs the signature verification.
- The Stub Resolver (DNS client) sends a DNS query to its DNS Server (Security-Aware Recursive Name Server), setting the DO bit to 1 in the query
- The Recursive DNS Server sends the query to the Root and TLD DNS servers, sets the DO bit, and obtains the address of the Authoritative DNS server for the zone
- The authoritative DNS server for the parent zone indicates that the child zone is signed, and sends the DS record
- The recursive DNS server sends a query to the authoritative DNS server, sets the DO bit (and possibly also the CD bit, as it will perform the validation itself), and in the response receives the data of the requested record along with the RRSIG record (the signature)
- The recursive DNS server returns the response to the DNS client and provides the record data
- If the zone is signed and the recursive DNS server verified the returned records, it sets the AD bit in the response
- If the verification failed, it returns the
SERVFAIL
error - If we want to get a response even if the verification failed, we set the CD bit in the query
- If the DNS server is not validating, it does not set the AD bit (nor does it perform the verification) and returns the response with the data (if it supports DNSSEC, including the RRSIG record)
Note: Microsoft states that if the client asks directly the authoritative DNS server (i.e., its DNS server manages the zone that the query is for), the server will set the AA bit (Authoritative Answer) in the response. It no longer performs verification and does not set the AD bit, as it would be redundant for it to verify its own answer. The client accepts such a response.
Cryptographic algorithms
Since the basis of DNSSEC is asymmetric cryptography, the choice of algorithms is important. The list can be found in the appendix of RFC4034, but we are likely more interested in the newer SHA-2 and elliptic curve algorithms defined in other RFC5702, RFC6605, RFC8624. Elliptic curves (ECDSA) have several advantages over RSA, such as smaller size and faster signing (but slower signature verification). The algorithms are denoted by numbers, for example:
- 8 is RSASHA256
- 13 is ECDSAP256SHA256
- 14 is ECDSAP384SHA384
- 15 is ED25519
- 16 is ED448
DNS (Domain Name System)
There are several terms around DNS, some more important (necessary for DNSSEC) that we will briefly describe. The terminology and descriptions differ slightly from what is in the RFCs (e.g., RFC1034) and what is described by Microsoft. I described the basics of DNS in a very old article DNS (Domain Name System) focused on Microsoft.
Recursive and non-recursive query
A DNS query can be:
- non-recursive (Non-Recursive Query) - the server responds only with local information
- recursive (Recursive Query) - the server performs a series of queries (traversing the DNS tree) to obtain the target information (theoretically passing through the root DNS and TLD DNS up to the authoritative DNS), it can use caching and respond with data in memory
A slightly more specialized option is the use of iteration (the server returns a reference to another DNS server) or forwarding.
Name Server vs. Resolver
The basic components of DNS (or the roles of a DNS server) are:
- Name Server - often referred to as a DNS server, it is a server that stores the complete records for a domain, responds to queries for its zone (a subset of the domain space), can cache the structure of any part of the domain tree, in simple terms, the Name Server provides DNS records
- Resolver - a program that obtains information from the Name Server in response to a client's query, must have access to at least one name server and uses the information to directly respond to the query or perform a query using references to other name servers, in simple terms, the Resolver queries (looks up) DNS records, Microsoft also uses the term DNS server
A DNS server in a company often serves as both a Name Server (Authoritative Name Server) and a Resolver (Recursive Name Server). It hosts one or more domains and is also used by clients to translate addresses on the Internet. If a query comes for a domain that the server manages, it responds with local data. If it has a valid record in the cache, it uses that. In other cases, it performs recursive queries (typically starting with Root Hints) and finds the answer.
Note: The last of the main components of DNS is the Domain Name Space and the Resource Record.
Stub Resolver vs. Recursive Resolver
A Resolver can be:
- Stub Resolver - a minimal DNS Resolver that uses the recursive query mode, sends a single recursive query to a Recursive Name Server, which performs the entire lookup and returns the result, the operating system (like Microsoft Windows) usually uses a Stub Resolver (DNS Client)
- Recursive Resolver - performs a set of queries traversing the DNS tree to obtain the answer to a query (from the authoritative DNS), if it is publicly available on the internet (Open Recursive Resolver), it can be a security risk and can be abused for attacks
Name Server (DNS Server)
A Name Server can be of several types (depending on the perspective, the first two variants can be classified as Authoritative Name Server):
- Root Name Server - 13 basic root name servers that serve the DNS Root Zone (
.
), their addresses are entered into Root Hints, Root Servers - TLD Name Server - the name server for top-level domains (Top Level Domain - TLD), such as
.cz
and.com
- Authoritative Name Server - a trusted name server responsible for a given lower (second) level zone (domain), manages and holds the records, e.g.,
company.cz
, responds to queries for its zone (using its own Zone File), we usually have multiple servers for a domain, one is primary (where records are edited, also performs DNSSEC signing) and others are secondary (information is replicated from the primary via Zone Transfer) - Non-Authoritative Name Server (more often referred to as a Recursive Name Server, or Caching Name Server) - a server that is a Recursive Resolver, responds to a client's recursive DNS query either with a found record (which it looks up on name servers) or with an error (not found)
Security-Aware client or server
When working with DNSSEC, the Resolver and Name Server acquire additional properties:
- Security-Aware or DNSSEC-Aware - understands (can work with) the DNS security extension (DNSSEC)
- Validating - performs signature verification (DNSSEC) itself
- Non-Validating - does not perform verification, but can trust a friendly name server with DNSSEC support that performs the verification
For example, we have a Non-Validating Security-Aware Stub Resolver. That is, a DNS client that trusts a specific Security-Aware Recursive Name Server, which performs the DNS query and DNSSEC verification and safely passes the result to the client. The Authenticated Data (AD) bit is used in the response. The client understands the verification result. The communication with the DNS server must be secured (DNS over TLS) to prevent a Man-in-the-Middle attack.
Or a Validating Security-Aware Stub Resolver, which sends the query in recursive mode, but performs the signature verification itself (does not rely on the response from the Security-Aware Recursive Name Server to which it sends the DNS query).
The DNS client in Windows from Windows 7 and Windows Server 2008 R2 is a Non-Validating Security-Aware Stub Resolver.
DNS Records and New Types for DNSSEC
DNS Resource Record (RR)
The record is described in RFC1034. The domain name identifies a node in the tree structure of the domain name space (Domain Name Space). A DNS record (Resource Record) consists of the domain name and a set of resource information. Its structure is:
- Owner Name - the domain name of the record
- TTL - Time to Live, how long the record can be cached (in seconds)
- Class - identifies the protocol
IN
(Internet system) - Type - the type of record, for example
A
(Host Address),CNAME
(Canonical Name of an Alias),NS
(Authoritative Name Server) - RDATA - data according to the record type, for example for an A record it is the IP address
Resource Record Set (RRset)
DNSSEC always signs a set of records (not an individual record, but the set may contain only one record, which is often the case). A Resource Record Set (RRset) is a group of DNS records in a zone that have the same name and type. For example, we have two A records for the address www.company.com, with two IP addresses where the website is available. We then verify the entire group at once, so we must obtain all the records of the given RRset.
New DNS Record Types for DNSSEC
The records are described in RFC4034, RFC5155, RFC7344. A new type always contains the standard items name, TTL, class and type, and additional data is found in the RDATA part.
RRSIG (Resource Record Signature)
Contains the signature of the record set (Record Set). Items:
- type of signed record
- signature algorithm
- Labels (used for wildcard)
- original TTL (of the signed record)
- validity period (from Inception to Expiration date)
- Key Tag (to identify the DNSKEY record with the public key, described below)
- Signers Name (name of the signing zone where the DNSKEY is)
- the signature itself (Base64 encoded)
DNSKEY (DNS Public Key)
Contains the public key (ZSK or KSK) that is used to verify the signature in the RRSIG records. Items:
- Flags (flags/bits determining the key, bit 7 determines Zone Key, bit 15 Secure Entry Point, standard 256 means ZSK and 257 KSK)
- protocol (fixed value 3)
- public key algorithm
- public key (Base64 encoded)
DS (Delegation Signer)
It refers to the DNSKEY record in the subordinate zone (for example, a DS record in the firma.cz zone refers to DNSKEY in the sub.firma.cz zone, but both records have the same name sub.firma.cz). It contains the hash of the DNSKEY record with the public KSK key. The items are:
- Key Tag (to identify the DNSKEY record with the public key)
- public key algorithm
- hash algorithm (Digest Type)
- hash of the DNSKEY record (digest in hexadecimal)
NSEC (Next Secure Record)
It is used for verification that a particular record does not exist. The records in the zone are sorted in canonical order. An NSEC is created for each record (owner name), which contains information about the next authoritative name in the order. If a query is made for a non-existent record, it will return the NSEC for the next record in the order instead of an empty response. The items are:
- next authoritative domain name
- Type Bit Maps (contains a list of existing record types for the given domain name)
NSEC3 (Next Secure Record Version 3) is a new version that protects against zone walking. The name (owner name) is stored using a hash function. But even this solution is not completely secure.
NSEC3PARAM (Next Secure Record Version 3 Parameters) are used by authoritative DNS servers to determine which NSEC3 record to use in the response.
CDNSKEY and CDS are used for a subordinate zone requiring updating of DS records in the parent zone.
For RRSIG and DS records, the Key Tag is used. It's something like an ID that identifies the used DNSKEY record. It is not a unique identifier. To determine the DNSKEY, a combination of Key Tag, Owner name, and algorithm is used. The Key Tag is not stored in the DNSKEY record, but is calculated in a defined way.
The image below shows an example of two DNSKEY records and one RRSIG (signed using the listed ZSK). Each record is displayed twice (the display is slightly cropped) using different formatting (tools).
Additional DNS Information
Entities Related to the Domain and its Registration
Several entities are involved in relation to DNS and DNSSEC. We need to understand them when we want to sign our own domain.
- registry - the domain name registry is a database that contains information about subdomains, we have a registry for top-level domains (TLDs - Top-Level Domains, for example
.cz
), where information about second-level domains is stored, it contains a list of registered domain names and the identification of their authoritative name servers (Name Servers) - registry operator - for the
.cz
domain, it is the interest group CZ.NIC (NIC - Network Information Center) - registrar - a contractual partner of the registry operator, who registers domain names (communicates with the registry operator, the domain holder communicates with the registrar)
- DNS operator - the name servers for a given domain, can be operated by the registrar, another organization, or the domain holder
- domain name holder - who registered (on whose behalf) the given domain name
EDNS
A prerequisite for using DNSSEC is support for Extension Mechanisms for DNS (EDNS0, RFC2671), a specification for extending the size of DNS parameters.
DNS Flags
DNS messages use Flags (flags / indicators), certain bits in the message. Three new ones were created for DNSSEC:
- Authenticated Data (AD) - in the DNS Message Header, used in the response, set by the Name Server if it has verified all the returned records using DNSSEC
- Checking Disabled (CD) - in the DNS Message Header, used in the query, the response should be sent regardless of whether the validation was successful (normally, the Name Server does not return records where the required verification failed)
- DNSSEC OK (DO) - in the EDNS part of the Opt RR TTL, used in the query, indicates that the Resolver supports DNSSEC and wants to receive DNSSEC data in the response
An older DNS Flag, which is also used with DNSSEC, if AA is set, then no verification is performed and AD is not set:
- Authoritative Answer (AA) - in the DNS Message Header, used in the response, indicates that the responding server is authoritative for the domain name in the query
Working with Signing Keys
Keys and Signing
The zone signs (calculates the hash using a given function and encrypts it with the private key) its authoritative records (more precisely, sets of records) using the private key. For each record in the zone, the signature is stored in the RRSIG record. The corresponding public key is stored in the DNSKEY record in the zone. The DNS Resolver (translator / DNS server) can use the public key to verify the signature of the records in the zone (decrypt the hash and compare it with the calculated one) and thus authenticate the records.
In general, the verified public key (stored in the DNSKEY record) that we use to validate signatures is referred to as the Authentication Key.
DNSSEC works with two key pairs (two types of signing keys, each key has a public and private part):
- Zone Signing Key (ZSK) - the key that signs the zones, used to sign records in the zone (in my domain), is shorter and changed more often
- Key Signing Key (KSK) - the key that signs the keys, used to sign the zone signing key (ZSK), is longer and does not need to be changed as often
Both types of keys (ZSK and KSK) are stored in the zone, each in a separate DNSKEY record. They are typically distinguished by the flags 256 and 257. Multiple versions (ZSK or KSK) of the key may be stored in the zone.
Key Rollover
It is recommended to change the keys regularly, even if they don't have an expiration date (they can be broken and thus the DNSSEC protection is lost). Certain information is contained in RFC 4986. The signatures of individual records in the zone have an expiration date. Before it expires, the records need to be re-signed. We set the validity period (lifetime) of the signature, for example, 7 days. Older information recommends changing the ZSK every 3 months and the KSK every year (but it depends on various circumstances, algorithm, etc.).
We must have the old and new key (and possibly the signature) in parallel for a certain period of time. Because the records (RRSIG and DNSKEY) have a TTL and can be cached for that time. Only when the time expires can we delete the old keys.
We can practically perform key rollover in two ways:
- pre-publishing of keys - add a new key (DNSKEY record), wait for the record to be distributed, re-sign the records with the new private key, wait, delete the old key
- double signature - add a new key (DNSKEY record), sign the zone with both keys (we always have two RRSIG), wait, delete the old key, sign with the new key/remove the old signatures
Pre-publishing of keys can work a little differently. This is how Microsoft DNS does it. Initially, we create two keys, one active (Active key) and one standby (Standby key). When needed, we sign the records with the standby key. We swap the keys and generate a new standby.
Publishing DS Records
We verify the records in the domain using the public key published in the given domain. We therefore need to obtain trust in this key. For this purpose, the DS record in the higher-level zone is used. It is referred to as the Secure Entry Point (SEP), i.e., the secure entry point into the zone (the DS verifying the DNSKEY). SEP is also a bit in the DNSKEY record (indicating the KSK).
The alternating sequence of the DNSKEY and DS record sets forms a chain of signed data, called the Authentication Chain, where each link vouches for the next one.
Note: A solution was created for DNSSEC to be able to be deployed if the parent (TLD) zone does not support it (if the .cz zone was not signed, for example). This is the DLV (Domain Lookaside Validation) registry, where DLV records are created. I don't know if this solution works, discussions indicate that dlv.isc.org ceased to exist.
Simplified descriptions state that we publish the public key with the higher authority (for the .cz
domain, with CZ.NIC). This creates a chain of trust in the DNS hierarchy (a more detailed description is provided below). However, this is not entirely accurate. We store the public ZSK and KSK keys that we use for signatures in our zone (firma.cz
) in the DNSKEY records in this zone. In the parent zone (.cz
), we must create a DS record that contains the identification of our public KSK key and its verification using the DNSKEY record hash (the hash is smaller, so it saves DNS server resources, where there are many zones). This record is again signed with the parent's ZSK key.
We can only store data in the registry for the .cz domain using our registrar. Therefore, key exchange is not a simple process. CZ.NIC provides the following information about publishing the DS record (Publishing DS Records):
In the registry for the CZ domain, DS records are generated automatically from the signature key data. Therefore, you need to create a so-called KEYSET and insert the complete DNSKEY record data from the zone file into it. This KEYSET then needs to be attached to your domain. Do all of this using the registrar system for the domain in question.
Automatic Delegation (Creating DS Records)
I came across an article stating that CZ.NIC supports automatic management of DNSSEC delegation, where we can exchange the key without the need to communicate with the registrar. .CZ domain launches automatic management of DNSSEC keys as the first. I didn't encounter this information in the DNSSEC description on CZ.NIC, but I found Automated keyset management using Google. (Do you also find the documentation on CZ.NIC so terribly confusing and not very high-quality?)
In the description, we learn that it's possible to use a special type of DNS record called CDNSKEY. CZ.NIC scans domains every day looking for this record. However, there's a problem with which DNS servers support CDNSKEY. The DNS Server role on Windows Server doesn't support this record.
Trust Anchor
Trust Anchor is the starting point for creating an authentication chain for a signed DNS response, which is used by the Validating Resolver. It's a configured DNSKEY or DS record, i.e., a public key or hash. The Validating Resolver must obtain the initial values of the Trust Anchor through some secure channel outside the DNS protocol. The presence of a Trust Anchor also means that the zone it points to is signed.
DNSSEC trust on the Internet begins with the signed root zone, and thus (theoretically) only one Trust Anchor is needed, which is referred to as the Root Trust Anchor. This is the Root KSK, which must be set in every resolver supporting DNSSEC (Validating DNSSEC-aware Resolvers). The official source is IANA Trust Anchors and Keys.
If we want to verify a zone that is not connected to the authentication chain from the root, or if this chain is interrupted (some link doesn't support DNSSEC, they don't have a signed parent zone), we must manually set their Trust Anchor in the Resolver.
How verification works - setting up trust on the Internet
Trust within our zone
The public Zone Signing Key (ZSK) is stored in the DNSKEY record in the domain, and the private key is used for signing records. Signatures are stored in RRSIG records. If we trust the ZSK, we trust all the records it has signed.
To trust the ZSK, it is signed using the Key Signing Key (KSK). The signature is again stored in the RRSIG record. The public KSK is stored in another DNSKEY record. Both DNSKEY records form a set of records (RRset), which is signed using the private KSK. Using the public KSK, we can therefore verify the public ZSK (and also the KSK itself).
Trust between zones
This is how we created trust within our zone. But we need to trust the entire hierarchical DNS structure. And also trust the KSK, which is self-signed. To establish trust between the Parent Zone and the Child Zone, a DS record is used. A hash for the DNSKEY record containing the public KSK is calculated and stored in the DS record in the parent zone. The DS record is signed with the private ZSK of the parent domain.
Whenever the Resolver is referred to a child zone, the parent zone also provides the DS record. The Resolver thus learns that the child zone has DNSSEC enabled, and verifies the public KSK. This creates a chain of trust. When exchanging the KSK, the DS record in the parent zone must be changed. During the exchange, we must first add a new DS, wait for the TTL period for the original record to expire, and then delete it. Or have two DS records published in advance. If something is done incorrectly, we break our DNS zone (DNSSEC verification).
Trust in the root zone
The trust of the DS record is established by the fact that this record is also signed (has its own RRSIG). We perform verification in the hierarchy upwards (we traverse the chain of trust) until we reach the root zone (Root DNS Zone). It contains authoritative information for queries on Top-Level Domains (TLDs) such as .cz
and .com
.
Signing the public key of the root DNS zone (i.e., creating RRSIG for DNSKEY, where KSK and ZSK of the root zone are) is performed by a public, audited, and secure procedure called Root Signing Ceremony. The private key used is the key to the entire Internet protected by DNSSEC. This is how root DNS Name Servers become a trusted anchor (Root Trust Anchor). Trust is not derived from a parent zone, but thanks to these processes, we trust this data (the data listed on official servers is considered valid). We can securely obtain the Root Trust Anchor from IANA Trust Anchors and Keys.
Chain of Trust
Verification takes place in the DNS hierarchy using a chain of trust, which must not be broken. A brief description with an example:
- We verify records in the domain (like an A record for
www.company.com
) thanks to their signature in the RRSIG record, we use the public ZSK (of the second-level zone) in the DNSKEY record (zonecompany.com
) for verification - We verify the ZSK by the fact that the set of DNSKEY records is signed (RRSIG), we use the public KSK (of the second-level zone) in another DNSKEY record (zone
company.com
) for verification - We verify the KSK using the DS record in the parent zone (zone
.com
), where there is a hash of the public KSK, so we verify the DNSKEY record - The DS record is signed in the RRSIG record (zone
.com
), we verify it using the ZSK (TLD) - We verify the ZSK using the KSK (TLD) in the DNSKEY record (zone
.com
) - We verify the KSK using the DS record in the parent zone (root zone
.
) - The DS record is signed in the RRSIG record (zone
.
), we verify it using the ZSK (.
) - We verify the ZSK using the KSK (
.
) in the DNSKEY record (zone.
) - We consider the KSK trustworthy (Root DNS Trust Anchor)
There are no comments yet.