- Oct

2019

Posted by: Juan Vázquez

[Cybersecurity & hacking tools and techniques]

Internet Guardians

The DNS (Domain Name System) is a decentralized naming system for devices connected to the Internet or a private network. Its main function is to translate IP addresses into names that are easy for people to identify and remember.

This system ensures the availability of websites or emails among other systems by mapping domain names with IP addresses. Therefore, the DNS system is a very important part of the Internet and its availability is crucial for the functioning of the Internet as it is currently known.

However, the design of this protocol did not take security into account. Because of this, it is necessary to use a secure protocol such as DNSSEC (Domain Name System Security Extensions)..

Today, Internet security relies on seven physical keys held by 14 people who meet regularly. They are guarded by security measures so that no one endangers the system. Who are these 14 people? Are they always the same? What would happen if someone got these keys?

In this article we will tell you everything you always wanted to know and you never dared to ask about DNSSEC, dealing with the most important aspects related to its technical functioning and architecture, including information on the degree of current implementation of this protocol worldwide.

How does DNS work?

There are currently about 300 million registered domains. The DNS system is hierarchical and three levels of domain can be distinguished within that hierarchy. Assuming that we have the domain www.jtsec.es we can distinguish the following parts:

3º Level Domains. Also known as subdomains, they consist of a portion of the domain name that appears before the second level of the domain name. The best known is "www" but it can also be others like the domain "blogs".
2º Level Domains. It is the part or level that differentiates the domain from the rest, in our specific case would be "jtsec".
Top Level Domain. This level is the highest level within the web organization hierarchy. Usually they are .com or .net but there are some codes reserved for specific regions like .es .uk, .au, etc.

The operation of the system shall be described by the following example:

A user enters a domain of a website, for example www.jtsec.es in their usual browser. The browser firstly sends a message to the network asking for the IP address related to the name entered by the user.
The users computer queries a machine provided by an Internet Service Provider (ISP). This machine has two options: either it has the "answer" stored in its memory or it needs to make the query recursive to other servers of the ISP.
If none of these servers has the stored IP address, they will query other root servers.
These root servers will redirect the query to the top-level domain servers based on the query (in our case, the server in charge of the .es domain).
Each top level domain server has its own set of authorized servers to ask about the second level domain.
Once the root server knows the address of the server that has the information consulted, it informs the ISPs recursive server. It is now when this server contacts the domain server with the desired information and obtains the IP address of the consulted domain.
The next step is to store this information (domain and IP address) in the cache of the ISPs recursive servers in order to improve the response time for the next time a user searches for that domain.
Finally, the recursive server returns the information to the users computer, which in turn provides the web browser with the information necessary for it to know the IP address to which it must make the connection. Subsequently, the user will be able to see the information contained in that domain.

This is the process that must be followed to obtain the IP address associated with a domain name. This usually occurs in just tenths of a second and is transparent to the end user.

DNSSEC operation

As a result of the need to include security measures in DNS due to the vulnerabilities detected in it, the technology of DNS Security Extensions, DNSSEC, arises to protect this part of the Internet infrastructure.

DNSSEC is a technology that has been developed, among other things, to provide protection against such attacks by digital signature of data in order to be sure that they are valid. However, to eliminate this vulnerability from the Internet, this technology must be implemented in each step of the search process, from the root zone to the final domain name. Signing the root (implementing DNSSEC in the root zone) is a necessary step in this overall process. It is important to note that it does not encrypt the data. It only certifies the validity of the address of the site being visited.

This protocol provides mechanisms to verify:

Integrity of the response to demonstrate that it has not been altered from the source.
Authenticity of the response to prove that it comes from the legitimate server.
Authenticity of negative responses to demonstrate the non-existent resources in the area.

Another feature of this secure protocol is to implement a digital signature using a public key scheme at all levels of the DNS hierarchy. This security is based on the maintenance of a chain of trust from the root zone, which is called the trust root. In addition, the resources of the zone are signed and these signatures are incorporated as another record of the DNS response.

DNSSEC architecture

The following diagram shows the basic architecture of the DNSSEC protocol:

The following elements can be differentiated in the above schema:

RRSet(). It is how a set of resources of a specific type is called that has a specific zone. Following the definition of resources made in the DNS protocol, the following resources can be highlighted:

Record A is the address record.
Record MX is the mail exchange record.
Record NS is the name server record.

