About DNSSEC 

 
What is DNSSEC?


The Internet Domain Name System (DNS) is a set of hierarchical and distributed databases containing basically IP addresses and their corresponding domain names. Each domain name is mapped to a particular numeric address. DNS, with servers located all over the Internet, performs the translation back and forth between names and numbers. This scheme enables users to invoke an easy-to-remember name (e.g. www.nic.sa) instead of a more mysterious string of numbers (e.g. 86.111.195.4) when using the Internet.


The Domain Name System is considered as a critical internet infrastructure service. However, it does not offer any form of security measure. It is vulnerable to a number of attacks such as spoofing, man-in-the-middle and cache poisoning.


Thus, the initial design and use of the Domain Name System (DNS) did not incorporate security measures at all. When it was invented and implemented there was no consideration whatsoever to assume that anyone would try and spoof DNS information (as most usage at that time were for research and academic purposes). Therefore, a DNS resolver was designed so that it would accept the first response it received for a request it generates. As phishing and spoofing nowadays has become the dark side of the internet, existing DNS needs to incorporate an additional layer for security measures.


DNSSEC (DNS Security Extensions) protocol adds this additional layer of security measures at the same time maintaining backwards compatibility. It was designed to protect DNS resolvers (clients) from faked and manipulated DNS data ( e.g., DNS cache poisoning) through a set of extensions to DNS that provides DNS resolvers the ability to verify that:


    

  • the received response was actually sent by the replying server (i.e., eliminating the possibility of man in the middle attacks); and
    • 

  • the identity of responding server is really what they claim to be.
    • 



Answers from DNSSEC are digitally signed. which allow a DNS resolver to validate if the received information is identical (i.e., complete and has not been tampered) to the information on the authoritative DNS server.


In short and in simple words, an authoritative DNS server instead of responding only with the required piece of information pertaining to any inquiry, it will also attach a digital signature to that information so as to enable the resolver to validate the received information and its source. This is achieved by using public-key cryptography, so that the authoritative DNS server uses a pair of interconnected (private and public) keys. The private key is used to generate signatures, and the public key is used by resolvers to verify the authenticity of the signature and therefore the validity of the information.




What are some of the benefits of DNSSEC?


Securing DNS is essential to Internet infrastructure. As DNSSEC was designed to protect DNS resolvers, it’s complete benefits will not be achieved until it is adopted by everyone (DNS resolvers) in order to limit some DNS attacks particularly “man-in-the-middle”.


In principle, DNS spoofing cause no risk to entities with DNSSEC-aware resolvers as they can detect and then discard spoofed data. However, entities without DNSSEC-aware will not see the benefits (protection) of the DNSSEC deployed by others. The more domain names that are using DNSSEC, the more websites and email addresses will be protected on the Internet.


So, DNSSEC major benefits are:


    

  • providing a mechanism to verify the source of information, and its validity.
    • 

  • validating the existence or nonexistence of information.
    • 

  • DNS security protection of known attacks, e.g., man in the middle attack or cache poisoning.
    • 



Note that DNSSEC does not provide confidentiality of data. Also, DNSSEC does not protect against DoS attacks.




How does DNSSEC work?


Basically, a DNSSEC on an authoritative DNS server, uses public-key cryptography to digitally sign DNS records with. DNSSEC depends not only on the zone being signed, but also on local resolvers being enabled for DNSSEC validation.


Before a zone is signed, the creator of the zone generates the public-key encryption key-pairs (private and public keys). The private key is used to digitally sign DNS records, and it can only be decrypted and verified by the public key. The public key is listed in the zone file under the DNSKEY record. The private key is stored securely by the zone creator. The indication that the zone has been signed is recorded at the parent zone file under the DS record.


