Pervasive Monitoring (PM) of data networking traffic is not only performed by governments, but corporations wanting to inspect the behavior of employees or customers. The goal of network traffic monitoring can be benevolent. Organizations may want to detect malicious behavior to combat malware, identify insider threats, and prevent against criminal behavior. Unfortunately, the goal of monitoring can also be malevolent. Examples of this can include invading a user’s privacy or gathering data to be used in a subsequent attack. In fact, the Internet Engineering Task Force (IETF) feels that “Pervasive Monitoring is an Attack” (RFC 7258).
In recent years, there has been increased awareness about pervasive monitoring of electronic communications by governments. Even if those governments claim that they are only collecting metadata about the communications and not actually listening in on individual phone calls, the metadata can reveal a lot about a person and their behavior. Governments claim that global surveillance helps them uncover terrorist activities, but there is a downside to personal privacy resulting from such behavior. Pervasive Monitoring of Domain Name System (DNS) messages can provide valuable data that can be used for good or evil, depending on your perspective. Even though information returned within the DNS messages is usually considered public, not everyone feels that their queries, what they are looking up, are also public information.
DNS Packet Inspection
When it comes to DNS packet inspection, both queries and responses contain data in clear-text. DNS traffic between the client and the recursive name server is not encrypted, nor is any encryption used when recursive name servers perform recursive lookups. The Domain Name System Security Extensions (DNSSEC), contrary to what its name might imply, does not encrypt the payload of the DNS query or response, but rather, provides a method of validating the authenticity of the information. DNSSEC provides for origin authentication and data integrity, but does not provide any confidentiality or DNS service reliability/availability.
By inspecting DNS traffic, you can observe the Query Name (QNAME) and the Query Type (QTYPE) and might even be able to see the data within the DNS response. You observe different information depending on where in the network topology you capture the DNS messages. If the DNS messages (frequently UDP port 53, but sometimes over TCP port 53) are observed on the Internet, one can also glean the IP address of the system making the DNS query. If you are observing the DNS messages in close proximity to the end-user’s device, you can inspect the individual client’s queries and the source IP address of the end-user’s device and query packet payload. For an enterprise using their own local recursive DNS server, then the recursive DNS server’s IP address could be discerned from the Internet perspective. Network Address Translation (NAT) is extensively used by enterprises with IPv4, so the source address of the DNS recursive name server could be modified on its way to the Internet DNS servers. However, with IPv6, there is no need for NAT (see RFC 4864) so the client’s global unicast address would likely be unmodified on its path to the recursive name server.
View from the DNS Recursive Name Server
By their very nature, recursive name servers proxy the DNS query and do not reveal the originating client IP address of the device making the initial request. Large publicly-reachable recursive DNS servers (such as those from Verisign and Google) provide DNS resolution services for numerous clients. Therefore, if you are observing DNS queries emanating from these recursive DNS servers, it would be difficult to ascertain what any one individual DNS client may be wanting to ultimately connect to. Also, these are caching DNS servers, so you would only be able to observe new queries or queries for names that have expired their Time to Live (TTL). The organization operating a public recursive DNS server would be able to observe the original query being made by the client’s device. Although there are many DNS queries made as a user might “surf the net”, it is possible to cull through the DNS packets to ascertain the user’s activity. We can only hope that the organizations operating public DNS services have the best of intentions and desires to preserve the individual’s privacy.
In the case of Verisign and Google, they publicly announced that they intend to help maintain privacy. However, it creates speculation over why a company would offer a free DNS resolution service, unless they were getting something in return; like information about us. For many residential broadband Internet users, their recursive DNS server is most often run by their ISP. If an enterprise organization runs their own DNS servers, then they would be in control of how they treat the confidentiality of the information within the DNS queries.
View from the Authoritative Name Server
For those organizations who operate their own authoritative name servers, they may be observing the queries they receive for their DNS information. The authoritative server would be able to see the source IP address of the recursive DNS server that sent the query. The authoritative server would also be able to learn the client’s source IP address if that client runs a personal/local DNS server on its system. The information gathered by the authoritative name server can also be valuable.
DNS Tells All
Most organizations and individuals do not realize how much information can be gleaned from DNS traffic inspection. We should recognize that we are giving away a lot of information to the system we are using for our DNS service. From this DNS information, the recursive DNS server knows just about everything about your Internet behavior. DNS traffic reveals everything from, where you shop online, what web pages you looked out, what you clicked on, and what you purchased. It can reveal who you associate with, what topics are interesting to you, and what information you accessed. If your Mail User Agent (MUA) server uses the same DNS server, then it also knows to whom and when you sent e-mails.
Geolocation and CDNs with DNS
Alternatively, there are certain benefits to disclosing your location by revealing your source IP address and what you are seeking to connect to. For example, Content Delivery Networks (CDNs) use geolocation to help direct you to content that is geographically closer to you, thus improving your application experience. Many content providers use the IP address of the DNS server making the query for their web site’s Fully Qualified Domain Name (FQDN) for the purposes of Global Server Load Balancing (GSLB). The assumption is made that the client is located in close proximity to their DNS server and therefore, the client can be directed to connect to a closer web server yielding reduced latency and improved end-user experience. This system breaks down when the client is using a DNS server that is far away from their actual location within the network topology.
DNS is Critical Internet Infrastructure
Awareness of how Internet infrastructure is in fact critical infrastructure has increased the visibility of DNS security, Border Gateway Protocol (BGP) security, and Certificate Authority (CA) security. Recent DoS attacks using open DNS servers and weak NTP systems have made securing these protocols a priority. The intersection of these protocols culminates in security efforts outlined in solutions like Resource Public Key Infrastructure (RPKI), DNS-based Authentication of Named Entities (DANE), and Domain Keys Identified Mail (DKIM), among others.
Organizations are starting to wake up to the dangers of DNS monitoring and there are groups that are working on solutions to improve privacy. This past summer at the NANOG On the Road #7 event, Duane Wessels of Verisign gave a great presentation on the “Recent and Future Developments in DNS Security.” A few months ago, there was a CircleID article by Verisign titled “Protect Your Privacy – Opt Out of Public DNS Data Collection” that also describes these issues regarding DNS and privacy.
In the next blog of this 2-part series, we will cover the work being done within the IETF to alleviate these DNS privacy concerns.
This post originally appeared on the Infoblox blog at https://community.infoblox.com/t5/IPv6-Center-of-Excellence/DNS-Privacy-in-the-Face-of-Pervasive-Monitoring-Part-1-of-2/ba-p/5166.