DNSKEY().This is the public key that the server has to provide to resolvers who ask about a particular resource. Here is signed with the KSK key therefore, the KSK key that is transmitted would be self-signed along with the public ZSK key signed with the own KSK key. An attacker could impersonate us and give us his own self-signed keys. For this, we use the DS as a chain of trust. This record is a public KSK hash.
DS.It is a resource calculated by the daughter zone and transmitted to the DNS of the parent zone that will contain the DS of the daughter zones it contains. In this way, the chain of trust between the servers is transmitted and perpetuated. It should be noted that the chain of trust spreads from the daughter zone to the father zone. Thus, when a request arrives at the parent node, what is needed is to send the resource associated with the daughter zone server and its DS as proof that it is in the chain of trust.
KSK.Key signature key, an authentication key that corresponds to a private key used to sign one or more authentication keys for a given zone. DNSSEC validation does not distinguish between key signature keys and other DNSSEC authentication keys, and it is possible to use a single key as both a key signature key and a zone signature key, although this is not recommended. This key is generated by hardware (HSM module). This module is accessed by the guardians with their corresponding smartcards in the key generation ceremony of the root node.
ZSK.Zone signature key, an authentication key that corresponds to a private key used to sign a zone. Normally, a zone signature key will be part of the same DNSKEY signature key set as the corresponding private key signature key whose corresponding private key signs this DNSKEY signature key set, but the zone signature key is used for a slightly different purpose and may differ from the key signature key in other respects, such as duration of validity. This key is usually generated by software from the KSK key.

Protocol operation

The following points should be taken into account before starting to develop the operation of the DNSSEC protocol:

When referring to the DNS root node, you dont have to think of a single server responding to requests from users all over the world. This root server is replicated all over the world (hundreds of servers), to avoid any kind of latency in the response. The responsibility for operating and managing these nodes is shared among the following organizations/authorities:

It must be taken into account that each hostname is replicated in several locations in the world and, therefore, each of the organizations/authorities included in the mentioned table must take charge of the maintenance of these servers. In Spain, there are about 13 root servers (distributed between Madrid and Barcelona). In addition, IANA provides the following global distribution of root servers (the number of each indicator on the map tells the number of root servers in a given area):<\p>

Following the DNS protocol hierarchy, all other domains are children of the root node. For example, the .com domain is a child node of the root node and is the responsibility of the VeriSign organization. IANA provides the list of domains for which it is responsible along with the contact details of the organization/physical person owning the domain.
When we talk about the node/server to resolve, we must bear in mind that it is the DNS server provided by the ISP so that users who have contracted this ISP have a DNS server to which to make requests. Those requests that do not have in the cache memory this node solve will have to consult them with the corresponding DNS node, following the hierarchy of the DNS protocol.

An example will be explained below in order to understand the changes introduced by the DNSSEC protocol with respect to the DNS protocol. Note that this protocol is designed to coexist with DNS. For this purpose, the "DO - DNSSEC OK" flag is the means by which a server is informed by a recursive server that the latter has DNSSEC capabilities. From this moment on, the authoritative DNS server will provide the server with the resource it has requested, together with the necessary information to validate it.

In the example, the resolver requests the resource www.example.com from the root server (steps (1) and (2)). This server provides the NS record together with the signature of this record with the ZSK private key, the DS trusted record together with its signature from the private key of the ZSK zone key and the DNSKeys together with its signature made with the public KSK key to the resolver server (response in steps (1) and (2)). Remember that the DS registry is a hash of the public KSK key and the signature of this registry is made with the private key of the ZSK zone key, so the resolver must calculate this hash to verify that the chain is still trusted. The purpose of sending this information is to provide the requested information (in this case it would be the NS record, since the authoritative server does not have the information sought by the resolver node and therefore has to indicate which is the next "jump"), the keys with which it signs the information and the DS record to demonstrate that it is a "reliable" node.

The resolver server will perform the verification (section 4.3 Validation) to verify that the root server is trusted and then proceed to perform the query to the authoritative DNS server .com (steps (3) and (4)) which responds with the NS record (from example.com), the DS trust record and DNSKeys keys along with their respective signatures to continue checking the reliability of the authoritative server in question.