Every time a zone is created or updated, each resource record (A, AAAA, MX, Cname, etc…) is digitally signed with a new type of resource record called an RRSIG. The RRSIG is created by making a hash (or digest) of a resource record, and then encrypting that hash with the domain private key. The RRSIG is sent along with the response to any DNS query. As soon as the resolving server receives the response and RRSIG, it sends a query request for the public key (DNSKEY) to decrypt the signature. Then, it makes a hash of the received resource record that was requested, and uses the received public key to decrypt the signature. If they (the hashes) match, it means that the signature is valid. Hence, by checking its associated signature, resolvers can verify that a requested DNS record comes from its authoritative name server and wasn’t altered, opposed to a fake record injected in a man-in-the-middle attack.


DNSSEC has introduced a number of new resource records to facilitate signature validation:


    

  1. Resource Record Signature (RRSIG) – Contains a cryptographic signature
    2. 

  2. DNS Public Key (DNSKEY) – Contains a public signing key
    3. 

  3. Delegation Signer (DS) – Contains the hash of a DNSKEY record
    4. 

  4. Next Secure (NSEC / NSEC3) – For explicit denial-of-existence of a DNS record
    5. 



The procedures and relationships involving these new records have been used to form a layer of trust on top of DNS. The following DNSSEC functions and practices will outline how to form the chain of trust.


Before indulging in the details of these procedures, it is assumed that two separate keys (ZSK and KSK) were used.


    

  1. The first pair is used to sign the zone file and called Zone Signing Key (ZSK). It consists of pair of keys: private and public keys.
    2. 

  2. The second pair is used to sign to only the keys and hence is called Key Signing Key (KSK). Also, it consists of pair of keys: private and public keys.
    3. 



It is quite ok in some cases to have only one key used for both signing the zone RRsets and the DNSKEY records. However, it is widely recommended to separate them as it is difficult to update (change) out an old or compromised KSK, while changing ZSK is much easier. This allows the use of smaller ZSKs without compromising the security of the server, minimizing the amount of data that the server has to send with each response.




DNSSEC functions and practices


1) Grouping Resource Records (RRsets)


In DNSSEC, all records with the same type is grouped into a resource record set (RRset). For example, if there are 3 MX records in a zone, they would all be bundled into a single MX RRset. Then, each RRset is digitally signed.

RR Sets

2) Signing the Zone using Zone-Signing Key (ZSK)


DNSSEC uses a zone-signing key (ZSK) pair. The private part is used to digitally signs each RRset in the zone and the results are published as RRSIG records within the same zone. The public part is published in the zone using a DNSKEY record and is used later by resolvers to verify the signature.

ZSK

Once a resolvers send a DNS query requests for a certain record type (e.g., MX), the responding name server also returns the corresponding RRSIG along with the requested record. Then , the resolver will request the DNSKEY record containing the public part of ZSK from the responding name server. Collectively, the RRset, RRSIG, and the public part of ZSK play a part in validating the response.

Resolver

Now, there is a necessity to validate the public part of ZSK (i.e., it has not been compromised) through its RRSIG. This is done by the following step.


3) Singing the keys using Key-Signing Keys (KSK)


Besides ZSK, DNSSEC uses a key-signing key (KSK) pair. Similar to the public part of ZSK, the public part of KSK is published in a DNSKEY record. The KSK is used to validate the DNSKEY records in precisely the same manner as ZSK is used to validate the other RRsets. So, the private part of KSK signs the RRset for the DNSKEY records which stores the public parts of ZSK and KSK, creating an RRSIG for the DNSKEY RRset.

DNSKEY

Now, resolvers will use the public part of KSK to validate the public part of ZSK somehow in the following manner:


    

  • Query the requested RRset, which also returns the corresponding RRSIG record.
    • 

  • Query the DNSKEY RRset holding the public part of ZSK and the public part of KSK, which also returns the RRSIG for the DNSKEY RRset.
    • 

  • Verify the RRSIG of the requested RRset with the public part of ZSK.
    • 

  • Verify the RRSIG of the DNSKEY RRset with the public part of KSK.
    • 


DNSKEY

As it can been seen the public part of KSK is signed by itself. Therefore, again there is a necessity to validate the public part of KSK (i.e., chain the trust of the zone with its parent zone).


