I have written about my use of OpenVPN in several posts in the past, most latterly in May 2017 in my note about the Investigatory Powers (IP) Bill. In that post I noted that all the major ISPs would be expected to log all their customers’ internet connectivity and to retain such logs for so long as is deemed necessary under the Act. In order to mitigate this unwarranted (and unwanted) surveillance as much as possible, I wrap my connectivity (and that of my family and any others using my networks) in an OpenVPN tunnel to one of several endpoints I have dotted about the ‘net. This tunnel shields my network activity from prying eyes at my ISP, but of course does not stop further prying eyes at the network end point(s). Here I am relying on the fact that my use of VMs in various European datacentres, and thus outside the scope of the IP Act, will give me some protection. But of course I could be wrong – and as I pointed out in my comparison of paid for versus roll your own VPNs, “there is no point in having a “secure” tunnel if the end server leaks like a sieve or is subject to surveillance by the server provider – you have just shifted surveillance from the UK ISP to someone else.”
That aside, I feel more comfortable in using my own VPN, to an end point I have chosen, in a location I have chosen, with a provider I have chosen, than I do in simply exiting my domestic ISP’s network with all that I /know/ they will be doing to log my activity. Call me picky.
Now one glaring omission in my protective stance has always been my reliance on third party DNS servers. Again, as I noted in my 2017 post, many commercial VPN providers rely on DNS servers of questionable reliability. By that I mean not that the DNS servers would necessarily fail, but that they could not be fully trusted. Google DNS servers (on 8.8.8.8 and 8.8.4.4) for example are very popular with ISPs precisely because the infrastructure they provide /is/ robust and reliable. But Google log your requests. In fact they are in a very powerful position. I can’t find statistics on the total proportion of DNS requests answered by Google (and I have looked, trust me) but back in late 2014, Google themselves stated “Google Public DNS resolvers serve 400 billion responses per day and more than 50% of them are location-sensitive.” That worries me – and it should worry Tor users (a naturally shy bunch of internet users) even more. Back in 2016, “Freedom to Tinker” published a blog post by the researchers Philipp Winter, Benjamin Greschbach, Tobias Pulls, Laura M. Roberts, and Nick Feamster (later published in a paper at nymity.ch (PDF). That research found “that a significant fraction of exit relays send DNS requests to Google’s public resolvers. Google sees about one–third of DNS requests that exit from the Tor network—an alarmingly high fraction for a single company, particularly because Tor’s very design avoids centralized points of control and observation.” Discussion on the Tor relays email list suggests that, even today, DNS lookups remain a threat to Tor user’s privacy and anonymity.
But worse than just logging, some DNS providers (notably Quad9 on 9.9.9.9 and 149.112.112.112 and OpenDNS on 208.67.222.222 and 208.67.220.220 for example) actively hijack and interfere with DNS requests. OpenDNS actually make a marketing point of this interference by saying that they will block access to “adult” sites (in the name of parental protection of course). Others, such as cleanbrowsing (on 185.228.168.9 & 185.228.169.9) make a similar virtue of blocking access to “malware” or “adult” sites. All this may appear eminently laudable, and for some people hoping to manage the sort of sites their kids access from home it may seem an attractive option. But I’m a purist. A DNS server should do one thing and only one thing and it should do it well. It should answer DNS requests according to the RFCs 1034 and 1035 (which obsoleted RFCs 882 and 883). It most certainly should not, for example, intercept requests and provide pointers to websites owned by the provider when that provider deems it appropriate to do so. If I ask for the A record for the DNS name “nosuchserver.org” for example. I should get the answer “NXDOMAIN” (as recommended by RFC 2308) telling me that that name does not exist in the DNS system. I most categorically should /not/ get a record pointing to another site. Indeed, back in the early part of this century, Verisign, who were the registry responsible for the .net and .com domains introduced what they called the “Site Finder service”. (See also the wikipedia article for further discussion.) That “service” (or in reality nothing less than a naked power grab by Verisign) returned the address of a Verisign owned and managed web server whenever a request was received for an unregistered .com or .net domain name. Fortunately, in this case ICANN stepped in in 2003 and forced Verisign to desist. But this example merely serves to illustrate how easy it is to interfere with legitimate DNS requests. UK ISPs do this all the time these days. They have to by law, not least in order to apply the (somewhat controversial) blocklists provided by The Internet Watch Foundation.
On my own network internally, I run dnsmasq as a local caching resolver – well actually, I run two such resolvers, one on my inner net, the other on my outside net which has a slightly different security policy stance. The advantage of running such local caches is that I can interfere with my /own/ DNS requests. I do this deliberately in order to block requests to sites I don’t want to see, and which attempt to infringe my privacy. dnsmasq gives me a very simple mechanism to do this through its configuration directive “addn-hosts=” which forces dnsmasq to consult a file similar to the local database of known hosts typically listed at “/etc/hosts”. In my case I set this to “addn-hosts=/etc/hosts.block” which is a locally modified copy of Dan Pollocks’ host file. So any website which tries to direct my browser to facebook, or google-analytics, or any other of the myriad irritating sites which try to shove cookies at me or track me or collect data about me (and these days, unfortunately, that is most of them) won’t succeed. I hate advertising sites and I loathe facebook in particular. So they get pointed to 127.0.0.1.
But as I said above at the start of this post, one glaring omission in my attitude to DNS resolution was my reliance on external third party DNS servers for addresses not covered by my local resolver. As I said in my 2017 post, my local dnsmasq resolver files pointed to the OpenVPN endpoint(s) for resolution and both those servers and my local DNS resolvers pointed only to opennic DNS servers. I trust those servers a lot more than I would any of the larger public DNS servers, but they have flaws. The biggest problem is that many of those servers seem to be run by people like me – essentially hobbyists or activists who dislike internet censorship. There is nothing wrong with that, in fact I applaud it, but it often means that the DNS servers themselves are underspecced or underpowered and/or run on VMs in low bandwidth datacentres (because they are cheap). This means in turn that the servers themselves will often be overloaded, or periodically offline, or will even disappear altogether. This makes maintenance of my list of preferred servers too much of an overhead. I like simplicity. (As an aside, because I am naturally a suspicious sort of chap, there is also the possibility that one or more of the opennic servers may actually be run by persons I ought NOT to trust. It is well known amongst the Tor fraternity for example, that a proportion of the exits nodes at any one time may well be run by Government agencies, or others, keen to de-anonymise Tor users. If you are shown to care about your privacy, by using Tor for example, then of course you “must have something to hide”. Similar reasoning may lead “bad guys” (TM) to wish to run opennic servers. After all, they are all run by volunteers…..)
So, what to do to enhance my (fragile) privacy? Enter unbound, a validating, recursive, caching DNS resolver, designed to be fast and secure. Better yet, unbound supports the emerging standard for encrypted DNS and does DNSSEC validation by default in most configurations. Unbound is distributed under a BSD license and can be found in most linux repositories or bsd ports collections. It is also freely available in source form from NLnet labs. The extensive documentation is also excellent.
The configuration file options allow for extensive control over how unbound operates, but a simple configuration can use as few as 8 or 9 lines of text. My own configuration hides both the identity and the version of unbound in use, limits unbound to IPv4 only and disables all logging (for obvious reasons). And, of course I only allow queries from my own servers or networks – I don’t want to be used by all and sundry on the internet.
It is worth noting that several authors have published suggestions aimed at mitigating the threat to Tor users posed by relying on third party DNS servers. One nice example by Antonios A Charlton at daknob.net proposes the use of the powerdns recursor a recursing only server which holds no authoritative data of its own – it always queries authoritative servers. Powerdns has many fans, I simply prefer unbound in my environment. YMMV.