Finally, the resolution obtains the information it initially needed and proceeds to contact the server containing the resource www.example.com. This server provides the resource (which is why it asks, in this case, the IP address of the domain www.example.com), the DNSKey keys and their respective signatures to the resolver server (steps (5) and (6)).

Verification

Verification is another important DNSSEC procedure. Each server needs to process the information it has received from a particular authoritative DNS server and verify the integrity of the information received. To do this, the following points need to be verified:

Trusted anchorage (with parent zone). The authenticity of the KSK key will be verified to confirm that it comes from the zones authoritative server.
Zone signature key (ZSK). The authenticity of the ZSK will be verified to confirm that it belongs to the authoritative server of the zone and, in addition, the integrity of the resources served to confirm the guarantee of the chain of trust will be verified.
DNS resource requested. The authenticity of the resource will be verified by means of the verification of the signature of the authoritative server and also the integrity of the resource will be verified to verify that it has not been altered from the origin.

An example of the validation procedure in DNSSEC will be explained below. To begin with, in the root node the procedure appears in the following illustration:

The resolver node must validate the following resources from the root node:

DNSKey “.” (KSK). The public key of the KSK key must be validated in order to confirm the identity of the root server. This is a special case as it is the highest node within the hierarchy. Therefore, this node has the key previously published by the root node in the computer itself, ie, the public part of the KSK key is in the resolver node, in order to have information to compare when you get the different resources from the root node. This key is "updated" by the organizations that are responsible for the root nodes, which proceed to update it once the corresponding key generation ceremony is completed. In short, if the two resources (the key received and the public key KSK that previously had in the team itself) coincide, it can be determined that trust in anchorage has been validated (KSK).
DNSKEY “.” (ZSK). The next step is to validate the public key of the ZSK zone key. To do this you need the previously acquired public key and the signature of the ZSK key itself to apply the validation algorithm (which may vary but normally RSA is used with SHA 256, although it is beginning to be replaced by elliptical curve algorithms) and compare with the ZSK key provided by the root server. If the procedure is successful it can be determined that the ZSK key comes from the root server.
DS “.com”. This is the resource related to the chain of trust and therefore the resolver node must validate it. The public key of the zone (which has just been validated) and the signature of the DS resource are used. Again, if the validation algorithm provides the same value as the resource in question, the validation is considered successful.
NS “.com”. Este es el recurso solicitado en este ejemplo. El proceso de validación es igual que el proceso descrito anteriormente.

The next .com node will provide the node with the following resources to validate:

DNSKey “.com” (KSK). The public key of the KSK key must be validated in order to confirm the identity of the .com server.In this case, we have a hash of the public key that has served us the node of the parent zone and that calculates the resolver node. Next, this information is used to validate the trust chain with the parent node. Therefore, if the two resources coincide, it can be determined that the anchor trust has been validated (KSK).
DNSKEY “.com” (ZSK). The next step is to validate the public key of the ZSK zone key. To do this you need the public key of the .com node and the signature of the ZSK key to then apply the validation algorithm (which may vary but is normally used RSA with SHA 256) and compare with the ZSK key. If the procedure is successful it can be concluded with the confidence of the keys of signature of the zone ".com".
DS “example.com”. This is the resource related to the chain of trust and therefore the resolver node must validate it. The public key of the zone (which has just been validated) and the signature of the DS resource are used. Again, if the validation algorithm provides the same value as the resource in question, the validation is considered successful.
NS “example.com”.This is the resource requested in this example. The validation process is the same as the process described above.

Finally, the resolver node will be "directed" to the last step before obtaining the desired final resource. The procedure is reflected through the validation by the resolver node of the following steps:

DNSKey “example.com” (KSK). The public key of the KSK key must be validated in order to confirm the identity of the example.com server.In this case, we have a hash of the public key that has served us the node of the parent zone and that calculates the resolver node. Next, this information is used to validate the trust chain with the parent node. Therefore, if the two resources coincide, it can be determined that the anchor trust has been validated (KSK).
DNSKEY “example.com” (ZSK). The next step is to validate the public key of the ZSK zone key. To do this you need the public key of the example.com node (recently validated in the previous step) and the signature of the ZSK key for later, apply the validation algorithm (which may vary but is normally used RSA with SHA 256) and compare with the ZSK key. If the procedure is successful it can be concluded with the confidence of the keys of signature of the zone ".com".
A “www.example.com”. This is the resource requested in this example. The validation process is the same as the process described above.