4) Set up Trust Anchors using Delegation Signer Records (DS)


To chain the trust from a parent zone to a child zone, DNSSEC uses a delegation signer (DS) record, where the DNSKEY record that holding the public part of KSK is hashed and provided to the parent zone to publish it as a DS record.

Trust Anchor

A parent zone provides a DS record each time it directs a resolver to a child zone. This will inform resolvers that the child zone is DNSSEC-enabled. Afterwards, to validate the child zone’s public part of KSK, the resolver hashes it and compares it to the DS record obtained from the parent. If they match it indicates that the public part of KSK hasn’t been tampered with, which means that all of the records in the child zone can be trusted. This is how a chain of trust is established in DNSSEC.


Be aware of any modification to the KSK also requires an update in the parent zone’s DS record which is considered a heavy process that may lead to inconsistent zone . It may involve initially adding a new DS record at the parent zone, then wait until the TTL for the original DS record to expire before removing it. This is why there are 2 separate keys (ZSK, KSK) so that it would be much easier to swap out ZSKs than KSKs.


5) The Chain of Trust (How do we trust the DS record?)


The DS record is signed in the same manner as any other RRset, which implies that it has a corresponding RRSIG in the parent zone. The whole validation process repeats until we get to the parent’s public part of KSK. To verify that, we need to go to parent’s DS record (i.e. in the zone of the parent of the parent), and on and on we go up the chain of trust until we reach the root DNS Zone.

Trust Anchor

When the root DNS zone is reached, then the public part of root KSK is trusted without the need to check its parent’s DS record as it has no one. This trust comes from ICANN’s security procedures around accessing the private KSK and the root signing ceremony that involves quite a few respected individuals from around the world witnessed signing the root DNSKEY RRset in a very public and highly audited way. They witnessed the publishing of the RRSIG record that can be used to verify the root name server’s public KSK and ZSK.


If any part of the trust chain is broken, then the requested records cannot be trusted because a man-in-the-middle could alter the records and direct us to different internet resources.


6) Expressing Explicit Denial of Existence


A normal DNS returns an empty answer for a non-existence resource query (e.g., if a resolver asks a DNS server for an MX record of a domain name that does not exist, the DNS server will returns with an empty response). The problem: how does a DNSSEC authenticate an empty response? DNSSEC resolves this issue by introducing the NSEC and NSEC3 record types that allow for an authenticated denial of existence.


An NSEC/NSEC3 holds information about the “next secure” record in the zone. For example, consider a name server that defines A records for: “mail”, “secure” and “www” (note that records are sorted alphabetically). If a resolver requests a record for say “online”, the name sever would return an NSEC/NSEC3 record containing “secure”, meaning there’s no A records between “mail” and “secure”. The resolver will understand that “online” doesn’t exist and it can validate that by validating the RRSIG of an NSEC/NSEC3 record.




How to deploy DNSSEC?


Deploying DNSSEC is done in the two main sides:
(a) signing at authoritative DNS servers; and
(b) validation at Resolvers.


Both deployments are essential for the overall DNSSEC implementations. However, they can be independently deployed. This means that DNSSEC validations can be deployed on enterprises or ISPs networks with or without signing the domain names managed and operated by these enterprises or ISPs. Likewise, an enterprise can sign its domain with DNSSEC and publishes it on their authoritative name server without having validation happening on its local network.


Please note, to gain the maximum DNSSEC’s benefits, it is not enough to deploy DNSSEC only in the authoritative DNS servers by domain name holders. But, it is essential to also deploy it in all or major DNS resolvers distributed globally.


a) Deploying DNSSEC at the Authoritative Side:


The purpose to deploy DNSSEC at the Authoritative side is to sign the domain zone. This involves generating cryptographic signatures (RRSIGs) and adding additional records (eg. DNSKEY, NSEC3) into the “zone file” that are used by DNSSEC-enabled resolvers to validate authoritative server’s responses.


