DNS: The blind spot in the PCI DSS compliance strategy

The Payment Card Industry Data Security Standard (PCI DSS) defines a series of physical, logical, and administrative controls for the protection of payment card data, with particular emphasis on the Primary Account Number (PAN).

In technical terms, PCI DSS includes explicit references to security controls such as firewalls, web application firewalls (WAF), anti-virus, file integrity monitoring (FIM), intrusion detection/ prevention systems (IDS/IPS), time synchronization services (NTP), event logs, use of secure versions of protocols (such as TLS, for example), etc. However, no specific controls are included in network architecture's critical components: The Domain Name System (DNS). And it is precisely in the DNS service where a "blind spot" in compliance with the standard can be found.

To get into context, the DNS is a distributed and hierarchical database using the client-server model that allows the association of a domain name (known as Fully Qualified Domain Name - FQDN) and other associated data (known as "records") with an IP address. The technical description of the concepts and criteria for implementing and specifying the name resolution system is described in RFC1034 and RFC1035.

In general terms, there are five main elements within a name resolution system:

• Client: Component within a client computer that makes name resolution requests for its operation (browsers, email clients, etc.). 
• DNS resolver (also known as "recursor" or "iterator"): Server in charge of receiving client requests for name resolution. It uses temporary storage of already resolved records (caching) to optimize response times.  
• Root nameserver: Server in charge of providing the name and IP address of the authorized server of the highest-level zone for the searched domain. There are currently 13 servers of this type in the world. 
• TLD (Top Level Domain) nameserver: Server that maintains the information of all the domain names that share a common domain extension, such as .com or .net. There are several types of TLD servers, including generic or gTLD (.com, .net, .edu, .org and .gov) and country or ccTLD (.uk, .co, .jp, .es, etc.). The complete list can be found here. 
• Authoritative nameserver: Server that contains the specific information of the domain it manages (e.g. yahoo.com) and returns the IP address of the specified hostname to the resolving DNS that made the initial request. 

Like many other services that were part of the origins of the Internet, the DNS was developed to be operational and scalable, but security was not part of these initial criteria: there was no authentication, the integrity of responses was not validated and data was transmitted in clear text, deficiencies that began to be exploited by attackers through the following techniques: 

• DNS spoofing/cache poisoning: In this attack, forged DNS data is entered into the resolver's cache, causing the resolver to return an incorrect address for a domain, diverting traffic to a malicious host or any other location the attacker desires, to distribute malware or collect login data. 
• DNS Tunneling: This technique allows the encapsulation of other protocols (such as SSH or HTTP) in DNS requests to avoid restrictions at the level of packet filtering, used for data exfiltration or communication with command and control (C&C) servers. 

• DNS hijacking: Using this technique, the attacker redirects queries to a different domain name server using malware or modifying the DNS server. 
• Reflection/amplification and denial of service attacks: In these attacks, the name resolution infrastructure is used to create malicious traffic that is directed at specific targets or to saturate the operation of the service. Some of the better-known attacks in this category are NXDOMAIN, Phantom, Random subdomain, domain lock-up, botnet-based CPE, etc. 
  

DNS and its relationship with PCI DSS

As noted above, the PCI DSS standard does not include any explicit reference to the use of security controls in the name resolution infrastructure, so during an implementation or formal compliance assessment the following questions may arise that can affect the security of the environment: 

• Can the DNS protocol and its standard port (53/UDP) be considered "secure"? 

• Is it necessary to implement additional security considerations in a traditional name resolution infrastructure? 
• Is the designation of a specific name resolution server within a network that processes, stores and/or transmits payment card data required? 
• How should a connection be made between a client and a DNS server to perform name resolution in a PCI DSS-aligned environment? 
• What criteria should be used when choosing an authoritative name resolution server? 
• Are root and TLD servers at the top of the DNS hierarchy trusted? 