As can be seen, the use of DNSSEC greatly increases the processing compared to a conventional DNS server. Because of this, we try to reduce the impact by using ZKS keys shorter than KSK in exchange for renewing them every three months.

Key rollover process

As a general rule, the process of generating new keys (either KSK or ZSK keys), generally performs a previous deployment of the keys in order to avoid that a server has to sign twice all data in the area. In order to do this, the following steps are followed:

Initial phase: the operation is correct and expected, we have a KSK key and another ZSK.
New password: a new key is introduced into the set of keys available on the server. At this moment no signatures have been generated with this key yet. It is necessary to wait to propagate the information of this new key to the authoritative servers plus the time TTL that lasts the cache with the information of the old key.
New signatures: once the caches are deleted and the information needs to be signed again, the authoritative servers will begin to include the new generated key.
Deletion phase: once the previous process has finished, the old keys will be deleted so that information is not signed with them again. Keep in mind that the process of implementation and dispersion of the keys is similar for both the KSK key and the ZSK. The main difference is the frequency of the process. It is recommended that KSK be renewed once a year and ZSK every 3 months, however, the generation of new KSK keys is usually longer in time (every 7 years).

Explicit denial of existence

This is one of the new features of using DNSSEC. The DNS protocol is not prepared to give a response such as "the requested DNS request does not exist". Due to this, DNSSEC has the problem of validating this type of situation through the key infrastructure it has. DNSSEC therefore corrects this by adding the NSEC and NSEC3 record types. Both allow authentication of the denial of existence.

NSECs operation is to return the following safe record. For example, if a server contains several resources and is prompted for a resource that does not exist, the NSEC record will store the last record and therefore the request will contain information to be signed. The resolver server that receives this information will infer that the response does not exist because the NSEC field is filled.

An associated problem arising from the use of this DNSSEC field is that an infected server could "inventory" all the information contained in an authoritative server using the information appearing in this field. The solution has been to use a new field called NSEC3 which sends the hash of the resources included in this record. Thus, a malicious server would not receive additional information from an "empty" response. This poses another problem: guessing the hash using brute force techniques is not complicated and therefore the use of the NSEC3 field is not completely secure either.

It should not be forgotten that the DNS protocol, in general terms, is not a protocol containing private and confidential information, but it is true that there is some concern with the possibility that an attacker may collect more information than necessary and may carry out a larger attack on a given organization using this information.

Last mile problem

There is a problem related to the implementation of transparent proxy servers for DNS by ISPs. These proxy servers are configured to intercept DNS traffic and redirect it to the corresponding authoritative server. This is a security flaw because it is proof that, within the ISPs network, DNS traffic can be redirected without implementing DNSSEC and that until it reaches the resolver node, there can be no confidence that DNSSEC is being used. The proposal made would also be to use confidentiality during the DNS protocol request/response process. Current solutions are based on encapsulating the DNS packet within the HTTPS and TLS protocol:

DoH (DNS over HTTPS)
DoT (DNS over TLS)

Therefore, in order to provide confidentiality, authenticity and privacy, the use of the combination DNSSEC and DoH/DoT is recommended.

Internet guardians

Considering the importance of this system, demanding security measures are necessary to protect the functioning of DNS and, ultimately, the Internet. To this end, the head of this system, ICAAN (Internet Corporation for Assigned Names and Numbers, which is a non-profit association founded in 1998 whose aim is to ensure that the Internet is secure, stable and interoperable) created a new security system in 2010.

The security measure consists of the use of 14 secret keys that protect the system. These 14 keys are in the hands of 14 people in the world and the aim is to avoid too many guards in the same country. Twice a year they fly from their country of residence to the United States to participate in a curious ceremony held alternately in two venues. Seven do it in Los Angeles, in winter and summer, and seven in Virginia in fall and spring (the two venues are separated by 4250 km in order to ensure that, if it suffers an attack or a disaster, such as an earthquake, the others continue to function).

These 14 people are known as "guardians" although their official name is Trusted Community Representatives (TCR). There are two types of TCRs with different functions:

