Upstream DNS providers

For those fascinated by DNS–and who isn’t?–here is a worthwhile conversation between Ryan K of Cloudflare and Bill Woodcock of Quad9.

Though much is of interest to those here, I think Woodcock’s point that everyone should run their own recursive DNS seems worth underscoring. It is also quite informative the number of leaks and/or parties involved in DNS queries.

4 Likes

There are currently 9 pages, the Quad9 person appears on the first page, Cloudflare on the third. I end reading on the 4th due to other multitasking issues.

1 Like

Interesting discussion. Thanks for posting.

I currently use Cloudfare (as an alternative to Google), but I would love to switch to a fully non-commercial DNS provider.

For those of you using dnscrypt, which providers do you guys have enabled?

# Server names to never use even if they match the criteria below. I think
# Cloudflare is too big and as it gets selected by default everywhere other
# resolvers won't even get attempted. There is also Mozilla planning to send
# all Firefox DNS queries to them.
# This is unsupported in the Debian's version 2.0.19.
disabled_server_names = ['public-cloudflare-ipv6', 'public-cloudflare']

# Requirements for which servers to use
ipv4_servers = true
ipv6_servers = true
block_ipv6 = false
require_dnssec = true
require_nofilter = true
require_nolog = true
...
[sources]
  [sources.'public-resolvers']
  #url = 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md'
  urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md', 'https://cdn.staticaly.com/gh/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md', 'https://evilvibes.com/list/public-resolvers.md']
  cache_file = '/var/cache/dnscrypt-proxy/public-resolvers.md'
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  refresh_delay = 72
  prefix = 'public-'

[sources.'opennic']
 urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/opennic.md', 'https://download.dnscrypt.info/resolvers-list/v2/opennic.md']
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  refresh_delay = 72
  cache_file = '/var/cache/dnscrypt-proxy/opennic.md'
  prefix = 'opennic-'

# 2.0.23 recommended so onions won't be attempted without proxy enabled
# (5c9edfccfe67474bee2836ada67f955f10e43357)
# I won't uncomment this until I have updated version everywhere.
[sources.'onion-services']
  urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/onion-services.md', 'https://download.dnscrypt.info/resolvers-list/v2/onion-services.md']
  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
  cache_file = '/var/cache/dnscrypt-proxy/onion-services.md'
  prefix = 'onion-'

so I am using all resolvers from https://github.com/DNSCrypt/dnscrypt-resolvers/ which support DNSSEC and don’t log or filter queries, except that I am never using Cloudflare without Tor (and with Tor only if it happens to be one of the two fastest resolvers which is unlikely).

1 Like

There were around 7 when I went through it. I’m a bit disappointed more people weren’t interested in the conversation.

Going from memory, the Cloudflare guy disappeared. There was some drama about a privileged IP they get to use. The Quad9 guy also argued that DNS-over-TLS should be the preferred solution from a security/privacy point of view, while HTTP-over-TLS, he claimed, is quite leaky and has a number of known attacks. He also disliked DNSCrypt, although the claim there was mostly that it was non-standard. If someone with more technical understanding than I goes through it, I’d love to hear an assessment.

1 Like

To add to my last comment, the Quad9 guy said he’d do an AMA sort of thing on Quora. I don’t think anyone took him up on that. It would be pretty cool if someone who knows DNS were to put a bunch of security and privacy related questions to him there.

1 Like

I remember that the dnscrypt-proxy person had a nice analysis somewhere at GitHub, however I cannot seem to find it.

However I found a Reddit thread where they and the Quad9 person talk about this:

DNSPrivacy also had an interesting link, of which I didn’t recognise all the names:

https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+-+The+Solutions


Without being an expert, I think the biggest is going to be DNS over TLS or DNS over HTTPS. I like dnscrypt-proxy, but it didn’t become a standard and I don’t know any other bigger app that supports it, while DoT is supported by Android 9 (another thread Behaviour of Android 9 Private DNS with restricted networks and a quick comparsion of DNS over TLS providers (or why I use Quad9) if you don’t mind a bit of self-advertising) and systemd, while DoH is supported by Firefox and Intra by Jigsaw by Alphabet (Google).

I am under impression that sysadmins prefer DNS over TLS as it can be blocked easily and thus they can be more aware on what is happening on their network and in some cases it can be used as additional malware/phishing protection like Quad9, OpenDNS and many others are doing.

However for users DNS over HTTPS tends to be better, because it’s so difficult to block and I have heard it getting through work DNS based filtering and also getting through internet censorship and some ISPs in the UK wanted to make Mozilla villain of the year for bringing support for it.

