Go to content Go to main menu Idź do wersji polskojęzycznej Go to footer

Online safety - recommendations, good practices and common sense

Online safety - recommendations, good practices and common sense

The Domain Name System (DNS) is a hierarchical, distributed naming system for computers, services or any resources connected to the Internet or a private network. That system associates various information with the domain names assigned to each participating entity. Most notably, it translates easy-to-remember domain names into the numerical IP addresses needed to locate computer services and devices around the world. By providing a worldwide, distributed routing service based on keywords, the Domain Name System is an essential part of the functioning of the Internet. A domain name (e.g. "yourdomain.pl") is a string of characters that identifies an area of administrative autonomy, authority or control on the Internet. Domain names are created in accordance with the rules and procedures of the Domain Name System. Each name, registered in the DNS, is a domain name. Domain names are used for a variety of network contexts and application-specific naming and addressing purposes. In general, a domain name represents an Internet Protocol (IP) resource, such as a personal computer used to access the Internet, the server that hosts a website or the website itself, or even any other service transmitted over the Internet.

When DNS was originally designed in the 1980s, its main purpose was to minimise central network administration and make it easier to connect new computers to the Internet. However, not much attention was paid to security at that time. Deficiencies in this area created room for various abuses and attacks, where responses to DNS queries are falsified. In this way, Internet users can be misled, e.g. they can be tricked into revealing confidential, sensitive information such as passwords and credit card numbers. Although every effort has been made to patch the vulnerabilities in the software used to create DNS queries, the underlying problem lies in the functioning of DNS itself.

Engineers at the Internet Engineering Task Force (IETF), the organisation responsible for DNS protocol standards, had long realised that the lack of stronger authentication in DNS was a problem. Work to solve this problem began in the 1990s and resulted in the development of DNS Security Extensions (DNSSEC). DNSSEC strengthens authentication in DNS with digital signatures based on public key cryptography. In DNSSEC, it is not the DNS queries and responses that are cryptographically signed. It is the DNS data that is signed by the owner of that data. Each DNS zone has a public/private key pair. The zone owner uses the zone's private key to sign DNS data in the zone and generate digital signatures on that data. As the name "private key" suggests, this key is kept secret by the zone owner. The zone's public key, on the other hand, is published in the zone itself and can be retrieved by anyone. Any recursive resolver, that looks up data in the zone, also retrieves the zone's public key, which is used to verify the authenticity of the DNS data. In this way, the resolver confirms that the digital signature of the DNS data, it has retrieved, is valid. If this is indeed the case, the DNS data are correct and are returned to the user. If the signature is not validated, the resolver assumes an attack, discards the data and returns an error to the user.1

The European Union Agency for Cybersecurity (ENISA) created a Multi-annual Thematic Programme (MTP1) in 2008 with the ultimate goal of jointly assessing and improving the resilience of public electronic communications in the EU. This programme examined innovative technologies that had the potential to increase the resilience of such communications. DNS Security Extensions (DNSSEC) was identified as a technology that increases the level of trustworthiness and quality of DNS. It complements other technologies, such as Secure Sockets Layer, which secure content delivery by increasing the security of Internet services.2

Since June 2012 the .pl country code domain registry, operated by NASK, allows the .pl domain registrants to secure their domain names with the DNSSEC protocol. Since that time the number of domain names, secured with DNSSEC, has been gradually increasing. A special moment in the history of DNSSEC in the .pl domain name registry was the year 2018, when a significant increase in interest in this service took place as a result of promotional campaigns and educational actions of the .pl domain name registry3, as well as active engagement on the part of registrars in the NASK Partner Programme. The graph (Fig. 1) presents the ratio of registration of the .pl domain names, secured with the DNSSEC protocol, compared to the average value indicated by the ccTLD registries, associated in CENTR (Council of European National Top-Level Domain Registries). In January 2020, NASK was among four entities awarded by nazwa.pl, a registrar of the .pl domain names, for its intensive actions aimed at improving the quality of the Internet. NASK, which acts, among other things, as the registry of the .pl domain, was awarded in the "Security" category in relation to the development and promotion of the DNSSEC protocol, which increases the security of DNS use. Not resting on their laurels, in the pursuit of constant improvement of the service and raising the security level of the .pl domain, in March 2020 already, the .pl domain name registry introduced a change in the method of handling the DNSSEC protocol, which resulted in a nine-fold reduction of the time of signing and validating zones in comparison to the previously used solution.

rysunek1

Fig. 1 Registration ratio of .pl domain names, secured with the DNSSEC protocol, compared to the average of registries associated in CENTR

 

With the development of DNSSEC, DNS may become the basis for other protocols that require secure data storage. New protocols have emerged that are based on DNSSEC and therefore only work in zones that are signed. For example DNS-based Authentication of Named Entities (DANE) allows Transport Layer Security (TLS) keys to be published in zones for applications such as mail transport. DANE provides a way to verify the authenticity of public keys that does not rely on certificate authorities. New methods of adding privacy to DNS queries will also be able to use DANE in the future. In 2018 ICANN (Internet Corporation for Assigned Names and Numbers) changed the trust anchor for the DNS root for the first time. During this process, many lessons were learned about DNSSEC. In consequence, many resolver operators became more aware of DNSSEC and enabled validation, and all interested parties had a better opportunity to see how the entire DNSSEC system works. ICANN hopes that DNSSEC will be increasingly used by both resolver operators and zone owners. This would mean that more users around the world could benefit from a cryptography-based DNSSEC service, ensuring that they receive authentic DNS responses to their queries.