Crypto Officer.They are in charge of attending each ceremony to be able to access the smartcards that light the HSM module to generate the new zone keys (ZSK keys). In total there are 14 people designated with this role (7 in each of the mentioned venues) and must attend at least 3 people to enable the cryptographic module. Generally, the 7 that must attend a ceremony are consulted to know their availability during a period of 4 days in case there is something unforeseen in the pre-set day of the ceremony and it has to be postponed to the following day.
Recovery Key Share Holder. It is responsible for protecting a portion of a key used to encrypt backups of the HSM module contents. Each person in this role is responsible for maintaining a smartcard (with its corresponding tamper-evident bag) in a safe deposit box of a bank, which is accessible by them. There are 7 people with this designated role and in principle, they should not attend the ceremonies since their purpose is to be able to access the private key information contained in the HSM module at any given time. However, they must be able to attend a ceremony in a relatively short time and must also provide evidence that their Smartcards are intact on an annual basis (it appears that a photo showing that the anti-tamper bag is still intact is sufficient).

The ceremony, which lasts about two and a half hours, aims to generate new area keys from a master key has maximum security measures and transparency, as it is broadcast by streaming. Witnesses, security personnel, computer scientists and at least three of the seven Crypto Officers participate in the ceremony.

Each of the guards must pass a series of checks. They must identify themselves with their passports, retinal scanners and biometric sensors from the palm of their hands. In total, there are seven levels of security until you reach the room where the device that will generate the new root key is located. This key can only be activated with the simultaneous participation of at least 3 guardians. Security levels can be categorized as follows:

Tiers 1-2.Physical access is recorded and only personnel who have permission to enter the building without bodyguard are considered authorized personnel. From this level of security, the access is already with safeguard.
Tiers 3-5.Physical access to the next facility is recorded and videotaped. Access here is already through a double authentication factor (retina scanner and biometric sensors of the palm of the hand). Personnel without a safeguard cannot access this level.
Tiers 6-7.Access here is to the HSM and where the cards are located. These components are located in closed safes, with anti-tampering bags and safe boxes. Access to the locker that holds the cards must be made through a key that has been previously provided to the guardians.

If something goes wrong or someone skips the script, everything comes to a standstill. In extreme cases, the smart cards used to access an HSM device containing a part of a KSK (Key Sign Key) are self-destructed.

An HSM that generates the KSK key and stores the private part of it is stored in both locations. Every three months the master key stored (private KSK) in an HSM is used to sign the zone keys to be used in the following quarter. The goal is to avoid giving hackers time to reveal them through brute force attacks, in which they test billions of combinations. The reason for this problem is related to the fact that ZSK keys are generally shorter in order to facilitate the processing of DNSSEC requests at CPU level. So every three months these keys are changed to avoid that, by brute force, an attacker can remove from the signature, the private key.

As already mentioned, it is necessary for each of the guards to pass the security levels mentioned above until they reach a kind of cage in which a device known as the Hardware Security Module (HSM) is stored. This device has no Internet connection and can only be used once the guards have entered their corresponding smartcards. To control this device is used a laptop without Internet connection, without hard disk or battery to be able to communicate with the HSM module through an Ethernet cable. The Operating System of this equipment is started by DVD and the memory to record the logs generated during the process consists of a USB memory. In addition, when new KSK keys are generated (which, to date, has only been produced once since 2010) it is done in new HSM modules and the information included in the old modules is safely eliminated (by zeorization) and even the replaced devices are destroyed in the same ceremony by a specific machine.

This device, in addition, resists any type of manipulation and in case of intrusion, it automatically erases the keys that it stores. Statistically, according to the ICAAN "the possibility of a conspiracy that could compromise the keys is one in a million, assuming a rate of dishonesty of 5 percent among individuals participating in the ceremony."

As a summary, the following important points of the ceremony can be taken into account:

With the Smart Cards of the Crypto Officers (official name of the guardians) you can access the HSM.
The HSM has the private key of the KSK.
The frequency of generation of new ZSK keys is done on a quarterly basis, the generation of the KSK key has only been done once from 2010 until today.
With this key, new ZSKs are signed for use in the following quarter.
The information generated is then backed up and the HSM is deactivated and saved again.

Finally, the keys (public and private in the case of the ZSK key) are sent to ICANN and VeriSign. They can be sent (in fact, they do so in several meetings) by signed mail or by means of a secure web. In the case of KSK keys, there are some differences due to their importance, which will be discussed in section 4.5.

Safe deposit box

