anondns
anondns copied to clipboard
AnonDNS: encrypting and anonymizing all your DNS requests with Tor
AnonDNS: encrypting and anonymizing all your DNS requests with Tor (WORK IN PROGRESS)

This project's goal is to anonymize and encrypt outgoing DNS requests. It currently consists of automation code to set up dnsmasq (either locally or public-facing) in combination with Tor which will anonymize all of your outgoing DNS requests. This is not an official Tor project.
AnonDNS's target user base are those who are willing to trust the web PKI, running standard Firefox or Chrome with extensions like HTTPS Everywhere (although the SNI header still leaks the domain name one is visiting), yet don't want to bother with the Tor Browser, and still would like their DNS lookup activity to be anonymized.
In recent years, the world wide web has been making significant and impressive strides in HTTPS adoption. As part of this, Google's Chrome web browser will begin marking plain HTTP sites "insecure" in the user interface later this year. Likewise, Mozilla plans to require secure contexts for most features. The statistics since the advent of Let's Encrypt have been impressive.
Source: Let's Encrypt
Still, one place where privacy has been significantly lacking is in DNS. Each time one makes a connection to a website, the client must first translate the hostname to an IPv4/6 address. It's an old protocol, first standardized by the IETF in 1983 and BIND came out a year later. SSL would not happen for another decade, which is to say that the Domain Name System was not not designed with security in mind. There was originally no encryption of DNS requests, although now the results can be signed with DNSSEC to block tampering or poisoning. The subject of extensions to the protocol has been explored extensively, such as in IETF papers titled Pretty Bad Privacy: Pitfalls of DNS Encryption and Encrypted DNS: An opportunistic encryption protocol extension for DNS. Google, who operates the most popular public open resolvers, provides information about DNS-over-HTTPS. There's the recent RFC 8094, a Specification for DNS over Datagram Transport Layer Security (DTLS), as well as RFCs 7626 and 7858; and a draft for DNS queries over HTTPS. There were also multiple efforts related to DANE: RFCs 6698, 7218, and 7671.
The goal of this particular project is to anonymize and encrypt one's DNS requests on their machine by leveraging Tor and its DNSPort feature, absolutely prohibiting leaks of requests to your ISP or other network adversaries with iptables, plus a locally-running DNS server such as dnsmasq to provide caching (avoiding slowness) and DNSSEC validation.
It's presently geared to users of Debian GNU/Linux 9 (stretch). Currently this is just a set of Ansible roles and playbooks, but the long-term plan is a cross-platform program that runs as service and has an accompanying graphical configuration tool.
In this alpha release, it can be configured to run locally or as a public Tor-based DNS server. Every time you make a DNS request, you could be getting your results from a random Tor exit node anywhere. Poisoning or spoofing is a risk; so the default configuration includes DNSSEC validation, and also prevents rebinding attacks and addresses from private IP space to be returned. Any process or user who is not dnsmasq will be redirected through Tor.
Please consult NOTES_AND_TODO.md for what needs to be imeplemented and explored next. There are several challenges to making this compatible with other platforms using conditional logic, benchmarking to be performed, plus the whole build system, installer and configuration UI and service setup to be addressed.
Here's an overview of the playbooks:
- local.yml: Run ansible-playbook --connection=local --limit localhost in order to activate AnonDNS on your machine.
- security.yml: Provides OS and SSH hardening of the target machine. Requires you to run
ansible-galaxy install --force --ignore-errors -r requirements.ymlin order to obtain the security-related dependencies from dev-sec.io - tor-dns-server.yml: Sets up a full-fleged public Tor-based DNS server, with monitoring (explained below) and extra configuration provided by the "common" role.
Variables
# If set to true this will open port 53 to the public internet via ufw, and bind your ethernet interface instead of loopback..
public_dns_server: false
# If set to true, dnsmasq will fall back in strict order to the listed nameservers, when Tor fails. This is recommended.
nameserver_fallbacks: true
# A list in relation to the above setting.
fallback_nameservers:
- "1.1.1.1" # Cloudflare
- "9.9.9.9" # Quad9
- "8.8.8.8" # Google
- "208.67.222.222" # OpenDNS
dnssec_enabled: true
dnssec_check_unsigned: false
# Replace your system-wide Tor configuration with our own. Otherwise, we'll only set the options needed to make AnonDNS work.
replace_torrc: true
# The name of your regular unprivileged system user.
anondns_user: ''
Getting started
The configuration management is done with Ansible, which may be obtained via Python's pip.
We use Debian GNU/Linux (currently stretch or 9.x) for everything. Don't try running this code on another distribution and expect it to work.
All commands documented here are expected to be executed from root of this repository. Here's what one needs to have installed:
sudo pip install -U ansible
We recommend Ansible 2.4.3 or later.
In order to update the security-related dependencies for hardening base operating system and SSH daemon:
Edit the hosts inventory at hosts and set the IP address for your server. It's ideal to have some DNS subdomains pointing to that same server.
Then you may execute the playbook at tor-dns-server.yml.
HTTPS adoption succeeds while most of the Domain Name System remain plaintext
Source: https://research.google.com/pubs/pub46197.html
Source: https://research.google.com/pubs/pub46197.html
Source: https://research.google.com/pubs/pub46197.html
Source: https://research.google.com/pubs/pub46197.html
Source: https://research.google.com/pubs/pub46197.html
Source: https://research.google.com/pubs/pub46197.html
Source: https://research.google.com/pubs/pub46197.html
Source: https://scotthelme.co.uk/alexa-top-1-million-analysis-aug-2017/
⚠️Warnings
Relying upon Tor for DNS results comes with risk. Exit nodes might be bad or malicious, poorly misconfigured, or have set their own dubious nameservers. Therefore, we've enabled options to prevent rebinding attacks and addresses in private IP from being returned. Also, this is where DNSSEC comes into play, and there are two options.
We may choose to proxy and trust the upstream server's validation of a DNSSEC signature, or we can do it ourselves. Since Tor could be regarded as a volatile and unpredictable network, we've configured the option to validate DNSSEC-signed records against the root trust anchors.
DNSSEC deployment progress has been remarkable, although DANE lags behind. As of this writing, there are 1544 TLDs in the root zone in total. 1407 TLDs are signed, and 1399 TLDs have trust anchors published as DS records in the root zone.
Source: http://secspider.verisignlabs.com/growth.html
Source: https://stats.labs.apnic.net/dnssec
However, the problem is that client resolvers are not validating.¹ Although we have an approximately 90% DNSSEC-enabled internet, only a meagre 12% of users are validating.
Source: http://rick.eng.br/dnssecstat
With strict ordering of upstream nameservers enabled, an insecure or an invalid result should mean the query is forwarded to the next server in the chain, until the result is valid, and it will be cached. We've also adjusted Tor's configuration so that circuits are changed more frequently, in order to grasp at a wider variety of sources for zone information.
The following graph shows that validation rates are higher in Scandinavian countries than, for instance, the United States. Hypothetically, setting ExitNodes in torrc to some specific country codes, which is usually inadvisable, might be helpful in this instance.
But in general, I have been running this name resolution scheme on my Linux desktop for weeks without issues.
Source: