Protective DNS for the private sector

Protective DNS (PDNS) systems prevent malicious domains being visited by devices in your network. To unpack that a little, we’ll first have a look at what DNS does and how it does it.

The Domain Name System (DNS) is often referred to as the address book of the internet. DNS resolvers translate human-readable web addresses like ‘www.ncsc.gov.uk’ into the Internet Protocol addresses, like 198.51.100.63. These four sets of digits tell the requesting browser or web service where to find the domain. The human readable version on its own is not enough.

PDNS works by making your networks use a given DNS resolver, or set of resolvers. These resolvers, run by the PDNS provider, base their responses to queries on a set of policies which determine which queries will be blocked.

Typically, both the domain name requested and the IP address returned from a query will be checked against a deny list and access prevented if the list is matched. Additionally, some PDNS providers will attempt to block visits to websites with programmatically generated domain names, which are used by malware to circumvent deny lists.

Blocked by PDNS

PDNS prevents access to a range of malicious sites. For example:

• domains distributing malware
• command and control (C2) domains used to control malware
• domains used in phishing attacks, including those used for fraud

Preventing access to these domains should protect your organisation against malicious actors, making it harder for them to compromise your networks, and harder to exploit any compromises.

A secondary benefit of PDNS is the ability to analyse, and potentially be alerted to, DNS requests made to blocked domains. This should be incorporated into a Security Information and Event Management (SIEM) model, allowing you to effectively investigate incidents.

As an integral part of this monitoring process, organisations should have DNS logging in place. To help small and medium sized organisations here, the NCSC has developed Logging Made Easy. This is an open-source project to help organisations set up basic security logging.

Services should be sourced from trusted providers with proven knowledge and experience in the area of cyber security and DNS.

Providers should be able to demonstrate their ability to understand and protect against threats that can be blocked by PDNS and should demonstrate a willingness to keep their knowledge and capabilities up to date.

Providers should be able to give assurances that their deny lists and policies are regularly updated with information from threat intelligence feeds. Technologies and capability, including these threat intelligence feeds, should be regularly evaluated to make sure they continue to be effective.

CISA and the NSA in the US have published guidance on selecting a PDNS service, which compares the capabilities of different providers.

Interfaces and insights

A good PDNS system provides another perspective on your network activity by analysing the security of DNS traffic. PDNS providers will typically give you a web interface for administration of PDNS and present an overview of this analysis.

From high-level graphs to actionable intelligence, these additional insights can often highlight errors, misconfigurations, vulnerabilities and compromises in your network which may not be as obvious from other views of data.

These summary views, along with the corresponding API data, are both uniquely valuable as additional layers to a layered security model.

The details these interfaces provide may vary by provider, just as your needs may vary depending on the size of your organisation and the needs of your security teams.

Logging and exporting data

PDNS services will typically provide access to logs of blocked DNS requests made from your network via both web interface and APIs.

These logs, when combined with your own DNS logs and other SIEM information, allow you to investigate incidents, identify compromised machines and triage critical incidents.

It's important to consider how easy it would be for your organisation to integrate these logs with existing security systems.

Allow and deny lists

The primary purpose of PDNS is to prevent malicious domains being visited. This is largely achieved through the use of deny lists.

Deny lists are compiled lists that the protective DNS service obtains from a variety of threat intelligence feeds, including free, commercial and government sources. A good PDNS often contains information categorising and describing the threat.

As well as deny lists, your organisation should have the ability to curate allow lists. These are lists of domains that devices will be allowed to visit, even if added to the deny list. This mechanism prevents critical services and infrastructure from becoming inaccessible to your organisation.

Administrators in your organisation should be able to update the allow list to add domains via a user interface.

Blocking

When a device attempts to visit a domain that is denied, the IP address for that domain won't be returned. There are several options for what can be returned instead.

One option is to redirect the device to a 'blocking page' containing information on the protective DNS service and an explanation that the domain has been blocked. This may result in the browser presenting a certificate error. The traffic can alternatively be sent to a sinkhole, ie, a specific server to which traffic is redirected, and a custom response provided there.

Alternatively, the PDNS service may reply with an NXDOMAIN response. This is the response received from a DNS query when there is no record. This will result in the user being shown an error page in most browsers. They won't know the domain has been blocked via the PDNS service.

Protocol extensions

There are several extensions to the DNS protocol that may be used or supported in your organisation. You should ensure providers support any extensions that are used in your organisation, including Domain Name System Security Extensions (DNSSEC) and any DNS encryption protocols in use.

For a simple network, setting up PDNS should be very simple. It involves switching over the DNS resolver used by your networks, to those of the service provider. This will provide an immediate security benefit to your network with very little set-up cost.

Complex networks

Solutions should offer the flexibility to support a range of network architectures, including hybrid systems and any legacy or future network architectures that you intend to deploy. For example, enterprise cloud-based architectures or zero trust architectures. Solutions should also be compatible with existing security products, as well as network and device policies.

More complicated networks may need to be able to configure settings for different networks and users in their organisation. This may result in different blocking policies for different networks, as well as having different responses to blocked domains, such as silently blocking with an NXDOMAIN response or redirecting to a sinkhole.

Supporting roaming and home users

To support roaming and home networks, PDNS services may also offer a lightweight DNS client to be installed on end user devices. This will ensure that these devices always resolve DNS queries through the PDNS resolvers.

Preventing circumvention of PDNS resolvers

It's important to consider how to prevent end users and client applications, such as browsers, from using different DNS resolvers.

This should include configuring firewalls to block outbound DNS requests over port 53 or 853, that don't go via the DNS resolver. You should also ensure that either DNS over HTTPS (DoH) is disabled on client operating systems and operating systems and browsers, or that it's configured to go via the PDNS resolver, and still enables logging to take place.

This should be considered during the general management of end user and remote devices, which may include setting Group Policy Object’s (GPO) for Microsoft systems, configuring mobile device management (MDM), and setting up allow and deny listing for applications.

You should consult your provider to ensure you obtain a solution compatible with your current policies and procedures, while delivering PDNS security.

Security and privacy

A PDNS service will be able to view all DNS queries made by a network. It's important to consider the privacy and security implications here for your network and users. You may wish to consider service providers that offer guarantees about how they use and protect your data. This may not be possible with freely available services.

DNS resolvers can be the target of cyber attacks designed to redirect traffic to incorrect domains. The use of public key certificates by websites reduces the risk from this but you should still carry out due diligence to make sure that the provider has appropriate security to prevent DNS spoofing and DNS hijacking attacks, such as including support for the DNSSEC protocol.

Service level agreement

DNS is a crucial protocol for using the internet, which makes it important that any PDNS provider can offer a resilient service with very good availability.

You should make sure that your organisation has a service level agreement (SLA) with the provider to ensure this, and also that the provider has appropriate failover systems in place.