There are two safes in the rooms of each of the venues. One (pictured) contains safes similar to those found in a bank. In these repositories are the smart cards with which the guardians obtain permission to activate the HSM hardware module that will be used to sign the new ZSK zone keys. The other contains the module itself. There are two devices at each site, in case the other one breaks down.

New signatures generated

The new keys (with their corresponding public and private parts of the ZSK key) generated will be transmitted by an ICAAN operator via a secure connection to VeriSign, a U.S. company that manages network infrastructures.

Guardians must enter their keys in order to verify that there has been no manipulation of the master key and then the process of generating ZSK zone key signatures from the master key private key (KSK) begins. To do this, the HSM (which, if dropped or hit too hard, will self-destruct) starts with the generation of the new ZSK zone keys from the private part of the KSK key.

Once the signatures have been generated, a copy of the generated signatures is made and sent to VeriSign and ICANN. This information will be sent through a signed mail or through the use of a secure web. It is necessary to bear in mind that these signatures will begin to have validity from the ceremony that is carried out in the following quarter.

The keys

This image shows two keys: the physical one -the typical metallic one- opens the safe where the intelligent keys (similar to credit cards) placed in anti-tamper bags are deposited. The guards should check that no one has touched the bag before removing their card.

Importance of the process

These security measures are necessary because if the system were compromised, the Internet could cease to be "reliable" as we know it. A potential attacker could perform a worldwide phishing as it could deceive any user and provide different IP addresses to obtain confidential information from each of the users who use the Internet.

Guardians could reboot the system completely in case the integrity of the DNSSEC system is compromised to solve any type of attack of the dimensions being addressed.

It is necessary to be aware of the susceptibility to a Man In The Middle attack, which is the DNS protocol, since an attacker can analyze the DNS traffic and supplant it without a user being able to verify the origin of the responses received. If an attacker intercepts the communications of a recursive DNS, he can redirect them to himself or to another infected server to perform a phishing attack.

First key rotation process

On October 15, 2018, ICANN proceeded to make the first change to the KSK cryptographic key that helps protect the Domain Name System (DNS) which has been completed with minimal disruption to the global Internet as we know it. It was the first time the key has been changed since it was first put into use in 2010.

After evaluating the available data, there does not appear to be a significant number of Internet end users who have been negatively affected by the key change.

There were some problems during the ceremony but these were not major failures in the overall system and therefore did not influence the normal functioning of the Internet (as defined by the ICANN community). In that context, the transfer of the new key signature key, known as KSK 2017, has been a success.

At this point, ICANN will proceed to the next step in the transfer process: the revocation of the former KSK, known as KSK 2010, during the next ceremony to be held in the first quarter of 2019.

Another important point to bear in mind is the way in which the private part of the KSK key is transferred from one location to another. After the generation of the private key and the end of the ceremony, the key is exported encrypted with what is known as SMK (Storage Master Key, according to the technical specifications of the AEP Keyper HSM, which is the HSM model used in ceremonies) on a smartcard and placed in an anti-tamper bag and transported to the other location by a carrier. At the other site, the smartcard is placed in the appropriate safe, checking beforehand that the bag has not been tampered with during the transport process. Once the smartcard containing the private key is stored, the safe is closed and at the next ceremony the key is imported into the corresponding HSM, which must have the same SMK as the HSM device that exported the key and continues with the procedure for generating the new ZSK keys. This SMK key is related to the HSM access key. As previously mentioned, in order to access the HSM device, the collaboration of at least 3 of the guardians is necessary. This is made possible by the M of N feature which allows for a division of the HSM authentication key (with the restriction of requiring at least 3 of those "divisions").

Although it may seem that the transport of the KSK key is unsafe and poses a threat to the implemented system, it must be borne in mind that the deployment of new ZSK keys that are signed with this new KSK key generated, does not take place until the next ceremony. For this reason, if the transported KSK key is tampered with in any way, the DNSSEC security would not be affected as a new KSK key could be generated and the ceremony repeated.

Finally, it should be noted that this process of saving the smartcard in the safe is recorded and recorded in the corresponding log (Script_MediaDeposit_Annotated), so that there is also evidence that the process has been carried out as planned.

Such strict security measures provoke reactions in the community of all kinds, but ICANNs main objective is to demonstrate transparency so that users can trust the stability and security of the DNS service as we know it at all costs. This leads to funny comments such as the following from the @SwiftOnSecurity account