Among the more serious threats to online security are those based on social engineering. Often it is this kind of activities that enable perpetrators to successfully achieve their goals also in the domain name industry. The scammers' scheme, well known to the users of portals assisting in the local sale of goods and services, consisting in reaching out to the victim about the offered item via an external tool - a popular communicator - has been also applied on the domain market. While in the goods and services sales market the aim of the perpetrator's use of an instant messenger is to send a link to a site imitating a portal, where a fake payment panel is located for "payment", in the case of domains such an instant messenger can be used as a tool for authentication by a person impersonating a domain name registrant. Such a fate, according to the editors of KrebsonSecurity, met the registrant of the "e-hawk.net" domain name, in the case of which, on 23 December 2019, the perpetrators managed to deceive the registrar's customer service employee and induce them to transfer the domain name to another registrar by means of a rather mundane, as it may seem, social engineering trick - and without triggering any verification of the real domain name registrant. The perpetrators, contacting the registrar via a mobile messenger application, declared that they are now the rightful "owners" of the domain name and shared a short video showing the registrar's customer panel and a failed attempt to confirm the already initiated transfer of the domain name. The registrar's customer service employee, trying to check if the system was indeed not working properly, approved the transfer, which led to the domain name being transferred to the registrar's reseller. Three days after this incident, the domain name was transferred to a new registrar. It is worth mentioning that the e-hawk.net domain name was secured with the Registrar Lock service, which provides protection of the domain name at the registrar level.

Analysing the actions of the perpetrators, it can be seen that the initial operation of transferring the domain name to the reseller of this registrar was intentional - such a transfer does not result in changing the registrar ID at the domain registry level, and thus it is not related to the domain service transfer procedure performed by the registry. Thanks to this "silent" operation, the perpetrators gained additional time for further actions, without attracting attention of the actual registrant. And it was this additional time, when the scammers' actions remained unnoticed, that allowed them to remove the Registrar Lock and transfer the domain name to an "external" registrar. Without going into further details of this particular case of "domain hijacking", it can be seen that the phenomenon is still present and the social engineering techniques used are taking newer forms, also observed in other areas of today's digital life. In the case described above, on the procedural side, the human factor was certainly at fault - the registrar should not act on the basis of information coming from an unauthorized e-mail address or any other tool not related to the service of a given domain name. What is worth paying special attention to, in terms of security systems in the context of the presented scenario, is the availability of tools ensuring the top level domain protection4. Such a tool is the .pl Registry Lock, service, provided by the .pl domain name registry. Such a precaution, i.e. securing the domain name with the Registry Lock service, was not taken by the registrant of "e-hawk.net". Its application could effectively neutralize any attempts of manipulating the registrar's employee and, as a consequence, prevent from transferring the domain name to another registrar and changing its delegation. In case of active Registry Lock service, the registrar cannot transfer the domain name service, delete the domain name or e.g. change its delegation.5 Such actions require a complex, multi-step authorization to be completed, which is a strong barrier for potential domain "hijackers", leaving little room for the so-called weak link.

Since the implementation of the .pl Registry Lock service in March 2019, we have been actively promoting it among the Internet users and the .pl domain name registrants themselves, both in the form of electronic communication6, as well as within the framework of NASK's participation in international events, such as, e.g. the Secure Conference7 or the Economic Forum8. Spectacular cases, showing scenarios of domain hijacking, were the main topic of many presentations and lectures delivered during industry conferences, e.g. Ecommerce Standard in 20199, as well as on the web portals10 dealing with broadly defined online security. Also in terms of analytical and development works, the .pl domain name registry has its share in shaping the concept of modelling and standardising possible implementations of the Registry Lock service in ccTLD registries associated in CENTR - "Models of registry lock for top-level domain registries".11

Since the introduction of the .pl Registry Lock service, apart from the aforementioned educational activities, the .pl domain name registry, in an attempt to enable the registrars to reach the widest possible number of recipients, has been applying a special pricing policy in the NASK Partner Programme. As part of the current promotional campaign, a significant increase in interest in the .pl Registry Lock service has been observed, resulting in a doubling of the number of domain names secured with the .pl Registry Lock service between October 2021 and March 2022.

In February 2019, John Crain, ICANN's chief security, stability and resilience officer, said that many of the best practices that can make it difficult for attackers to take over domain names or DNS infrastructure have been known for more than a decade. "A lot of this comes down to data hygiene", Crain said. "Large organizations down to mom-and-pop entities are not paying attention to some very basic security practices, like multi-factor authentication. These days, if you have a sub-optimal security stance, you’re going to get owned. That’s the reality today. We’re seeing much more sophisticated adversaries now taking actions on the Internet, and if you’re not doing the basic stuff, they’re going to hit you."

1 Source: ICANN
2 Good Practices Guide for deploying DNSSEC, ENISA, March 2010
3 Details on the registry's activities in the field of education and NASK's publications on DNSSEC are available at https://www.dns.pl/en/DNSSEC
4 the leaflet on .pl Registry Lock (PDF)
5 The scope of protection depends on the Registry Lock service model implemented by a particular registry
6 https://www.dns.pl/newsy/jak_zapobiec_porwaniu_domeny, https://www.dns.pl/newsy/niezabezpieczone_domeny_zagrozenie
7 https://www.dns.pl/newsy/secure2019
8 https://www.dns.pl/en/news/cybersecurity_forum_2019
9 https://www.dns.pl/newsy/Ecommerce_Standard_2019
10 https://www.forbes.pl/biznes/sadzisz-ze-masz-dobrze-zabezpieczona-domene-internetowa-prawdopodobnie-jestes-w/x3e3m6f
11 https://centr.org/library/library/download/9799/6192/41.html

 

button download article