The implementation of DNSSEC at the authoritative side involves performing some (high-level) functions and providing some components. Please note, they are somehow intense particularly at the initial phase of implementation. However, there are a number of tools to perform these procedures and to automate them as well. This will make the task for zone signing and resigning (every time its content changes and when the signing keys expire) more manageable and controllable. Examples of such tools are OpenDNSSEC and latest versions of BIND (Ver. 9.7 and newer)
The following list represents some of the essential elements and functions that are needed when deploying DNSSEC at the authoritative side:


1. Signer


In common implementations, a signing system (signer) has no external public interfaces visible to the Internet and is virtually inserted between the zone builder device and the public name server. As a result, the zone builder performs a zone transfer to the signer using, perhaps, an AXFR/IXRF or even SSH/SCP. The signer then signs the zone file and performs a zone transfer of the signed zone file to a public name server in the same manner.


If the zone builder supports DNSSEC signing, it can be used for signing as well, which will significantly simplify the deployment architecture. However, it is not recommended at all to implement the signing function using a public name server, as it may expose the private part of the signing keys.


It is highly recommended to have a backup to the signer system to mitigate the risk of compromising the signer due to a hardware/software failure or a security breach. So that, the signing functionality and the private signing keys can be manually migrated to the backup signer within a reasonable time. A faulty signer will not directly affected accessing the zone file, but will prevent zone updates and hence DNSSEC signatures will eventually expire if the signer is not back life within certain period of time. Here it come the important of choosing the “right” signing parameters that can impact how significant the availability of the signer is (see the section below about choosing signing parameters).


There are software that will aid in performing these functions, e.g., OpenDNSSEC and latest versions BIND.


2. Generation and Management of Signing Keys


Generating and managing signing keys (ZSK and KSK) are considered the core of a reliable DNSSEC implementation. Therefore, specific care should be given to ensure that:


    

  • 

    there is sufficient randomness in generating the Keys. Randomness can be increased by using an external random number generator. For example, they are available as USB memory sticks, or as part of the latest processors (e.g. RdRand).
    

    • 

  • 

    the private part of signing keys are stored and protected from any unauthorized access.
    

    • 

  • 

    the private part of keys are always encrypted during storage. Keys can also be stored on a separate HSM (Hardware Security Module) device. However, these are usually quite expensive, require some degree of special expertise, and not necessary for enterprise zones.
    

    • 

  • 

    there are backup copies of signing keys and should not be stored in plain text format.
    

    • 

  • 

    the selected encryption algorithm is secure and well supported. e.g., the RSA algorithm (as of writing date) appears be the right choice with 2,048 bits is the recommended length for RSA keys. It is wise to ensure that the signing system is capable of supporting elliptical curve algorithms (ECDSA), which may become future trends.
    

    • 

  • 

    a strong digest algorithm is being used, e.g., SHA-256.
    

    • 

  • 

    to use two different key pairs: A Key Signing Key (KSK) used to sign only zone keys (the DNSKEY RRset), and a Zone Signing Key (ZSK) used to sign all the zone. This will allow for rolling ZSK keys without touching the parent zone. It is a good practice to leave the rollover of ZSK keys (2 or 4 time per year) to the signer. Rolling KSK keys requires interaction with the parent zone. There are 2 tactics:
    

    • 



    

  1. Rolling KSK keys only when the signing system/algorithm is renewed (that requires the use a stronger key, for example, 4,096 bits);
    2. 

  2. Rolling KSK keys should be practiced regularly (interval of 1–2 years).
    3. 