“Fun fact: During key rotation ceremonies, ICANN has a locksmith ready to drill the locks of the safes holding DNSSEC private keys, if for some reason they won’t open”

However, Internet users can be confident that no manipulation is carried out during the process and that all necessary security measures are employed to prevent any type of attack on a global scale.

Spanish representation

The Public Business Entity Red.es, attached to the Ministry of Industry, Tourism and Trade through the Secretary of State for Telecommunications and the Information Society, is legally entrusted with a series of functions with the aim of contributing to the development of telecommunications and the information society in Spain.

Among other functions, Red.es has been assigned the management of the registration of Internet domain names under the country code corresponding to Spain ".es", which includes all the functions related to the processing of applications and assignment of domains in accordance with the corresponding regulations, as well as the performance of the technical functions necessary to guarantee the correct functioning of the system of domains in Spain and in the global Internet network, participating in the international organisms that coordinate the management of the system of domain names.

ESNIC (Network Information Center) is a department of the public business entity Red.es, the competent authority for the management of the Registry of Internet domain names under the country code ".es". It is in charge of the processing of new domains and their assignment among others.

There is no direct relationship between Red.es and ICANN. They are two independent entities that are in charge of maintaining the domains at different levels of the DNS hierarchy. Red.es is in charge of managing the domains at the Spanish level and ICANN is in charge of managing the DNS root node. ICANN has a department in charge of supervising the global assignment of IP addresses, autonomous systems, DNS domain name root servers and other resources related to Internet protocols. This department is what we know as IANA.

In order to get an idea of the operating range of each of these bodies, one must first take into account the existence of two major divisions of top-level domains (TLDs). On the one hand, there are the gTLD domains, which are the generic top level domains (Generic Top Level Domain), among which are .com, .info, .org or .net. This type includes sponsored domains (sTLD sponsored Top Level Domain), which promote specific groups (.cat, .museum, .aero).

gTLD domains must have a minimum of three characters and are not associated with countries. They are managed by international organizations such as ICANN.

The second large group of domains are the ccTLD (country code Top Level Domain) or country code top level domains. These include .es, .ar, .fr, .mx, etc. Their main feature is that they have only two characters and are managed by agencies in each country.

All the types of domains that exist in the world are registered in the IANA and the domain .es, is managed by the public entity Red.es.

It is also necessary to bear in mind that both types of domains hang from the root node, because they are all top-level domains. This dependence is reflected graphically in the following image:

Recent attacks using the DNS protocol

All the security measures used by ICANN demonstrate the concern to protect the DNS system through the use of DNSSEC. This concern is not unfounded, let alone exaggerated. This section will include information on one of the recent (January 2019) DNS hijacking attacks and its impact.

The U.S. government, along with several industry-leading security companies, recently warned of a series of very complex and widespread attacks that allowed suspected Iranian hackers to divert large volumes of email passwords and other confidential data from multiple governments and private companies. This cyber espionage campaign has been referred to by Cisco Talos as DNSpionage.

Talos reported in his investigation that the authors of the DNS espionage were able to steal e-mail accounts and other access credentials from various government and private sector entities in Lebanon and the United Arab Emirates by hijacking DNS servers, so that all e-mail and VPN traffic was redirected to an Internet address controlled by the attackers.

Talos reported that these DNS hijackings also paved the way for attackers to obtain SSL encryption certificates for target domains (e.g., webmail.finance.gov.gov.lb), allowing them to decipher the intercepted email and VPN credentials and view them in plain text.

Among many other domains, it is known that domains related to embassies, finance ministry, Abu Dhabi police service, Jordanian intelligence service, etc. were hijacked. The kidnapping was based on changing the IP address to which the domains were pointing towards the servers controlled by the attackers themselves.

The analysis of the attack showed that the IP to which these domains were redirected was in Germany. But the problem did not end here, since the domains pointing to this IP address were consulted and several that belonged to Sweden were discovered. These Swedish domains were owned by Netnod Internet Echange, a leading global DNS provider based in Sweden and operator of one of 13 root servers (remember, the highest in the DNS hierarchy).

Netnod CEO, Lars Michael Jogbäck, confirmed that parts of Netnods DNS infrastructure were hijacked in late December 2018 and early January 2019, after attackers gained access to accounts at Netnods domain name registrar. It also confirmed that "Netnod was not the final target of the attack. It is considered that the objective has been the theft of data access to Internet services in countries outside Sweden.

