The European Union’s General Data Protection Regulation (GDPR), one of the most rigorous pieces of privacy legislation to date, has become almost synonymous with data privacy. This is partly due to its broad scope. The GDPR applies to any organization collecting and processing the data of an EU citizen—even if the organization isn’t based in the EU—so it has a global impact.
Even where the GDPR doesn’t apply, companies may proactively implement its provisions if they plan to expand their exports, or to future-proof potential mergers and acquisitions. This is sometimes called the Brussels Effect, where it’s simpler for some organizations to comply with the most stringent regulation currently in effect, rather than deal with the complexity of enforcing different regulations in different jurisdictions.
DNS has an important role to play in GDPR and other regulatory compliance, especially when dealing with geo-dispersed users. This blog will focus on the non-IP aspects of DNS records, and how the dynamic delivery of non-IP DNS can aid in delivering regulatory compliant services.
Security and Privacy by Design
A commonly cited GDPR requirement is security and privacy by design. Organizations must take precautions to prevent data breaches and protect data subjects’ privacy in the event of a breach. This needs to be built into the entire IT strategy and infrastructure, not pasted on as an afterthought.
Article 32 of the GDPR (Security of Processing) mentions encryption as one of the possible measures that can be taken to protect a subject’s data—even if the data is stolen, it’s useless without the encryption key.
The GDPR also requires granular control over who can access data. Organizations should design their IT on the principle of least privilege. Only people who absolutely need to see personally identifiable information (PII) to do their jobs should be allowed access to it, and they should only be allowed to access the specific data they need. Authentication and Role-Based Access Control (RBAC) become must-haves.
DNS comes into this in a few ways.
One less-mentioned part of the GDPR is the transfer of personal data to third countries or international organizations. If this data leaves the EU to be processed, it can only go to certain approved countries or to organizations outside those countries who’ve signed a contract stating they’ll handle the data in compliance with the GDPR.
Thus, it becomes imperative to know where data is located and where it’s allowed to travel. This can affect the use of public cloud computing services or third-party subcontractors.
The combination of these regulatory requirements means organizations need to be able to set different policies for different users and different locations.
There exist both free and paid services to determine a device’s approximate location by IP address. Information from such a service can be combined with some types of DNS records to ensure data doesn’t move outside certain geographical limits and can only be accessed by authorized persons.
A word of warning on geolocation by IP address: it’s approximate. It’s usually accurate at the country level but becomes less so if you’re trying to pinpoint a specific ZIP code or street address. Failure to understand this can result in unintentional horrible consequences.
SRV records contain information about the network location of certain services and are usually stored in the DNS zone file. An SRV record can be used in conjunction with IP geolocation to answer pertinent questions like “where’s the email server?”
SRV is most often used in SIP telephony and email, but other services and protocols may also require SRV support. These include DNS-based Authentication of Named Entities (DANE), CardDAV, and Puppet, all of which have potential uses or cautions with regard to regulatory compliance.
DANE is related to securing internet communication, and therefore may be relevant as part of a GDPR strategy. DANE lets the digital certificates used for Transport Layer Security (TLS) be bound to domain names using Domain Name System Security Extensions (DNSSEC). This allows origin authentication of DNS data, authenticated denial of existence, and helps verify data integrity.
CardDAV is an address book client/server protocol used on many iOS and Mac devices. Contact information may be protected by the GDPR and similar legislation, so knowing the location of a CardDAV server (and protecting it accordingly) is important.
Puppet is an orchestration tool that can enforce desired-state configuration, which can be useful in securing IT infrastructure, especially at scale. This may be relevant to the GDPR requirement of security by default.
TXT is the DNS record equivalent of a Post-It note. It can contain human-readable information about a server, or network, such as “this is located in the Rabat data center.” Or it can be used to label network locations with reminders of what regulations apply.
TXT has also evolved into a place to store small amounts of machine-readable data, so various programs and protocols can be configured to read a .txt file and act on what they find there. In a regulatory context, this is useful—the .txt file can specify whether or not an app is allowed to use certain features in certain legal jurisdictions. RFC 1464 first proposed this as an experimental protocol in 1993, and since then it has been used in DMARC policies, verification of domain ownership, DomainKeys Identified Mail records, and implementation of Sender Policy Framework (SPF).
Multiple .txt files can be associated with one domain, so it’s possible—and perhaps desirable—to use several different means of documentation, authentication, and configuration to provide defense in depth.
This is only a brief overview of how DNS relates to regulatory compliance. But the basic idea is simple: if you control your own DNS server, you can create records that give more sophisticated control of how DNS queries are answered. From there, you can make more complex geographic, authentication-based, or addressing-based decisions to answer the DNS query.
The EU’s GDPR heralds a new era of regulatory instruments that are challenging how organizations have been storing and allowing access to data. As regulatory regimes evolve around the world from fuzzy, generic declarations of principle into precise, detailed laws, DNS is going to become a vital tool for service delivery and compliance.