3. Choosing Signing Parameters
RFC 6781 and RFC 7583 provide a set of helpful recommendations for choosing DNSSEC signing and timing parameters. Here are some thoughts when choosing the parameters:


    

  • The most important motivation of choosing timing parameters is to guarantee that DNSSEC/DNS administrators have enough time to detect and fix problems before the zone’s signatures start to expire taking weekends and holidays into considerations. For example, a typical setting has a validity period for signatures 14 days and a signature renewal interval as 10 days. So, this gives 10 days to discover and fix a fault.
    • 

  • Regular signing keeps the zone’s signatures refreshed.
    • 

  • The zone’s SOA expiry time should be set to a value that is an order of magnitude lower than the validity period of zone signatures. This is done to allow the zone expires from an authoritative name server than to return expired signatures. So that in case a zone expires, the authoritative name server returns a SERVFAIL response to the resolver, and the resolver should query another authoritative server. However, if a zone does not expire before the signatures expire, the authoritative server returns an expired signature to the resolver. The validating resolver then naturally interprets this as incorrect and returns a SERVFAIL response to the original requester
    • 

  • It is recommended (for large zones) to use hashed NSEC3 records instead of NSEC records to prevent discovering the entire contents of a zones.
    • 



4. Publishing DS records


To create the chain of trust for a zone, the DS record corresponding to the zone’s KSK key must be published in the parent zone and signed using the parent zone’s (ZSK) key.


5. Monitoring


It is very important to monitor DNSSEC signed zones. Here is a list of items that should be monitored:


    

  • Check if the zone can be DNSSEC validated, i.e., by using a resolver/system that checks some domains and make sure that the AD (Authenticated Data) bit is set in the responses (e.g., Nagios).
    • 

  • Remaining validity of signatures. It should look like a zigzag diagram, i.e., it becomes smaller as it reaches the signature refresh value (e.g., 10 days) and bigger as it reaches the defined validity period (e.g., 14 days) once the signature is renewed.
    • 

  • The zone’s last update: a signed zone should be updated on a regular basis, to ensure that its signatures do not expire (check serial number value in the SOA resource record).
    • 

  • Zone transfers between the signer and the public name server (or between a public master server and its slave servers).
    • 

  • After signing the zone and before updating it to the public name servers, it is essential to do self-validation by checking signed zone’s records are validated against the zone’s own keys and that the zone’s keys are signed using a KSK key for which a corresponding DS record is found in the parent zone.
    • 



b) Deploying DNSSEC at the Resolver side:


The purpose to deploy DNSSEC at the resolver side is to validate received responses. This involves validating DNSSEC signatures and verifying the “chain of trust” from the root DNS all the way down to the domain in question to ensure that the information has not been altered.


Deploying DNSSEC at the resolver can be broken down into the following high-level steps:


1. Preparing Requirements


This involves selecting the proper version of DNS software that support DNSSEC validation, e.g., Bind (Ver. 9.7.5 or later) and Unbound (Ver. 1.4.16 or later). Due to public key cryptography, DNSSEC is considered computationally intensive. So it requires CPU power that is an above average to run smoothly. Latest server hardware (not older than 5-7 years) is sufficiently powerful to operate a DNSSEC validating name server.DNSSEC records significantly increase the size of DNS responses which may not fit in the 512-byte UDP packets. Hence, the network infrastructure and firewalls need to be checked and tuned to support DNSSEC large responses on UDP and TCP( Which also known as EDNS0).


2. Obtaining and Validating Trust Anchor


Validating DNSSEC resolvers must be configured with a ‘trust anchor’ to play as the top point in the trust chain. It is thus very important to check the validity and integrity of the root trust anchor before configuring a resolver. First, obtain a copy of the root zone trust anchor from IANA’s website. Make ensure that the trust anchor information obtained over a secured link (i.e., HTTPS). Also, make sure that the trust anchor taken from IANA’s website corresponds to the root zone’s public key found in the name service. Its authenticity should be verified using some other mechanism, for example, the PGP web of trust.


3. Keeping time in sync


The DNSSEC has an intense reliance on the system clock of the caching recursive name server. The validity of DNSSEC signatures start at an inception time and end at an expiration time. Thus, the resolver may handle signature data incorrectly in case the resolver’s clock is of out of sync. Therefore, it is wise to external time source such as a Network Time Protocol (NTP).


4. Monitoring


