DNSSEC Security Protocol in the management of the “.es” domains

DNSSEC Security Protocol in the management of the “.es” domains

29/04/2022
Dominios

Equipment or machines on the Internet are identified through IP addresses or through names that must be unique in order to function correctly. The DNS system (Domain Name System) is responsible for establishing the correspondence between names (www.ejemplo.es) and IP addresses (192.168.2.15). This original procedure did not include security methods, which is why the Internet Corporation for Assigned Names and Numbers (ICANN) has been promoting the massive implementation of a set of extensions over the years, based on an asymmetric encryption known as DNSSEC.

 

To this effect, from Dominios “.es”, the Red.es unit responsible for managing the registration of Internet domain names under the country code corresponding to Spain, has been implementing a series of additional technologies and procedures that improve the quality of the service for some time. One of these added values is the implementation of a DNSSEC Security Protocol in accordance with the guidelines established by the international community Internet Engineering Task Force (IETF) in the document Request for Comments (RFC 6851) entitled “A Framework for DNSSEC Policies and DNSSEC Practice Statements”, which contains a detailed list of technical aspects and considerations.

 

DNSSEC adds integrity and authenticity to the DNS using cryptography. It can therefore be verified that the resolution “domain name → IP address” is legitimate and authorised by the person responsible for the domain name. It can also be verified that it has not been modified along the way.

 

DNSSEC makes use of the same authority and trust relationship in the current DNS hierarchy. “.es” domains must sign .ES and obtain authorisation from the DNS root server.

 

How can data integrity be authenticated and maintained?

 

DNSSEC uses asymmetric public key cryptography to ensure that the authorship of what is signed with one key can be verified with the other. For this reason there is a public key for each domain that is distributed (DS Records) and published using DNS (DNSKEY Record) in the zone of the secured domain. The records are authenticated by checking the digital signatures against the distributed public keys.

 

What are KSK and ZSK keys?

 

Two keys are used to sign the records: KSK (Key Signing Keys) and ZSK (Zone Signing Keys).

 

The KSK key will be “reported” as DS in the parent zone (for “.es” in the root zone). Its function is to sign the zone key (ZSK) with which the rest of the domain records are signed.

 

The ZSK key signs all the records in the zone. Generally, the rotation of this key is higher than that of the KSK, especially because it is not necessary to modify the parent zone when you want to change it. Simply generate a new one and sign it with the KSK, only informing the changes in our DNS zone.

 

From a technical point of view, there is no relevant difference between one key and another. The difference is its use. Through having 2 different keys, changing a ZSK using a KSK is practically automated with DNSSEC tools and does not require changes in the parent zone.

 

What are security extensions?

 

These security extensions add a set of records and modifications to the current DNS protocol including:

 

  • DNSKEY (DNS Public Key): DNS Public Key
  • RRSIG (Resource Record Signature): Digital signature of a record.
  • DS (Delegation Signer): Hash of a DNSKEY
  • NSEC/NSEC3 (Next Secure): Used for denial of existence
  • NSEC3PARAM: NSEC3 configuration parameters

 

In terms of protocol modifications, calls and record requests are included for each DNS query that is made, to enable domain authentication.

 

What is the chain of trust?

 

The chain of trust consists of a series of DNSKEY (Public Keys) and DS (Delegation Signer) records that allows the creation of trust relationships between domains.

 

This enables validation of any domain that is part of this chain with a single public key. To achieve this, the DS record, which is a hash (a function or method for generating keys that almost uniquely represent a document, record or file) generated from a DNSKEY record, is published in the parent domain. For example, the domain miweb.es with its associated key enables us to generate its DS record and publish it in the domain .es and authenticate the domain miweb.es with the public key of the domain .es.

 

As an end user, what do I need to do to protect myself with DNSSEC?

 

To use DNSSEC record validation, you must have equipment compatible with this system and contract the service with a DNS provider that has a recursive DNS server with validation enabled. 

 

What happens if a DNS record is queried and DNSSEC validation fails?

 

When a recursive server with DNSSEC validation enabled receives a manipulated or forged DNS response, the customer who requested the name resolution receives no record but instead a SERVFAIL error code (RCODE) meaning that there has been an issue answering the query.

 

As the owner of a domain, what steps do I have to follow for the domain to use DNSSEC?

 

In order for the domain to be secured with DNSSEC, the available authoritative DNS servers must publish the signed domain.

 

Currently, each holder of a domain name in .ES who wishes to implement DNSSEC must do so in the zones they control, creating a public key. This key must be sent to Dominios “.es” who will then sign this key and create a chain of trust from .ES to the domain name.