• Should name registration service providers be listed as PCI DSS service providers? 

Currently, many of these questions have no official answer, so it is quite likely that the vast majority of PCI DSS compliant environments have minimal or insufficient controls in place to protect their name resolution infrastructure from attacks.  

In that regard, the following are a series of recommendations to protect DNS services in the payment card environment, complementing the basic requirements of PCI DSS: 

Name Resolution Service (DNS) Architecture

To implement a secure DNS service architecture, the following guidelines are recommended:

• Install at least one dedicated internal server that acts as a DNS resolver for the PCI DSS environment. Depending on the complexity of the network, internal DNS servers can be used by geographic zones, branches, etc.
• The DNS server that performs queries to external DNS servers must be located in the DMZ.
• Outgoing name resolution traffic should be restricted only from the internal network DNS server to higher-level DNS servers on the Internet.
• All systems within the PCI DSS environment must use the internal DNS server for name resolution.
• Only IP address queries to the DNS server should be allowed within the environment. Proceed in the same way with other critical operations (such as zone transfers).
• DNS server queries must be logged, so that they can be used as elements of analysis in an investigation if a security incident occurs.
• Changes to name resolution records should be continuously monitored for unauthorized changes.
• Deploy more than one internal DNS server for load balancing and fault tolerance. DNS is particularly vulnerable to DoS attacks. Avoid connecting all DNS servers to the same segment, switch, or router, as this creates an unnecessary single point of failure.
• When using multiple internal DNS servers, disable zone transfers or limit zone transfers to the IP addresses of the internal DNS servers.

Use of secure name resolution functionality

To replace and/or complement the traditional functionalities of the DNS protocol, it is recommended to use any of the following alternatives and/or secure extensions:

• Domain Name System Security Extensions (DNSSEC): DNSSEC is a set of DNS service extensions described in RFC4033, RFC4034, and RFC4035, which provide cryptographic authentication and integrity validation of DNS data, including backward compatibility with earlier versions. By using DNSSEC, the risk of DNS cache poisoning can be minimized, as DNSSEC server responses are digitally signed, which can detect any attempt to manipulate this data.
• DNSCurve: DNSCurve uses elliptic curve cryptography to encrypt and authenticate DNS packets between the recursive/solver and the Authoritative Nameserver.
• DNSCrypt: DNSCrypt allows authentication between a DNS client and a recursive/solver using strong cryptography.
• Transaction SIGnature (TSIG): Described in RFC2845, TSIG allows authentication of DNS database updates.

DNS Traffic Protection

DNS traffic is traditionally sent in clear text, without any control to protect its confidentiality. Because of this, any attacker could have access to the name resolution traffic, making it easy to capture and manipulate (man-in-the-middle).  

To avoid these problems, it is recommended to make use of the following security features for the protection of DNS traffic: 

• DNS over TLS (DoT): DoT (RFC7858) adds encryption to UDP datagrams used by DNS using Transport Layer Security (TLS). DoT uses port 853. 
• DNS over DTLS (DoD): DoD (RFC8094) allows the encryption of DNS queries and responses through the use of Datagram Transport Layer Security (DTLS). DoD uses port 853, as does DoT. 
• DNS over HTTPS (DoH): DoH (RFC8484) allows DNS queries and responses to be made using the HTTP and HTTP/2 protocols instead of UDP and encrypts traffic using TLS in the same way as it is done with HTTPS. DoH uses port 443. 

Use of secure DNS software

There are multiple alternatives at the software level to implement a DNS server, both commercial and Open Source. However, it is recommended that the chosen solution supports the security features described above. 

These components must have a specific configuration standard associated with them, in accordance with PCI DSS requirement 2.2. As a reference, you can use the document NIST Special Publication 800-81-2 - Secure Domain Name System (DNS) Deployment Guide.  

Selection of an industry-accepted top-level DNS

