Managing Public Domain Names

The Domain Name System (DNS) is often referred to as 'the address book of the internet'. It turns memorable names that humans can use into the IP addresses that computer systems use to find each other. Every time you ask your computer to access a website, your computer uses DNS to translate the domain name of the site you wish to connect to (like 'ncsc.gov.uk') into the IP address it needs to make the connection (like 52.222.171.39).

An organisation’s public domain names provide the means to contact that organisation and access any of its publicly accessible digital services. These domains are registered via registrars and then the records within a domain are managed on a service provider’s infrastructure (or an organisation’s public DNS servers). 

What is the risk?

DNS services are increasingly being targeted by a range of attackers. Loss of service to your organisation’s public domains can be significant and wide ranging. For example, communications with customers could be disrupted or intercepted, access to services could be impaired, standard and encrypted traffic could be harvested, and transactions could be defrauded. 

• If your organisation has a single public domain name with a service provider (perhaps managed along with a website), then you should focus on the section Securing access to domain management. The most important recommendation is to implement 2-Step Verification (2SV) with the registrar.
• If you work in a larger organisation, perhaps with multiple domains and managing your DNS more actively, then you should review all the sections.

Domains are registered via a registrar. They in turn work with registries to add the domain to the global DNS. For instance, you could register example.com via a registrar and they would work with the registry for ‘com’ to add this to the global DNS. Some organisations may do this as part of setting up a website, others may register many domains associated with different brands.

Choosing a DNS registrar

There are a number of factors to consider when evaluating a DNS registrar.

• Ensure registrars offer 2-Step Verification (2SV) with their management portal and enable this for all administrators. Administrators should also refer to NCSC password guidance when using management portals. 
• Registrars may also be able to offer some form of ‘locking’ for the domain, so that it can't be changed until the lock is removed. This may involve addition cost, so you should assess any 'lock' services available and consider applying them, particularly to high-value domains.
• Ensure you know the registrar's procedure to reclaim a domain (in case it's hijacked) and keep all appropriate registration documentation to help verify your ownership of the domain.

Choosing your DNS hosting

The registrar can host your domain on the public DNS servers it manages, typically allowing you to administer the DNS records via a web portal. This will be the approach taken by many organisations that use the same service provider to host their web site and public DNS. This is the simplest approach.

However, you do not have to use the registrar’s DNS servers. Most registrars will allow you to use your own DNS servers, or a cloud service provider’s DNS. Both approaches can be combined for your DNS hosting i.e. having your domain hosted on both your own servers and a cloud provider’s infrastructure. This provides additional resilience in the event of service outages and any denial of service attacks. These types of set-up will typically be used by organisations with a large number of domains and more complex online services.

If you use your own servers you will have to set up and secure a resilient infrastructure for this purpose (see Managing your own public DNS). Cloud service providers will have their own DNS management interfaces. You can administer DNS records in one environment, for instance your own infrastructure, and use a cloud provider as a DNS secondary service. You could also use two cloud service providers, managing your DNS records on one, with the other as a secondary service, or using a configuration-as-code approach.

User and group access

Ensure that there is more than one trusted person with secure access to manage the domain. If the domain was set up using a personal email account, change this to ensure any interaction with the registrar is via an organisation’s secure systems. The same principle applies if a domain is registered by a web hosting company; ensure that the domain is managed by your organisation (and not the web hosting company) so that you own and secure the domain name that represents your brand.

Within your organisation, identify a single group that will act as an internal registrar to register and manage all public domain names. This will prevent individuals registering domains with different registrars who may not have appropriate security controls in place. It also ensures your organisation’s policies regarding contact information, renewal and payment are followed. 

Set up auto-renewal

Domains should be set to auto-renew as they will have an expiry date, after which administrative access is unavailable and another organisation could register your domain. Do this via a payment method actively maintained by the organisation (and not a personal credit card that will expire). 

Using your own tools or a commercial service, you should monitor critical DNS records for unexpected changes. This can include name server records, the address records associated with name server records, MX records and the DNS records associated with critical services. You should also monitor certificate transparency logs for TLS certificates being issued for your domains; unexpected certificates may be an indication that an attacker has control of DNS associated with the domain. Certificate transparency log access and monitoring services are available, such as crt.sh, and Cert Spotter.

Your domain names could be deny listed because of malware activity or operational reasons. If your name is added to a DNSBL (Domain Name System-based Blackhole), you could still be cached in the system and effectively listed as spam. Monitoring services are available which can alert you if your domain ever appears in a DNSBL, so you can request removal. 

Ensure any available logging is enabled and the logs stored securely so that you can review changes. Consider incorporating these log messages within any Security and Information Event Management (SIEM) framework to alert on changes if the frequency is likely to be low. 

CNAME records

You may delegate domains or use aliases (CNAME records) that refer to domains outside of your organisation. There are risks involved with this, so you should

• ensure that the parties managing these domains meet your security needs
• remove delegations and alias records once these services are no longer used
• register your sub-domains in Web Check (provided you're eligible)

Once expired, the domain name referred to in the delegation or CNAME record may be used for other purposes, or used by a malicious actor to direct traffic to systems under their control. This is described in more detail in the following HackerOne blog. 

If you're managing your organisation's public DNS on your own infrastructure, you should ensure that these systems are managed in accordance with the NCSC's guidance on System Administration Architectures and Protection of Management Interfaces for systems connected to public networks. Since DNS services can be configured and then 'just work', they're often not maintained as well as other infrastructure. You should classify DNS in the same security category as high value targets such as web servers. The NCSC recommend that you:

• Ensure that public DNS systems are included in your organisations processes which track high value, high impact assets.
• Consult appropriate vendor guidelines on hardening operating systems.
• Consider architectural best practises for public DNS, such as using a hidden master server and diverse locations/networks for public servers. For example, the NIST Secure Domain Name System (DNS) Deployment Guide (PDF) contains good security practises, including some applicable to the management of public DNS servers.
• Test your name servers and networking infrastructure for compliance to EDNS(0) standards (to support additional DNS functionality, such as DNSSEC). The DNS flag day site can be used for this, even though the site was created for a specific event. Be aware that any issues highlighted could be within service provider infrastructure or your own network (and not necessarily the DNS server itself).

DNSSEC is a set of extensions for DNS which improves the security of DNS responses by adding cryptographic integrity checking of responses. This helps protect against manipulation of responses in the network and against some types of DNS infrastructure compromise.

In the context of public domain names, there is an increase in management complexity with the adoption of DNSSEC, such as key management and zone signing. There are also DNS services and applications that do not support DNSSEC, such as some DNS based global server load balancer (GSLB) applications and public cloud providers.

Organisations should consider deploying DNSSEC while weighing the associated risks, costs, and benefits associated.