9

I use pfSense (Unbound) as my local resolver. Historically I've pointed it at root recursive resolution, because I perceived my main threat as trustworthiness and recency of data (poisoned/invalid DNS) and local ISP DNS tracking. (I don't know if that's so, but I felt that a root DNS server overseas might be less connected to me personally and have less interest in any queries I generate.) I mainly use IPv4 which may be relevant.

With all the attention on DNS tracking, some concerns and perceptions have arisen:

  • Should I use some kind of DNS encyrption or signing method, for privacy/certainty? I'm not using DNSSEC or any other extensions, so my DNS queries are "in the clear" plain text. They are watchable between here and the various DNS servers, and there's no certainly over manipulation "on the wire" (less likely but noted). But what to use and how far will it help, as it's not supported by everyone.
  • Should I use an external resolver instead of querying root servers? I'm querying root servers from the start, so I'm issuing many queries from root servers down to the actual subnet of interest, instead of using a precached entry on some existing DNS resolver/cache. But each DNS server only sees one component of the domain, they don't get to see the entire target. If I use an intermediate resolver, especially one with signing/encryption, I issue far fewer DNS requests and what I do issue would always be encrypted and signed. But it requires a chosen intermediary with considerable trust (caching etc), and doesn't affect the risk of interception.
  • Should I route DNS over some kind of anonymising proxy? It's slower for first requests, but Unbound would cache any replies locally and also request refresh data in advance of the cached data expiring, and I'm guessing the 80/20 rule applies (most queries will be to the same subset of domains where I already have cached data), so I'm not too worried about the speed aspect. But how practical is this? The most prominent anonymising method is tor. Tor doesn't do UDP so it handles DNS by asking the exit node to do a DNS query and trusts the result. I could configure Unbound to query DNS over TCP only, and route via local tor, if that would solve it (= if most exit nodes will allow port 53, and if most DNS servers speak TCP). I'm also happy to run a DNS anonymising node if there is a tor equivalent specific to DNS, if it will help others (this might let me merge my traffic with general DNS queries) but does such a thing exist?

So my current risk model is probably something like this -

  • Poisoned/invalid data;
  • Logging/monitoring at the server(s), and modification/monitoring "on the wire";
  • Tying queries to source IP / DNS anonymisation.
    If I don't use DNS proxying/anonymisation, then there's only 2 options. I can resolve everything myself from root servers down, in which case I trust every DNS server on every domain not to log queries which is unlikely, but identifying query targets is less easy since the resulting subdomain queries are very widely distributed. If I use a public resolver I place "all my eggs in one basket" as they see the entire target domain, not just parts of it, and I'm trusting them not to be logged which may also be unrealistic. So DNS anonymisation seems necessary, but it's not clear if it's realistic.

I'm happy to put in the work to resolve this, and I'm sure I can improve on what I'm doing. But workarounds will be needed, since DNS is fundamentally insecure.

Given the current state of DNS and the current state of anonymising technologies, what is my best approach to threat mitigation for DNS queries?

Stilez
  • 1,664
  • 8
  • 13
  • You may want to look into DNS over TLS which is now a standard. – forest Apr 17 '18 at 10:51
  • That might (or might not? unsure) solve "on the wire", ar least as far as it's supported by the DNS servers for arbitrary domains I might use. But not the privacy issue at the server end, nor use of a single external resolver vs local resolver. So it's useful partial info, but really needs a full answer. – Stilez Apr 17 '18 at 15:25
  • Precisely why I put it in a comment rather than a new answer. Note also that when you use Tor for DNS (the DNSPort option can do that), you have to trust the resolvers the exit node uses. – forest Apr 18 '18 at 02:20

1 Answers1

2

In short, either install a DNSSEC enabled resolver with QNAME minimization (RFC 7816) on your computer or use DNS over TLS (RFC 7858) towards a remote server you trust/control.

Now in more details, as the previous setup caters for different cases, and can also be combined in some way.

First DNSSEC is not something that you can just use on your side to be applied everywhere, and it is not something that will help for privacy. For zones that are DNSSEC enabled (that have signatures), if you resolver validates them, then you have the guarantee of authenticity (you could not get fake data) and integrity (things could not be changed or downgraded). This is useful and solves some issue but:

  1. not all domain names are DNSSEC enabled, far from it even
  2. it does not prevent anyone reading your DNS traffic as it remains in clear, both the request and the replies

So if you do that, you must trust your ISP or anyone on the network not to sniff your traffic. Anyone will be able to watch your DNS messages, and alter the one not DNSSEC enabled.

The other option is to connect with TLS to some remote DNS server that speaks this new protocol. This gives you two benefits:

  1. noone will be able to snoop, nor change, your DNS messages as they are all protected by TLS, and this applies to both DNSSEC and not DNSSEC enabled domains
  2. the authoritative nameservers you query will only see the other nameserver IP and never yours.

Of course a poor man's alternative would be to do an IPSEC or SSH tunnel, to get almost the same benefits, however not without some complexities, as you need to handle both UDP and TCP. Or a SOCKS proxy. But since DNS over TLS is a standard now (at least a RFC) it may make more sense to pursue this way instead.

I said you need to trust/control this remote DNS server because obviously it will see all your DNS traffic. So it depends on you to define who you can trust or not. Some public open DNS providers do also provide DNS over TLS nowadays, for example CloudFlare: https://developers.cloudflare.com/1.1.1.1/dns-over-tls/ but you can find many other ones here: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers

If you need to use such nameservers that you do not control completely, some may advise you to set things up in such a way that you use multiple ones and that you spread your queries among them, so that no single one could reconstruct your whole DNS session. A little more complicated to put in place as this is not the standard way a list of nameservers operate by default.

As a side note, the standard of DNS over HTTPS is currently cooking and should arrive "soon". I guess that many providers will offer this service, so you will have the same dilemas as today with VPN providers (who to trust, etc.)

Also you said "But each DNS server only sees one component of the domain, they don't get to see the entire target." which is wrong in practice today. The protocol allows that but for various reasons since no one remembers when, the recursive nameservers were sending the whole name (each label) to each authoritative nameserver at each step. It is only now with QNAME minimization standard (RFC 7816) that resolvers can do the traversal by sending only one label each time. This is not without problems, as some nameservers do not cope with that (hence some recursive ones implemented a fallback strategy: first try with QNAME minimization and if it fails start again with full name as before)

Patrick Mevzek
  • 1,748
  • 2
  • 10
  • 23