The PCH (Packet Clearing House) entity, which manages a significant amount of the worldwide DNS infrastructure (with more than 500 TLDs, several of them spread over Middle Eastern countries) was also a victim of the attackers.

The entitys CEO said hackers forged credentials that the PCH registrar used to send signaling messages known as Extensible Provisioning Protocol (EPP). EPP is a little-known interface that serves as a kind of back-end to the global DNS system, allowing domain registrars to notify regional registries (such as Verisign) about changes in domain registrations, including new domain registrations, modifications and transfers.

Jogbäck acknowledged that Netnods infrastructure suffered three separate attacks from DNSpionage attackers. The first two occurred in a two-week window between December 14, 2018 and January 2, 2019, and were directed at company servers not protected by DNSSEC.

However, the third attack between December 29 and January 2 was directed at Netnods infrastructure that was protected by DNSSEC and served its own internal email network. However, since the attackers already had access to their registrars systems, they were able to briefly disable that protection, or at least long enough to obtain SSL certificates for two of Netnods email servers.

Once the attackers had those certificates, they re-enabled DNSSEC for the companys target servers as they apparently prepared to launch the second stage of the attack, diverting traffic passing through their mail servers to machines controlled by the attackers. But Jogbäck mentioned that for whatever reason, the attackers did not use their unauthorized access to their registrar to disable DNSSEC before attempting to divert Internet traffic.

This was the absent-mindedness that made it possible to detect the attackers and stop the advance of their espionage mission.

On the other hand, PCH did not suffer so much the effects of the attack since its infrastructure is based entirely on DNSSEC. However, there was an incident with two employees who were not using the service, but beyond this there were no major problems.

As PCH had protected its domains with DNSSEC, the effect of the hijacking against its mail infrastructure was that for approximately one hour no one, except the two employees mentioned above, received any e-mail, as the signature of the attackers could not be "verified".

This situation has served both companies as experience in improving their DNSSEC infrastructure and has increased their efforts and resources related to that infrastructure. Many of these improvements are related to the recommendations made by John Crain, ICANNs chief of security, stability and resilience in the aftermath of these attacks:

Use DNSSEC (both to sign zones and to validate responses).
Use registration features such as Registry Lock that help protect domain name registrations from being modified without prior authorization from the registrar.
Use access control lists for applications, Internet traffic, and monitoring.
Use a dual authentication factor and require it to be used by all relevant users and subcontractors.
Where passwords are used, choose unique passwords and consider using password managers.
Review accounts with registrars and other vendors.
Monitor certificates by monitoring, for example, certificate transparency records, the components of which enhance the chain of trust model by providing support for public oversight and scrutiny of the entire SSL certificate system.

In addition, ICANN also proposes the following list of measures to be taken into account for those responsible for managing DNS servers of important domains:

Ensure that all system security patches have been reviewed and applied.
Review log files for unauthorized access to systems, especially administrator access.
Review internal controls over access by users with administrator permissions.
Verify the integrity of each DNS record and the history of changes to those records.
Have a sufficient complexity of passwords, emphasizing their length.
Ensure that passwords are not shared with other users.
Ensure that passwords are never stored or transmitted in plain text.
Have a policy of periodically changing passwords.
Apply a password blocking policy after several failed attempts.
Ensure that zone DNS records are signed by DNSSEC and that resolvers nodes implement DNSSEC validation.
Follow up on ICANNs recommendations from the attacks mentioned in this section.

However, much of the problem experienced by both entities is related to the current low global use of DNSSEC.

Use of DNSSEC today

Unfortunately, the use of DNSSEC is not spreading at the desired speed and currently the number of signed zones is less than 1% as can be seen in the graph below:

A fundamental element for a domain to be able to use DNSSEC is that the domains above it in the hierarchy are. In this case, it should be noted that, at the operational level, the state of implementation of DNSSEC is quite good, as can be seen in the following image:

Bearing this in mind, it would be possible in Spain, for example, to use DNSSEC for any domain since the .es domain and the root domain are implementing it and the chain of trust can therefore be increased.

This last point is basic and at the same time very important because the first step to implement DNSSEC worldwide is to be able to trust all the root nodes that have been deployed in the world. Currently the implementation rate is 91%.

Unfortunately, the state of implementation in Spain is low, as can be seen in the following graph: