December Webinar: Kea Configuration with Stork
Kea Configuration with Stork Stork is an open source project, providing a graphical interface for monitoring, and now also configuring, Kea DHCP servers.Read post
Surveillance is the business model of the Internet. Everyone is under constant surveillance by many companies, ranging from social networks like Facebook to cellphone providers. This data is collected, compiled, analyzed, and used to try to sell us stuff.
Personal data, of the sort that is exposed while using the Internet, is valuable. If you share personal data, you should assume that there may be someone out there who is motivated to collect, analyze, and monetize it. One step in minimizing exposure of your personal data on the Internet is to use a DNS service that implements QNAME minimization. BIND 9.14.0, the new current-stable version of BIND, features QNAME minimization enabled by default. This is a significant change in the way DNS name resolution is done.
RFC 7816 defines “DNS Query Name Minimisation to Improve Privacy.”
QNAME minimization changes the DNS queries from the recursive resolver to include only as much detail in each query as is required for that step in the resolution process. The IETF draft describes it as a technique “where the DNS resolver no longer sends the full original QNAME to the upstream name server.”
Let’s say you want to visit a blog site at https://someblogname.bloghosting.com.pl. In order to determine which IP address to connect to to reach that link, your computer sends a request to your ISP’s resolver, asking for the full name - someblogname.bloghosting.com.pl, in this case. Your ISP (or whoever is running the network you are using) will ask the DNS root, and then the top-level domain (.pl in this case), and then the secondary domain (.com.pl), for the full domain name. In fact, all you are finding out from the root is “where is .pl?” and all you are asking .pl is “where is .com.pl?” Neither of these requests needs to include the full name of the website you are looking for to answer the query, but both receive this information. This is how the DNS has always worked, but there is no practical reason for this today.
Sharing the full query target with intermediate servers may not seem like a big deal in this case. But what if you were looking up something controversial or even illegal in your local jurisdiction, such as information on a political movement that was prohibited in your country? Would you want your query to be shared with domains that have no practical need for that information?
Constant background leakage of this sort of meta-data, combined with improvements in big-data analysis, has made it more feasible to profile and track individual user activity on the Internet. As RFC 7816 states, “QNAME minimization follows the principle … the less data you send out, the fewer privacy problems you have.”
The DNS Privacy Project has an excellent summary of the reasons for concern about user privacy:
- Almost every activity on the Internet starts with a DNS query (and often several). A key function of the DNS is to map human readable names (e.g. example.com) to IP addresses that computers need in order to connect to each other.
- Those queries can reveal not only what websites an individual visits but also meta data about other services such as the domains of email contacts or chat services.
- Whilst the data in the DNS is public, individual transactions made by an end user should not be public.
- However DNS queries are sent in clear text (using UDP or TCP) which means passive eavesdroppers can observe all the DNS lookups performed.
- The DNS is a globally distributed system that crosses international boundaries and often uses servers in many different countries in order to provide resilience.
- Note that even when using a VPN some VPNs will still leak your DNS queries by sending them unencrypted to your ISP. Use the nice tool from anonymyster.com to check is this is happening with your VPN!
– Sara Dickinson on DNS Privacy.org
* Deleted points concern additional risks associated with the exposure of meta-data to the resolver operator. QNAME minimization does nothing to reduce data shared with the resolver operator; QNAME minimization on its own is only a partial mitigation for protecting user privacy.
Some implementations of DNS authorities can be confused by minimized queries, and will either not respond, return an error code, or return garbage data. In that case, BIND’s implementation, with the “relaxed” qname-minimization setting which currently is the default, will “fall-back” to normal querying, and will re-send the query with the full QNAME. A 2015 research study on QNAME minimization found that 12% of minimized queries failed, almost all due to a few large CDNs. These problems have largely been addressed, but there still are operators that fail to properly answer for minimized queries. The current “relaxed” setting might change in the future to “strict”, which will fail to resolve a name for which authoritative servers don’t answer properly for minimized queries.
Query loops are more common when using QNAME minimization.
Example query loop:
example1. IN NS ns.example2. example2. IN NS ns.example1.
We have added query-loop detection in BIND’s QNAME minimization logic so we won’t get hung up in this situation.
A single authoritative server may be serving both parent and child for a domain: isc.org and .org, for example. In this case, the records for .org should properly include a DS record for isc.org, and isc.org should include an NS record for .org. However, because traditionally the query contained the full path, servers that lacked the pointers from parent to child were able to verify that the DNSSEC chain was valid. With QNAME minimization, if there is no explicit link between parent and child, DNSSEC validation should fail.
In the case of zones that contain labels that are multiple levels deep (reverse PTR lookups for IPv6 is the classic example), QNAME minimization can require more queries than previously necessary. There are limits on how deep BIND will go with qname-minimization, and BIND will “jump over” some labels when querying for IPv6 PTR records. This difference will diminish as the cache is primed with answers.
When a resolver gets a response of NXDOMAIN, meaning the domain does not exist, the resolver will stop querying. BIND 9 caches and reuses negative responses to avoid superfluous queries.
QNAME minimization makes each negative answer more useful. For example, when querying for “department.school.university.edu” with QNAME minimization, a negative response from .edu would apply only to the question university.edu and would be cached as a negative response for that higher-level query.
The Pew Research Center has done extensive surveys on end-user attitudes towards their online privacy. Unsurprisingly, they are finding consumer concern has increased substantially over the last few years.
“Pew Research Center studies have shown that people are anxious about all the personal information that is collected and shared and the security of their data. Overall, a 2014 survey found that 91% of Americans ‘agree’ or ‘strongly agree’ that people have lost control over how personal information is collected and used by all kinds of entities.”
Some of this concern about social media and data sharing has already carried over into concern about DNS privacy.
79% of respondents to a 2017 ISC survey on DNS privacy believed that products and services that improve end-user privacy will get marketing benefits from the improved privacy.
Multiple new DNS services that promise to protect end-user privacy have emerged in the past two years and are seeing tremendous adoption. Quad9 (which operates a DNS resolver service at 126.96.36.199) reports that they are seeing growth in their user base of 5 - 10% EACH WEEK. Cloudflare, which operates 188.8.131.52, has also implemented QNAME minimization on their service.
QNAME minimization is only one element in an overall privacy protection plan. It does not encrypt your communications, nor does it ensure the integrity of data received. However, QNAME minimization is important to minimize passive data leakage, and it is one end-user privacy step that requires absolutely no effort or retraining of the end user. It is also easy for the service provider to deploy and does not add any cost or performance penalties. We hope that in 2019, QNAME minimization will spread on the Internet so that it will become the new default standard for a well-run DNS service.
What's New from ISC