DNSSEC introduces substantial changes and problems to the operation of the domain name service. Therefore, it is critical to monitor the operation of DNSSEC and its components. With regard to DNSSEC validation, at least the following things should be monitored:


    

  • The number of validation errors and names that fail validation should be analyzed when necessary, for example, by increasing the logging verbosity of the name server software.
    • 

  • The availability of resolver statistics (including validation errors) depends on the name server software used. With Unbound, for example, you can dump statistics using the 'unboundcontrol-stats’ command.
    • 

  • It requires careful consideration whether or not validation errors to be logged continuously. Note that continual comprehensive logging can, at worst, load the resolver heavily and thereby open up a new attack vector.
    • 

  • The number of SERVFAIL responses.
    • 

  • The resolvers’ time synchronization status (for example, NTP synchronization).
    • 





SaudiNIC’s Methodology in Adopting DNSSEC


Since its inception, SaudiNIC has been relying on its national staff in R&D and in building systems. This was also its method to adopt DNSSEC where it began by training some of its staff by attending DNSSEC courses and workshops. Additionally, it established a number of relationships with DNSSEC international experts. This enabled SaudiNIC to conduct some studies, develop operational plans, prepare technical and procedural policy documents,  determine requirements, and then execute implementations. It worth to mention that this methodology (relying on a talented national team and using open source software) enabled SaudiNIC to achieve technology localization and attain technical leadership locally and globally in what SaudiNIC is doing, in addition to reducing development and operation cost.Since 2015, CST has started executing a number of internal projects in phases. Where it started with conducting a study in how to adopt DNSSEC in Saudi domains through reviewing some international cases and studying international standards (RFCs). The study concluded by developing a roadmap plan made up of three phases:


    

  • Phase I: Gaining and building local expertise.
    • 

  • Phase II: Prototype and experimental operation.
    • 

  • Phase III: Launching the actual operation.
    • 



Implementation of this plan focused on building local expertise on DNSSEC by performing several tests and technical trials, as well as outreach with international bodies, institutions and companies on ways of activating DNSSEC on their networks. Furthermore, studying challenges and ways to overcome them. Then, drafting policy and procedure documents for DNSSEC implementation. This include reading and understanding specifications and international standards (RFCs), in addition to building a test environment. These led to the signing of all Saudi TLDs (.السعودية, .sa). Here is a list of major achievements:


    

  • Invite operators (e.g., DSPs, ISPs) to experiment signing their domains for gaining experiences dealing with DNSSEC.
    • 

  • Develop web content related to DNSSEC (Arabic and English)
    • 

  • Updating registration systems to incorporate DNSSEC support.
    • 

  • Conduct a DNSSEC Key creation and installation ceremony
    • 

  • Signing the Saudi TLDs (.sa and .السعودية)
    • 





Managing DNSSEC for Saudi domains registered with SaudiNIC


Login to SaudiNIC’s portal and from “My Domain” screen click on “Mange DNSSEC”. A “Steps of managing DNSSEC” screen will appear. The following technical details must be known before filling the DNSSEC form:


    

  • 

    Key tag which represents the identifier number for the key (for more info see RFC4034 Appendix B).
    

    • 

  • 

    Key algorithm which is used to generate the keys. There are many International standards, e.g.:
    

      

    • DSA/SHA-1
      • 

    • RSA/SHA-1
      • 

    • DSA-NSEC3/SHA1
      • 

    • RSA/SHA-256
      • 

    • RSA/SHA-512
      • 

    • GOST R 34.10-2001
      • 

    • ECDSA Curve P-256 with SHA-256
      • 

    • ECDSA Curve P-384 with SHA-384
      • 

    • Ed25519
      • 

    • Ed448
      • 

    

    • 

  • 

    Digest type which represents the name of method to hash the public part of the key, e.g.:
    

      

    • SHA-1
      • 

    • SHA-256
      • 

    

    • 

  • 

    Digest is the actual value of DS-record.
    

    • 





RFCs





Other Resources