Update : It looks like ISPA is now in full retreat and have pulled the Mozilla nomination entirely, but not before issuing a “sorry not sorry” press release:

Read @ISPAUK 's full statement about this year’s Internet Villain nomination here: https://t.co/JjVhLsmCJn pic.twitter.com/R9Eu55Sovy

— Internet Services Providers Association (ISPAUK) (@ISPAUK) July 9, 2019

Also as an user, I think many public WLANs have blocked DNS over TLS (853) by default as it’s not usual DNS (53), HTTP (80) or HTTPS (443) which are probably the minimum ports to not break everything. I also don’t know what are the contact details with public WLANs, I asked Helsinki Libraries for them once and received something, but I never contacted there, but maybe it would be worth trying with DNS over TLS and surely public transport has some idea who maintains their networks. I imagine the answer would be no though, either because of wanting to see what users do or fearing DNS filtering evading (if they do any) or maybe some other reason I cannot think of right now.

EDIT: I also forgot to say that DNS over TLS is currently the only one with attempting to automatically connect to DNS server in case it supports DoT so it doesn’t centralize everything on a bigger server like seems to be happening with Firefox/DoH/Cloudflare.

1 Like

Wow! Thanks for the bouquet of links. Will take some time to digest.

Perhaps you mean the FAQ?: https://dnscrypt.info/faq/

1 Like

No, I am sure it was something at GitHub, but that FAQ looks more in-depth than what I remember.

Missing link, thanks Atavic at GitHub:

https://tools.ietf.org/id/draft-livingood-doh-implementation-risks-issues-03.html

I may be misremembering it as I just find multiple comments like (I am not sure if there is a point in quoting):

No. DNS-over-TLS is useless, and will be quickly obsoleted by DoH.

I guess DoH would be a safe bet, please just implement those recommendations from Centralized DNS over HTTPS (DoH) Implementation Issues and Risks as it’s currently the biggest plus I see for DoT over DoH.

https://datatracker.ietf.org/doc/draft-ietf-doh-resolver-associated-doh/

You inspired me to go back to the original thread. Of the more useful parts:

496092:

I think running one’s own caching resolver is a necessary piece. I think QNAME minimization is a necessary piece. I think link encryption is a necessary piece. I wish we didn’t have to take for granted that DNSSEC validation doesn’t happen locally on the client, but for now, we pretty much do. Which is unfortunate. That puts DNSSEC validation out at the resolver. Cloudflare and Google have both now added DNSSEC validation, which is great. So now you need to make sure that you’re actually talking to a validating resolver, which turns out to be more difficult that you might assume… DANE authentication of the resolver isn’t quite there yet, which means you’re dependent on a self-signed or a CA cert. Self-signed without DANE causes problems in the form of pesky interruptive questions for the user, which brings us down to a CA cert. Which we can’t trust, because of “domain validation.” So there’s a serious unsolved problem. Also, we can’t restrict what certs the client will accept, for most client OSes. And it turns out that we can’t even restrict what DNS server the client will use, for the publicly-distributed versions of iOS and Android. iOS is a lot safer than Android, but it still doesn’t compartmentalize DNS queries during captive portal traversal, which is a huge, huge security fail, which I’ve been bugging Apple product security about for eleven years, now. I’d hoped that MDM would let me lock down some of these things, but no, it turns out that it doesn’t. Which brings us back to moving the DNSSEC validation back into the client. Anything else has way too many externalities.

496788:

We also recommend against DNS-over-HTTPS, because while it’s sufficient in theory, that wasn’t what it was intended for in practice. HTTPS implementations are notoriously data-leaky, which means they’re fingerprintable. So, people who are capturing and monetizing user data see DoH as serving their needs in a way DoT does not, because it allows them to track users as they move from IP address to IP address, because of fingerprintability of the HTTPS implementation. Also, the proponents of DoH are, principally CDNs, Content Delivery Networks, who see consolidation of DNS service onto their “platform” as a tool for violating net neutrality. If you were CDN A, and you could convince people to send you their DNS queries (particularly over DoH), you would have special knowledge of what queries were coming next in any sequence of web page loads, and you could pre-feed those answers down to the client as “additional information,” yielding faster performance for clients loading only that content which was hosted on your platform, and slower performance for all the content hosted on your competitors’ platforms, even before you intentionally slowed down queries yielding answers pointing at your competitors. Moreover, any time there was a choice between directing clients to results on your platform and results on your competitors’ platforms, you could always direct them to your own, increasing your revenue at the client’s (and content publisher’s) expense.

The entirety of the last post, only partially quoted, seems worth looking at.

1 Like

Oh, I have still forgotten to read this and it has even dropped from my tab pile, but we have added encrypted DNS providers on the website.

1 Like