Home » Security Bloggers Network » Using Akamai Edge DNS with PCI DSS Environments

Using Akamai Edge DNS with PCI DSS Environments

by Gennadiy Belenkiy on December 3, 2020

Overview

The PCI DSS scoping guidance indicates that common shared services that provide services to the CDE, such as DNS, can be in scope and must be assessed for PCI DSS compliance.

This post discusses the application of this scoping guidance to the external authoritative DNS servers and provides an overview of DNS operation on the internet. It also outlines some common threats to the DNS infrastructure and respective compensating controls from the perspective of the PCI DSS, providing a detailed explanation of why Akamai Edge DNS internet authoritative DNS service is an out-of-scope system for PCI DSS.

DNS Infrastructure and Akamai Edge DNS

The internet DNS infrastructure was developed in the 1980s without a strong security consideration.

Let’s consider a common scenario where a PCI DSS-compliant web application is published on the internet using the domain name www.akamai.com, with the web server located at the IP 104.117.251.150 (see Figure 1).

Sponsorships Available

Figure 1

For the server to be found by users on the internet by its domain name, the name needs to be registered in the respective DNS registry. This is normally done with the help of a DNS registrar. As part of the name registration, among other things, it’s necessary to provide the details of the authoritative DNS servers that would host the DNS zone record.

Akamai’s Edge DNS is an excellent choice as a primary authoritative DNS, as it’s highly scalable and has a 100% availability SLA.

Next, let’s consider how the clients will resolve the domain names into IP addresses with this scenario: A client is located in a large convention center with a sizeable guest Wi-Fi network. The venue uses an ISP to provide its guests access to the internet and uses DNS servers of the ISP to resolve domain names. The DNS request to resolve www.akamai.com from the client in this case might work as follows:

The client on the convention center’s Wi-Fi network will send a request to the DNS Resolver1, which is the venue’s DNS recursive resolver
The DNS Resolver1 will look into its cache, find no suitable records, and send a request further to the ISP’s resolver
The ISP DNS Resolver2 is a recursive resolver, and it will look into its cache as well — if there are no suitable records, it will (refer to Figure 1):
1. Go to the root DNS servers, which will redirect to the appropriate TLD DNS servers, and the DNS Resolver2 will …
2. Go the appropriate TLD DNS servers and ask for the authoritative DNS server name that contains the relevant zone record. Once the authoritative DNS server name is obtained, it will …
3. Go to the Edge DNS authoritative DNS server, as instructed by the TLD DNS servers, and ask to resolve www.akamai.com. The authoritative DNS server will resolve the domain name and return the appropriate IP address.
4. DNS Resolver2 will store the response in its cache in accordance with the TTL and pass the response further to the DNS Resolver1.
5. DNS Resolver1 will also store the response in the cache and respond back to the client.

Now the client has the correct IP address for www.akamai.com and can send an HTTP request.

What Can Go Wrong: DNS Threats

There are a number of things that can potentially go wrong with the DNS. In this context, typically it is about affecting either the availability of the web application or trying to redirect internet users to a malicious internet resource. Consider the following:

DNS recursive resolver cache poisoning. One particular type of this category is also known as the Kaminsky attack. The cache of the DNS Resolver1 and DNS Resolver2 can be poisoned and can resolve www.akamai.com into an incorrect IP address, so the client will try to establish an HTTP connection with a rogue WWW server (see Figure 1).

DNS hijacking. This attack can take many forms using multiple vectors. It can be an ISP, deliberately manipulating the DNS responses, or it can be malicious DNS registry changes. In the worst-case scenario, this attack will allow malicious actors to not only redirect the traffic to a rogue WWW server, but also potentially allow them to issue a valid DV certificate.

DDoS of the DNS infrastructure. This is one of the common attacks that can lead to the unavailability of the authoritative DNS and, as a result, unavailability of the web application service.

Even if the authoritative DNS server complies with the PCI DSS requirement, there are many places on the internet, as demonstrated above, where things can go wrong — and DNS responses can be manipulated and domains can be hijacked.

Compensating Controls for DNS Threats

In the internet communication scenario above, one of the main compensating controls for the outlined DNS threats is ensuring that HTTP is run over TLS. It is essential that the web application server uses a valid TLS certificate, uniquely identifying the web server and providing a one-way authentication of the connection.

As shown in Figure 1, even if the DNS response is manipulated and the client is redirected to a rogue WWW server, without the proper TLS certificate the browser will identify this connection as invalid and risky.

Without the proper TLS certificate and the private key, the DNS attacks will unlikely lead to the compromise of the HTTPS connections.

Therefore, monitoring and controlling the records in the DNS registry is of critical importance — if the DNS record in the registry is maliciously updated, a rogue TLS DV certificate could be issued. This is a responsibility of the web server owner who leased the domain name for it from the DNS registry.

Although DNSSEC was designed to overcome many DNS security shortcomings, this suite of IETF specifications is still not commonly adopted. APNIC estimates that only about 20% of internet DNS recursive resolvers use DNSSEC. Most resolvers on client computers also don’t currently use it at all.

As for the DNS DDoS threat, Akamai’s Edge DNS service is an excellent mitigation against it, ensuring the domain names can be properly resolved under such attacks and the business continues operating.

Should Edge DNS Be in PCI DSS Scope?

Version 1 of guidance for PCI DSS scoping¹ and network segmentation provides the following chart (Figure 2) to determine whether a system is in or out of scope of the PCI DSS assessment.

Figure 2

Let’s consider the requirements one by one.

Firstly, Akamai’s Edge DNS service does not process or store any cardholder data (CHD) or sensitive authentication data (SAD). It stores DNS zone records and responds to DNS requests from DNS resolvers on the internet. Akamai Edge DNS is also not located on the same network segment as systems that store or process CHD and SAD. Based on these criteria, Edge DNS cannot be included into cardholder data environment (CDE) and considered in the PCI DSS attestation’s scope.

The scoping document lists DNS servers as common shared services, providing services to the systems in the CDE and other system components across the organization’s enterprise — namely, domain name resolution service.

Akamai’s Edge DNS, however, is not such a DNS server. It is not a connected or security-impacting system, as it does not:

directly connect to the CDE — Edge DNS is not involved in any information exchange with the systems in the CDE, directly or indirectly; it is not a “connected-to” shared service, and is an external authoritative DNS service
impact configuration or security of the CDE; Edge DNS is a DNS service and does not adversely impact the security of the CDE, provided the controls for the DNS threats are in place as explained above
provide segmentation of the CDE from the out-of-scope systems
indirectly connect to the CDE
provide security services to the CDE; Edge DNS does not provide security controls in the PCI DSS context, such as network firewall, IDS/IPS, anti-malware or authentication service

The compromise of the Edge DNS will not lead to the compromise of the CDE, as the systems are completely separate. Given the above, Akamai Edge DNS service is considered as an out-of-scope system and does not need to be assessed against the PCI DSS criteria.