Because the DNS service architecture is hierarchical and recursive, the DNS server in the PCI DSS network must connect to a higher-level server (usually a DNS resolver) on the Internet. 

As with the time synchronization service (NTP), the external servers providing the service must be industry-accepted and support the security features described above.  

Some of these external name resolution services with security and privacy features are: 

• OpenNIC (https://www.opennic.org/)  
• Cloudflare (https://www.cloudflare.com/dns/)  
• OpenDNS (https://www.opendns.com/)  
• DNSWatch (https://dns.watch/)  
• Quad9 (https://www.quad9.net/)  

Additional functionalities

The use of an internal DNS service allows the implementation of additional controls such as content filtering, blocking traffic to untrusted domains.

Considerations for registering domains linked to PCI DSS environments

Another major issue not addressed by the PCI DSS standard is the security management of domain registrations associated with PCI DSS environments conducted with external name registration providers, particularly for e-commerce services.  

As described above, the DNS allows the linking of an IP address with a domain name (FQDN). When a user (an individual or an organization) wants to register a domain name under a specific TLD, they must contact an authorized entity called a "registrar". This registrar receives the user's registration request, validates that the domain is available and, if available, proceeds to add this new name to its DNS record database. From that moment on, any change required to be made to the registry (renewal, transfer or even editing of DNS records and zones if these tasks have been delegated to the registrar) must be done using the interfaces provided by this provider. 

If a domain name is registered that points to an asset's IP address within a PCI DSS environment, the registrar automatically becomes a critical element within the organization's infrastructure, as the responsibility for the operation and management of that name rests with this entity. If an attacker compromises the registrar's network or gains unauthorized access to the domain management interface, traffic can be redirected to malicious servers without the end user being aware of the change.  

According to the PCI SSC glossary, a service provider is defined as a “Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS, and other services as well as hosting providers and other entities.”.  

Generally, a domain registrar is not included among the service providers that affect a PCI DSS environment - even though their services may affect the security of cardholder data - so there is no obligation on the part of these entities to comply with the standard or to add additional security controls to prevent the risks associated with domain management.  

In that sense, it is recommended to follow these recommendations: 

• Using a reliable domain name registrar.  
• Minimize the information exposed in the Whois database (information on domain holders) through private registration services.  

• If available, enable multi-factor authentication (MFA) in the domain management interface provided by the registrar to minimize unauthorized access.  
• Manage different roles and permissions on users who can access the DNS management interfaces.  
• Enable DNS change locking, which adds additional controls if any changes are made to registered domain names. For example, an employee of the domain registration company can request written or telephone authorization from an authorized person in the company to make DNS changes, request a personal identification number (PIN), OTP code, and so on.   
• Restrict access to domain management interfaces to authorized IP addresses, physical locations, or specific devices only  
• Activate notifications (mail, SMS, etc.) when DNS changes are made. 

• Configure automatic renewal, to prevent a malicious user from acquiring the domain when it expires and redirecting traffic to servers under their control.  
• Periodically monitor DNS records (especially CNAME) to detect inactivity or obsolescence problems that may allow a malicious user to gain control of sub-domains (subdomain takeover).  

Conclusion

"A chain is only as strong as its weakest link." We have heard this phrase many times applied to the cyber security environment and it is still valid today.  

An environment that processes, stores and/or transmits payment card data must comply with the controls of the PCI DSS standard, which adds an additional security layer to protect such data. However, one of the components of these environments that is generally not properly identified and protected is the name resolution service or DNS. Because of this, the organization may have a "blind spot" in its security strategy and it is essential to proceed with the deployment of preventive and corrective actions so that this does not become a vector of risk.  

The use of secure architecture, the implementation of additional security functionalities, and the protection of DNS records exposed on the Internet, as well as the use of DNS services provided by trusted entities are part of this strategy to defend this "weak link". All of these recommendations should become a complementary part of PCI DSS controls in organizations affected by compliance with this standard.