1.1.1.1: Fast, privacy-first consumer DNS service | Hacker News Reader

1.1.1.1: Fast, privacy-first consumer DNS service

blog.cloudflare.com

1,895 points_l4jh657 comments

And look at these ping times:

                                   CloudFlare       Google DNS       Quad9            OpenDNS          
  NewYork                            2 msec           1 msec           2 msec           19 msec          
  Toronto                            2 msec           28 msec          17 msec          27 msec          
  Atlanta                            1 msec           2 msec           1 msec           19 msec          
  Dallas                             1 msec           9 msec           1 msec           7 msec           
  San Francisco                      3 msec           21 msec          15 msec          20 msec          
  London                             1 msec           12 msec          1 msec           14 msec          
  Amsterdam                          2 msec           6 msec           1 msec           6 msec           
  Frankfurt                          1 msec           9 msec           2 msec           9 msec           
  Tokyo                              2 msec           2 msec           81 msec          77 msec          
  Singapore                          2 msec           2 msec           1 msec           189 msec         
  Sydney                             1 msec           130 msec         1 msec           165 msec

Very impressive CloudFlare.

Where are you testing from? I'm going to guess: a datacenter. Residential customers won't see anything this fast. I'm in a small town in Kansas, connected by 1 Gbit ATT fiber. I'm getting ~26ms to 1.1.1.1 and ~19ms to my private DNS resolver that I host in a datacenter in Dallas. Google DNS comes in around 19ms.

I suspect that Cloudflare and Google DNS both have POPs in Dallas, which accounts for the similar numbers to my private resolver. My point is, low latencies to datacenter-located resolver clients is great but the advantage is reduced when consumer internet users have to go across their ISP's long private fiber hauls to get to a POP. Once you're at the exchange point, it doesn't really matter which provider you choose. Go with the one with the least censorship, best security, and most privacy. For me, that's the one I run myself.

Side note: I wish AT&T was better about peering outside of their major transit POPs and better about building smaller POPs in regional hubs. For me, that would be Kansas City. Tons of big ISPs and content providers peer in KC but AT&T skips them all and appears to backhaul all Kansas traffic to DFW before doing any peering.

Keep in mind that ping time isn't the only factor in DNS lookup speed. For me (sonic.net in Palo Alto):

ping 1.1.1.1: ~22ms

ping 8.8.8.8: ~19ms

dig @1.1.1.1: ~45ms

dig @8.8.8.8: ~70ms

Disclaimer: Eyeballed averages over a few samples. A more rigorous test of DNS lookup times would be cool to see.

Disclosure: I work for Cloudflare, but not on DNS.

ICMP round-trip times don't necessarily prove anything - you need to be examing DNS resolution times.

Lots of network hardware (i.e., routers, firewalls if they're not outright blocking) de-prioritise ICMP (and other types of network control/testing traffic) and the likelihood is that Google (and other free DNS providers) are throttling the number of ICMP replies that they send.

They're not providing an ICMP reply service, they're providing a DNS service. I'd a situation during the week where I'd to tell one of our engineers to stop tracking 8.8.8.8 as an indicator of network availability for this reason.

Using namebench[0], CloudFlare is about the 6th fastest for me. Just ahead of google.

1) Level3

2) DynGuide

3) UltraDNS

4) OpenDNS

5) Quad9

6) CloudFlare

7) Google

[0] https://code.google.com/archive/p/namebench/

Note, from Google Compute Engine use 8.8.8.8 as it should always be faster. I'm guessing the 8.8.8.8 service exists in every Google Cloud region. Even better use the default GCE autogenered DNS IP that they configure in /etc/resolv.conf to get instance name resolving magic.

How is this possible from a single location? The speed of light in a vacuum is ~200 miles per millisecond.

Interestingly having routing problems to China for 1.1.1.1 (but not 1.0.0.1): http://ping.pe/1.1.1.1

Poznań, Poland

    1.1.1.1: ~17ms (the first one took 179ms, but after that it's pretty fast)
    8.8.8.8: ~16ms

From London on a residential ADSL connection:

  8.8.8.8 - ping 7ms dig 14ms
  8.8.4.4 - ping 7ms dig 16ms
  1.1.1.1 - ping 7ms dig 16ms
  1.0.0.1 - ping 6ms dig 15ms
  
  9.9.9.9 - ping 6ms dig 17ms

CF & Google about the same for me. Good to have an alternative in CF though, and certainly a very memorable IP :)

I'm in a city in southern Japan (so most of my traffic needs to go to Tokyo first), on a gigabit fiber connection.

    --- 1.1.1.1 ping statistics ---
    rtt min/avg/max/mdev = 30.507/32.155/36.020/1.419 ms

    --- 8.8.8.8 ping statistics ---
    rtt min/avg/max/mdev = 19.618/21.572/23.009/0.991 ms

The traceroutes are inconclusive but they kind of look like Google has a POP in Fukuoka and CloudFlare are only in Tokyo.

edit: Namebench was broken for me, but running GRC's DNS Benchmark my ISP's own resolver is the fastest, then comes Google 8.8.8.8, then Level3 4.2.2.[123], then OpenDNS, then NTT, and then finally 1.1.1.1.

Pretty sure that google time for Sydney is an outlier

This is from my residential ADSL2 connection in Sydney:

  [Bigs-MacBook-Pro-2:~] bigiain% ping 8.8.8.8
  PING 8.8.8.8 (8.8.8.8): 56 data bytes
  64 bytes from 8.8.8.8: icmp_seq=0 ttl=59 time=21.257 ms
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=25.831 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=22.231 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=21.498 ms
  ^C
  --- 8.8.8.8 ping statistics ---
  4 packets transmitted, 4 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 21.257/22.704/25.831/1.841 ms
  [Bigs-MacBook-Pro-2:~] bigiain% ping 1.1.1.1
  PING 1.1.1.1 (1.1.1.1): 56 data bytes
  64 bytes from 1.1.1.1: icmp_seq=0 ttl=59 time=22.481 ms
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=38.814 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=19.923 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=19.911 ms
  ^C
  --- 1.1.1.1 ping statistics ---
  4 packets transmitted, 4 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 19.911/25.282/38.814/7.882 ms

And this is from an ec2 instance is ap-southeast-2:

  ubuntu@ip-172-31-xx-xx:~$ ping 8.8.8.8
  PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=2.24 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=2.27 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=2.30 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=2.26 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=2.31 ms
  64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=2.25 ms
  ^C
  --- 8.8.8.8 ping statistics ---
  6 packets transmitted, 6 received, 0% packet loss, time 5007ms
  rtt min/avg/max/mdev = 2.244/2.274/2.310/0.066 ms
  ubuntu@ip-172-31-xx-xx:~$ ping 1.1.1.1
  PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=1.03 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=1.05 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=1.05 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=1.01 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=55 time=1.07 ms
  ^C
  --- 1.1.1.1 ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4004ms
  rtt min/avg/max/mdev = 1.015/1.046/1.076/0.035 ms

From Hyderabad, India

Cloudflare:

Reply from 1.0.0.1: bytes=32 time=119ms TTL=56

Reply from 1.0.0.1: bytes=32 time=74ms TTL=56

GoogleDNS:

Reply from 8.8.8.8: bytes=32 time=44ms TTL=55

Reply from 8.8.8.8: bytes=32 time=43ms TTL=55

Reply from 8.8.8.8: bytes=32 time=44ms TTL=55

Cafe in Chiang Rai, Thailand:

    $ ping -n 1.1.1.1
    round-trip min/avg/max/stddev = 16.696/18.643/22.571/2.056 ms

    $ ping -n 8.8.8.8
    round-trip min/avg/max/stddev = 38.410/45.663/57.684/8.075 ms

"And look at these ping times ..."

I would be interested to hear from google (8.8.8.8) how much ping traffic that address gets ...

I know that I will quickly ping 8.8.8.8 as a very quick and dirty test of network up ... its just faster to type than any other address I could test with.

It looks like you are testing either from centers where cloudflare has servers or exchanging traffic with, which is likely true in a data center given the traffic it transports. What most users want is the ping time from home/office.

Cape Town, South Africa, Residential ADSL

    1.1.1.1 ~ 26ms
    8.8.8.8 ~ 42ms

Pasadena, CA

1.1.1.1 continually timed out.

1.0.0.1 succeeded

18 packets transmitted, 18 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 10.178/11.128/12.585/0.576 ms

I assume a cable modem adds at least 8ms of latency, because I get 8ms of latency to my default router, and about 12-15ms to any of those hosts.

I live I Greece, Google’s DNS are 20-30% faster.

DNS-over-HTTPS doesn’t make as much sense to me as DNS-over-TLS. They are effectively the same thing, but HTTPS has the added overhead of the HTTP headers per request. If you look at the currently in progress RFC, https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-04, this is quite literally the only difference. The DNS request is encoded as a standard serialized DNS packet.

The article mentions QUIC as being something that might make HTTPS faster than standard TLS. I guess over time DNS servers can start encoding HTTPS requests into JSON, like google’s impl, though there is no spec that I’ve seen yet that actually defines that format.

Can someone explain what the excitement around DNS-over-HTTPS is all about, and why DNS-over-TLS isn’t enough?

EDIT: I should mention that I started implementing this in trust-dns, but after reading the spec became less enthusiastic about it and more interested in finalizing my DNS-over-TLS support in the trust-dns-resolver. The client and server already support TLS, I couldn't bring myself to raise the priority enough to actually complete the HTTPS impl (granted it's not a lot of work, but still, the tests etc, take time).

Some ISPs block outbound DNS from customers to anywhere but their resolvers, filtering based on target port. This is a particularly common trick in countries that attempt to censor the internet.

It's a lot harder to do that with DNS-over-HTTPS because it looks like normal traffic.

That said, in this case ISPs can just null route the IP address of the obvious main resolvers such as 1.1.1.1. I imagine most of the benefit is surely to people who can spin up their own resolvers.

1.1.1.1 does support DNS-over-TLS as well: https://developers.cloudflare.com/1.1.1.1/dns-over-tls/

One of the use cases for DNS-over-HTTPS given in the draft was to allow web applications access to DNS directly via existing browser APIs.

Cloudflare addresses this in the blog post:

There are a couple of different approaches. One is DNS-over-TLS. That takes the existing DNS protocol and adds transport layer encryption. Another is DNS-over-HTTPS. It includes security but also all the modern enhancements like supporting other transport layers (e.g., QUIC) and new technologies like server HTTP/2 Server Push. Both DNS-over-TLS and DNS-over-HTTPS are open standards. And, at launch, we've ensured 1.1.1.1 supports both.

We think DNS-over-HTTPS is particularly promising — fast, easier to parse, and encrypted.

Dns over https would be harder for governments and other middleman to block or intercept, despite it being less efficient. It would look like any other https request. Especially if browsers agreed to universally support it.

rfc 8336. h2 coalescing. h2 push. caching. it starts to add up to a very interesting story.

How is any of this more secure against your ISP in any case given someone willing to do reverse lookup‘s on IP addresses?

If someone controls routers is it not nearly useless?

So for example all mobile 4g providers could laugh at this and build a nearly as good database of every site you visit?

How much overhead? Is the request or response larger than a single packet?

>The article mentions QUIC as being something that might make HTTPS faster than standard TLS.

Even with TLS 1.3 0-RTT?

TIL you can also use 1.1 and it will expand to 1.0.0.1

  $> ping 1.1

  PING 1.1 (1.0.0.1) 56(84) bytes of data.
  64 bytes from 1.0.0.1: icmp_seq=1 ttl=55 time=28.3 ms
  64 bytes from 1.0.0.1: icmp_seq=2 ttl=55 time=33.0 ms
  64 bytes from 1.0.0.1: icmp_seq=3 ttl=55 time=43.6 ms
  64 bytes from 1.0.0.1: icmp_seq=4 ttl=55 time=41.7 ms
  64 bytes from 1.0.0.1: icmp_seq=5 ttl=55 time=56.5 ms
  64 bytes from 1.0.0.1: icmp_seq=6 ttl=55 time=38.4 ms
  64 bytes from 1.0.0.1: icmp_seq=7 ttl=55 time=34.8 ms
  64 bytes from 1.0.0.1: icmp_seq=8 ttl=55 time=45.7 ms
  64 bytes from 1.0.0.1: icmp_seq=9 ttl=55 time=45.2 ms
  64 bytes from 1.0.0.1: icmp_seq=10 ttl=55 time=43.1 ms

The most useful case for this shortcut is 127.1 -> 127.0.0.1

You can also use the decimal value of the IP, without the dots: https://16843009

Interesting question related to this : https://superuser.com/questions/486788/why-does-pinging-192-...

  1.2 -> 1.0.0.2
  1.2.3 -> 1.2.0.3

But then, much of software would fail here - Firefox/Chrome for example would both threat that as bareword and redirect to search page.

I wish that they talked a bit more about their stance regarding censorship. They have a small paragraph talking about the problem, but they don't talk about the "solution".

While Cloudflare has been pretty neutral about censoring sites in the past (notably, pirate sites), the Daily Stormer incident put them in a though spot[1].

They talk a bit about Project Galileo (the link is broken BTW, it should be https://www.cloudflare.com/galileo), but their examples do not mention topics that would be controversial in western societies, and the site is quite vague. Would they also protect sites like sci-hub, for example?

While I would rather use a DNS not owned by Google, I have never seen any site blocked by them, including sites with a nation-wide block. I hope that Cloudflare is able to do the same thing.

1: https://torrentfreak.com/cloudflare-doesnt-want-daily-storme...

There's a pretty big difference between terminating a business relationship (which is what Cloudflare did to Daily Stormer, and which Google also did a couple days before Cloudflare did) and refusing to answer DNS queries for third-party domains with which there is no business relationship. It's hard to imagine how the former could be used as precedent to compel the latter.

Cloudflare has no interest in censorship -- the whole reason the Daily Stormer thing was such a big deal was because it's the only time Cloudflare has ever terminated a customer for objectionable content. Be sure to read the blog post to understand: https://blog.cloudflare.com/why-we-terminated-daily-stormer/

(Disclosure: I work for Cloudflare but I'm not in a position to set policy.)

Bear in mind, they dropped Daily Stormer because they were claiming Cloudflare agreed with their ideology. Which someone in the previous discussion pointed out was a Terms of Service violation.

DNS resolving offers no such terms and no such reason to make such a claim. I don't see that playing here. And bear in mind, when the CEO did it, he wrote about how dangerous it was that companies had that power. I don't feel other companies running other DNS services hold that level of concern or awareness.

When you consider that their "competitor" in the space of free DNS resolvers with easy-to-remember IPs is Google, who recently tried blocking the word "gun" in Google Shopping... it's hard not to see the introduction of a Cloudflare DNS resolver as at least a net positive for resisting censorship. And more options is almost always better.

Actually, they have already suspended the service for sci-hub, albeit under a court order.

https://yro.slashdot.org/story/18/02/05/1944225/cloudflare-t...

The Galileo link works for me. It's worth pointing out Google at the very least censors as easily as Cloudflare [1].

My understanding of Cloudflare's policies though are with the exception of exceptionally objectionable content, Cloudflare only takes sites down in response to a court order. I don't know if it has been established that DNS is something which operators have a proactive obligation to censor, but I imagine it's the kind of thing Cloudflare would go to court over.

1- https://www.vox.com/policy-and-politics/2017/8/14/16143820/g...

"I wish that they talked a bit more about their stance regarding censorship. They have a small paragraph talking about the problem, but they don't talk about the "solution"."

I think there's a good way to put this to the test - establish a DNS "mixer" that will randomly direct DNS requests to either 1.1.1.1 or 8.8.8.8 or (whatever) and let the public have access to it.

In this way, Cloudflare would bear some small expense from processing these DNS requests (essentially zero) but would receive no information about the initial requestor.

It would be interesting to run this experiment and perhaps see some real traffic on the DNS mixer ... and then see how cloudflare responds.

Would they block the mixer ?

For the Cloudflare folks hanging around:

Please, please, please add some basic "features" (like Google does) that will help when troubleshooting resolution!

For example, the following will show the unicast IP address of the server you're hitting when using 8.8.8.8:

  $ dig @8.8.8.8 txt o-o.myaddr.l.google.com. +short

Additionally, with one other DNS query, we can get a list of what netblocks are being used (for Google Public DNS) in what datacenters/locations:

  $ dig @8.8.8.8 txt locations.publicdns.goog. +short

(This same info, along with a small shell script to format it nicely, is available on their web site [0] as well.)

[0]: https://developers.google.com/speed/public-dns/faq

Thank you for the suggestions. I'll make sure they get relayed to the team.

There's a public list of IP ranges on the website: https://www.cloudflare.com/ips/

There's troubleshooting utilities in the CHAOS class, e.g. dig @1.1.1.1 id.server ch txt

I think i have questions to Google:

  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
  "74.125.46.8"
  "edns0-client-subnet 92.223.114.166/32"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
  "74.125.46.11"
  "edns0-client-subnet 176.36.247.0/24"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
  "74.125.74.3"
  "edns0-client-subnet 94.181.44.185/32"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
  "74.125.46.8"
  "edns0-client-subnet 92.223.114.166/32"
  [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
  "74.125.74.3"
  "edns0-client-subnet 94.181.44.185/32"

This is the Cloudflare resolver, right? What's the "privacy-first" part about? It's just another third party DNS host. They haven't changed the protocol to be uninspectable and AFAIK haven't made any guarantees about logging or whatnot that would enhance privacy vs. using whatever you are now. This just means you're trusting Cloudflare instead of Comcast or Google or whoever.

"We will never log your IP address (the way other companies identify you). And we’re not just saying that. We’ve retained KPMG to audit our systems annually to ensure that we're doing what we say."

Now, audits are generally not worth very much (even, perhaps even especially, from a Big Four group like KPMG), but for this type of thing (verifying that a company isn't doing something they promised they would not do) they're about the best we have.

Cloudflare is making a public pronouncement that they're not going to sell your DNS data nor track your IP address, with the implication that they will also not use the usage data to upsell you services. That's about the only additional "privacy" edge they offer.

In the same breath, they insinuate that Google both sells and uses DNS usage from their 8.8.8.8 and 8.8.4.4 resolvers.

Yes they have:

"Privacy First: Guaranteed. We will never sell your data or use it to target ads. Period. We will never log your IP address (the way other companies identify you). And we’re not just saying that. We’ve retained KPMG to audit our systems annually to ensure that we're doing what we say.

Frankly, we don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical steps to ensure we can’t."

I think the whole point for such free services is to log that data and extract statistical meaning out of it - in this case, they pledge to use an anonymized format. On the other hand CloudFlare's mission (ensure secure, solid end to end connectivity) is much better aligned with the user's needs than Google's mission (sell more ads).

On the contrary, they've taken 2 big steps that are better than ISPs (not sure about Google):

* no logging

* DNS over HTTPS

Did you read the page? They're supporting DNS over TLS and DNS over HTTPS - both changes to the protocol to make in uninspectable. They've also said they're not logging IP info and they're getting independent auditors in to confirm what they're saying. Sounds trustworthy to me

When I've seen DNS-over-HTTPS in the past I've always thought it odd that it's setup with a DNS name for the HTTPS address, requiring a plain DNS lookup before it starts using HTTPS. I assumed this was done because they didn't have a valid TLS cert for the IP address. But 1.1.1.1 actually has a valid TLS cert, yet their setup instructions say to use the DNS name cloudflare-dns.com instead of the IP.

https://developers.cloudflare.com/1.1.1.1/dns-over-https/

Is there a technical reason the DNS-over-HTTPS resolvers need their upstream resolvers to be looked up by name and not IP?

I suppose I see your point, but since DNS-over-HTTPS only supports HTTPS (not HTTP) and therefore requires a valid certificate for the requested resolver, there's no risk of the protocol being downgraded to HTTP or easily spoofed.

So what do you see as the threat profile?

From Shenzhen, China

1.1.1.1/1.0.0.1 rtt min/avg/max/mdev = 198.036/199.739/202.978/2.319 ms

8.8.8.8/8.8.4.4 rtt min/avg/max/mdev = 12.798/13.681/14.408/0.673 ms

114.114.114.114/114.114.115.115 rtt min/avg/max/mdev = 15.508/25.381/38.815/9.842 ms

Not surprising: Google despite being blocked in China a lot of presumably expensive paid transit from the big 3 mainland china telcos in and out of the mainland to Hong Kong.

Cloudflare serves sites visited from China that aren't using their China-requires-an-ICP-license service from their west coast USA location where the big 3 Chinese telcos will peer for free.

True...

Today I learned that it is possible to request a certificate for an IP address.

Yup, the Subject Alternative Name (often misunderstood as an alias, but "Alternative" here is meant in the sense of this is the Internet's _Alternative_ way to name things versus the X.500 series directory hierarchy that the X.509 certificates are originally intended for) can be one of several distinct types, the two relevant for servers are dnsName and ipAddress. dnsName can be any er, name, in the DNS hierarchy, or, as a special case, a "wildcard" with asterisks, whereas ipAddress can be any type of IP address, currently either IPv4 or IPv6.

The Baseline Requirements agreed between Web Browser vendors and root Certificate Authorities dictate how the CA can figure out if an applicant is allowed a certificate for a particular name, for dnsNames this is the Ten Blessed Methods, for ipAddress the rules are a bit... eh, rusty, but the idea is you can't get one for that dynamic IP you have from your cable provider for 24 hours, but somebody who really controls the IP address can get one. They're uncommon, but not rare, maybe a dozen a day are issued?

Your web browser requires that the name in the URL exactly matches the name in the certificate. So if you visit https://some-dns-server.example/ the certificate needs to be for some-dns-server.example (or *.example) and a certificate for 1.1.1.1 doesn't work, even if some-dns-server.example has IP address 1.1.1.1 - so this cert is only useful because they want people actually typing https://1.1.1.1/ into browsers...

[edited, I have "Servers" on the brain, it's _Subject_ Alternative Name, you can use them to name email recipients, and lots of things that aren't servers]

Edit: I had not realised what the parent comment here meant, that you can coonect to an IP address without getting an error by adding the IP to the SAN. My explanation bellow is about finding certs installed for a given IP/hotname, typically with openssl.

Yes, but...

This only works if they don't use SNI[1]. If they use SNI then you just get the default cert. They might have more certs for other hostnames served on that IP address.

1: https://en.wikipedia.org/wiki/Server_Name_Indication

Here's how to use it with DNS-over-HTTPS on OS X / MacOS:

    brew install dnscrypt-proxy
    Change line 25 in /usr/local/etc/dnscrypt-proxy.toml to server_names = ['cloudflare']
    sudo brew services restart dnscrypt-proxy

Then change your DNS server to 127.0.0.1 (run Network pref panel, unlock, Advanced, DNS)

And you can use this to control it from the menu bar: https://github.com/jedisct1/bitbar-dnscrypt-proxy-switcher/

Thanks! That setup breaks everytime I'm behind a captive portal (hotel) .. any work around that except changing it manually and back?!

So, one thing I'd love to see clarified: APNIC was interested in studying the junk traffic to 1.1.1.1. Cloudflare's DNS will not log or track. So what is logged and tracked for APNIC's research purposes? Everything but DNS? Everything but DNS and HTTPS requests directly to 1.1.1.1 (presumably people looking for details on Cloudflare DNS?).

What's being studied?

Fun fact: CCNA classes regularly use 1.1.1.1 as a router-id. Really good reason now not to configure it via a loopback address.

Some previous study on the space with an APNIC loan:

https://www.youtube.com/watch?v=RBOPcLpQZ8w

Really hoping this question gets answered. It seemed contradictory to me.

"Cloudflare's 1.1.1.1 DNS will respond very fast, but the big sites you access, the whole reason for resolving DNS, will be SLOWER ∵ no edns-client-subnet support, so no geolocation of results." - https://twitter.com/philpennock/status/980561009961299968

edns-client-subnet leads to a surprising number of privacy concerns. See: https://00f.net/2013/08/07/edns-client-subnet/ I find the cache timing issue particularly worrying.

Cloudflare runs from 151 (and growing rapidly) locations worldwide. Without edns-client-subnet, the upstream DNS server will probably respond according to the geolocation of the Cloudflare location you're talking to -- which is probably pretty close to you, and therefore will probably produce a good outcome for you, while largely avoiding the privacy concerns.

$ ping 1.1.1.1

PING 1.1.1.1 (1.1.1.1): 56 data bytes

64 bytes from 1.1.1.1: icmp_seq=0 ttl=47 time=214.866 ms

64 bytes from 1.1.1.1: icmp_seq=1 ttl=47 time=173.416 ms

64 bytes from 1.1.1.1: icmp_seq=2 ttl=45 time=256.007 ms

64 bytes from 1.1.1.1: icmp_seq=3 ttl=45 time=196.638 ms

64 bytes from 1.1.1.1: icmp_seq=4 ttl=45 time=294.694 ms

64 bytes from 1.1.1.1: icmp_seq=5 ttl=45 time=314.883 ms

64 bytes from 1.1.1.1: icmp_seq=6 ttl=47 time=335.099 ms

(From Singapore)

Google's 8.8.8.8 has about <4ms

Using ping to compare the two may introduce a skew based on how the two networks prioritize ICMP.

For example, from my network google is averaging a faster response by ~.5ms

    $ ping 1.1.1.1
    PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=28.0 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=19.2 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=19.1 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=19.0 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=20.5 ms
    64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=19.6 ms
    ^C
    --- 1.1.1.1 ping statistics ---
    6 packets transmitted, 6 received, 0% packet loss, time     5010ms
    rtt min/avg/max/mdev = 19.043/20.950/28.072/3.226 ms
    
    $ ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=19.1 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=20.1 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=20.6 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=21.1 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=21.9 ms
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=19.4 ms
    ^C
    --- 8.8.8.8 ping statistics ---
    6 packets transmitted, 6 received, 0% packet loss, time 5008ms
    rtt min/avg/max/mdev = 19.114/20.414/21.922/0.988 ms

However, if i do DNS lookups against a few major domains, google is actually slower by ~2ms

    $ for domain in microsoft.com google.com cloudflare.com facebook.com twitter.com; \
      do cloudflare=$(dig @1.1.1.1 ${domain} | awk '/msec/{print $4}'); \
        google=$(dig @8.8.8.8 ${domain} | awk '/msec/{print $4}');\
        printf "${domain}:\tcloudflare ${cloudflare}ms\tgoogle ${google}ms\n";\
      done
    microsoft.com:	cloudflare 22ms	google 23ms
    google.com:		cloudflare 19ms	google 22ms
    cloudflare.com:	cloudflare 19ms	google 23ms
    facebook.com:	cloudflare 21ms	google 20ms
    twitter.com:	cloudflare 19ms	google 21ms

You'd have to run a bunch of queries to see if there is an actual impact vs. just an outlier (e.g. the first ping response from cloudflare), just wanted to point it out.

Bangalore, India

  $ ping 1.1.1.1
  PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=13.8 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=14.6 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=13.7 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=14.1 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=13.7 ms
  64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=15.3 ms
  $ ping 8.8.8.8
  PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=43.5 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=42.3 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=43.1 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=46 time=42.0 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=46 time=42.4 ms

  PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=55 time=19.6 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=19.9 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=19.8 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=19.7 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=19.8 ms
  64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=19.7 ms
  64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=19.8 ms
  64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=19.7 ms
  64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=19.8 ms

  PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=0.390 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=0.565 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=0.472 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=0.556 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=0.560 ms
  64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=0.573 ms
  64 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=0.359 ms
  64 bytes from 1.1.1.1: icmp_seq=8 ttl=57 time=0.575 ms
  64 bytes from 1.1.1.1: icmp_seq=9 ttl=57 time=0.543 ms
  64 bytes from 1.1.1.1: icmp_seq=10 ttl=57 time=0.548 ms

From Zagreb, Croatia. I guess that new cloudflare POP is paying off.

Edit: formatting

Tokyo, Japan:

    [mason@iMac-Pro-No-5 fubastardo (master)]$  ping 1.1.1.1
    PING 1.1.1.1 (1.1.1.1): 56 data bytes
    64 bytes from 1.1.1.1: icmp_seq=0 ttl=56 time=2.310 ms
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=2.287 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=2.103 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=2.785 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=2.276 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=56 time=2.646 ms
    ^C
    --- 1.1.1.1 ping statistics ---
    6 packets transmitted, 6 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 2.103/2.401/2.785/0.236 ms
    [mason@iMac-Pro-No-5 fubastardo (master)]$ 
    [mason@iMac-Pro-No-5 fubastardo (master)]$ 
    [mason@iMac-Pro-No-5 fubastardo (master)]$ ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8): 56 data bytes
    64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=2.217 ms
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=1.837 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=1.838 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=2.010 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=1.827 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=2.056 ms
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=1.807 ms
    ^C
    --- 8.8.8.8 ping statistics ---
    7 packets transmitted, 7 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 1.807/1.942/2.217/0.145 ms
    [mason@iMac-Pro-No-5 fubastardo (master)]$

From Belgium, not much of a difference

        [:~] % ping 1.1.1.1
        PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
        64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=22.0 ms
        64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=21.1 ms
        64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=21.8 ms
        64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=21.0 ms
        64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=21.8 ms
        64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=21.2 ms
        ^C
        --- 1.1.1.1 ping statistics ---
        6 packets transmitted, 6 received, 0% packet loss, time 5009ms
        rtt min/avg/max/mdev = 21.023/21.509/22.031/0.399 ms
        [:~] % ping 8.8.8.8
        PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
        64 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=26.4 ms
        64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=26.6 ms
        64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=26.7 ms
        64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=26.4 ms
        64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=26.7 ms
        64 bytes from 8.8.8.8: icmp_seq=6 ttl=59 time=25.9 ms
        ^C
        --- 8.8.8.8 ping statistics ---
        6 packets transmitted, 6 received, 0% packet loss, time 5010ms
        rtt min/avg/max/mdev = 25.925/26.501/26.790/0.344 ms

>5x improvement over Google for me

  ~ ping -c 10 1.1.1.1
  PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=1.15 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.15 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=1.06 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=1.04 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=1.03 ms
  64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=1.01 ms
  64 bytes from 1.1.1.1: icmp_seq=7 ttl=64 time=1.02 ms
  64 bytes from 1.1.1.1: icmp_seq=8 ttl=64 time=1.07 ms
  64 bytes from 1.1.1.1: icmp_seq=9 ttl=64 time=1.00 ms
  64 bytes from 1.1.1.1: icmp_seq=10 ttl=64 time=0.848 ms

  --- 1.1.1.1 ping statistics ---
  10 packets transmitted, 10 received, 0% packet loss, time 9009ms
  rtt min/avg/max/mdev = 0.848/1.042/1.153/0.086 ms
  
  ~ ping -c 10 8.8.8.8
  PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=6.82 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=6.72 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=6.39 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=6.73 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=6.55 ms
  64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=6.14 ms
  64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=6.24 ms
  64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=6.22 ms
  64 bytes from 8.8.8.8: icmp_seq=9 ttl=56 time=6.19 ms
  64 bytes from 8.8.8.8: icmp_seq=10 ttl=56 time=6.30 ms

  --- 8.8.8.8 ping statistics ---
  10 packets transmitted, 10 received, 0% packet loss, time 9011ms
  rtt min/avg/max/mdev = 6.149/6.433/6.826/0.248 ms

From Bogotá, Colombia it is slightly faster than Google:

  ~% ping 1.1.1.1  
  PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=11.0 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=10.9 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=10.5 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=10.0 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=13.0 ms
  64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=10.1 ms
  ^C
  --- 1.1.1.1 ping statistics ---
  6 packets transmitted, 6 received, 0% packet loss, time 5006ms
  rtt min/avg/max/mdev = 10.037/10.953/13.052/1.010 ms

  ~% ping 8.8.8.8  
  PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=14.7 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=14.5 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=13.5 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=13.2 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=14.0 ms
  64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=14.8 ms
  ^C
  --- 8.8.8.8 ping statistics ---
  6 packets transmitted, 6 received, 0% packet loss, time 5008ms
  rtt min/avg/max/mdev = 13.260/14.151/14.823/0.585 ms

Here in London, Cloudflare seems a bit faster:

  $ ping 1.1.1.1
  PING 1.1.1.1 (1.1.1.1): 56 data bytes
  64 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=2.793 ms
  64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=3.010 ms
  64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=2.789 ms
  64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=2.963 ms
  64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=2.954 ms
  64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=1.330 ms
  ^C
  --- 1.1.1.1 ping statistics ---
  6 packets transmitted, 6 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 1.330/2.640/3.010/0.592 ms

  $ ping 8.8.8.8
  PING 8.8.8.8 (8.8.8.8): 56 data bytes
  64 bytes from 8.8.8.8: icmp_seq=0 ttl=61 time=6.531 ms
  64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=5.956 ms
  64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=7.300 ms
  64 bytes from 8.8.8.8: icmp_seq=3 ttl=61 time=7.457 ms
  64 bytes from 8.8.8.8: icmp_seq=4 ttl=61 time=6.796 ms
  64 bytes from 8.8.8.8: icmp_seq=5 ttl=61 time=6.785 ms
  ^C
  --- 8.8.8.8 ping statistics ---
  6 packets transmitted, 6 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 5.956/6.804/7.457/0.494 ms

Toronto - (ISP: Bell)

    $ ping 1.1.1.1
    PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=22.0 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=19.7 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=17.6 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=20.2 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=55 time=18.2 ms
    ^C
    --- 1.1.1.1 ping statistics ---
    5 packets transmitted, 5 received, 0% packet loss, time 4006ms
    rtt min/avg/max/mdev = 17.691/19.610/22.080/1.559 ms
    [normal@inspiron ~]$ ping 8.8.8.8
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=7.12 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=5.28 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=8.24 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=5.28 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=4.01 ms
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=6.37 ms
    ^C
    --- 8.8.8.8 ping statistics ---
    6 packets transmitted, 6 received, 0% packet loss, time 5007ms
    rtt min/avg/max/mdev = 4.014/6.053/8.240/1.380 ms

Vancouver, BC, Canada

    $ ping -c 10 1.1.1.1
    PING 1.1.1.1 (1.1.1.1): 56 data bytes
    64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=1789.957 ms
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=19.620 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=9.372 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=11.585 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=20.660 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=60 time=11.808 ms
    64 bytes from 1.1.1.1: icmp_seq=6 ttl=60 time=12.784 ms
    64 bytes from 1.1.1.1: icmp_seq=7 ttl=60 time=11.908 ms
    64 bytes from 1.1.1.1: icmp_seq=8 ttl=60 time=11.373 ms
    64 bytes from 1.1.1.1: icmp_seq=9 ttl=60 time=11.992 ms
    --- 1.1.1.1 ping statistics ---
    10 packets transmitted, 10 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 9.372/191.106/1789.957/532.962 ms

    $ ping -c 10 8.8.8.8
    PING 8.8.8.8 (8.8.8.8): 56 data bytes
    64 bytes from 8.8.8.8: icmp_seq=0 ttl=60 time=1308.156 ms
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=17.557 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=13.043 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=16.217 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=60 time=15.033 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=60 time=15.132 ms
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=60 time=14.157 ms
    64 bytes from 8.8.8.8: icmp_seq=7 ttl=60 time=16.100 ms
    64 bytes from 8.8.8.8: icmp_seq=8 ttl=60 time=15.600 ms
    64 bytes from 8.8.8.8: icmp_seq=9 ttl=60 time=13.837 ms
    --- 8.8.8.8 ping statistics ---
    10 packets transmitted, 10 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 13.043/144.483/1308.156/387.893 ms

PING 1.1.1.1 (1.1.1.1): 56 data bytes

64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=2.099 ms

64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=2.073 ms

64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=1.963 ms

64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=2.089 ms

PING 8.8.8.8 (8.8.8.8): 56 data bytes

64 bytes from 8.8.8.8: icmp_seq=0 ttl=60 time=1.908 ms

64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=1.888 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=1.993 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=1.891 ms

From SG too. Could it be... just you?

If pings are anything to go by I should probably stay with Google (or my ISP, they ping at 1ms):

Pinging 8.8.8.8 with 32 bytes of data:

Reply from 8.8.8.8: bytes=32 time<1ms TTL=57

Reply from 8.8.8.8: bytes=32 time=1ms TTL=57

Reply from 8.8.8.8: bytes=32 time<1ms TTL=57

Pinging 1.1.1.1 with 32 bytes of data:

Reply from 1.1.1.1: bytes=32 time=6ms TTL=57

(Switzerland)

From Norway (fiber), seems to be a bit faster than google:

$ ping -c 5 1.1.1.1

PING 1.1.1.1 (1.1.1.1): 56 data bytes

64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=1.606 ms

64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=1.562 ms

64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=1.540 ms

64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=1.574 ms

64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=1.564 ms

--- 1.1.1.1 ping statistics ---

5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.540/1.569/1.606/0.022 ms

$ ping -c 5 8.8.8.8

PING 8.8.8.8 (8.8.8.8): 56 data bytes

64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=9.068 ms

64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=8.923 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=8.974 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=8.916 ms

64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=8.931 ms

--- 8.8.8.8 ping statistics ---

5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 8.916/8.962/9.068/0.057 ms

Rome: about the same for me.

PING 8.8.8.8 (8.8.8.8): 56 data bytes

64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=19.145 ms

64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=18.927 ms

64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=19.258 ms

64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=20.000 ms

64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=20.428 ms

PING 1.1.1.1 (1.1.1.1): 56 data bytes

64 bytes from 1.1.1.1: icmp_seq=0 ttl=53 time=21.351 ms

64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=18.606 ms

64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=19.451 ms

64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=19.084 ms

64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=18.989 ms

Near Lisbon on residential FTTH:

           ping    dig
           ----------------
  1.1.1.1  3.2     4
  1.0.0.1  2.9     4
  8.8.8.8  36.5    40
  8.8.4.4  36.3    42

These are only averages though, and by testing a bit more with uncached domains I found the first hit will take a lot longer with cloudflare than with google.

Colorado, US

1.1.1.1 round-trip min/avg/max/stddev = 10.984/12.221/14.909/1.239 ms

8.8.8.8 round-trip min/avg/max/stddev = 11.022/12.702/15.102/1.317 ms

Sorry man :(

Things are a bit quicker in the US:

64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=0.421 ms

64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=0.645 ms

Anycast is not based on latency, so that's normal.

Google's ones are also faster here by 8ms (Cyprus)

I get roughly the same 45-48ms from the EU for both.

Both are not fast in China. :(

Comparison from EXCITEL ISP - New Delhi.

C:\Users\ram>tracert 1.1.1.1

Tracing route to 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1] over a maximum of 30 hops:

  1     6 ms    11 ms     5 ms  192.168.1.1
  2     5 ms     5 ms    23 ms  10.4.224.1
  3     *        *        *     Request timed out.
  4    15 ms     7 ms    10 ms  103.56.229.1
  5     *        *        *     Request timed out.
  6    45 ms    56 ms    44 ms  115.255.252.225
  7    86 ms    84 ms    87 ms  62.216.144.77
  8   169 ms   173 ms   175 ms  xe-2-0-4.0.cjr01.sin001.flagtel.com [62.216.129.161]
  9   174 ms   174 ms   169 ms  ge-2-0-0.0.pjr01.hkg005.flagtel.com [85.95.25.41]
 10   173 ms   174 ms   170 ms  xe-3-2-2.0.ejr04.seo002.flagtel.com [62.216.130.25]
 11   171 ms   173 ms   170 ms  1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]

Trace complete.

C:\Users\ram>tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops:

  1    88 ms   305 ms    98 ms  192.168.1.1
  2    13 ms    98 ms   102 ms  10.4.224.1
  3     *        *        *     Request timed out.
  4     *       16 ms     *     10.200.200.1
  5     9 ms     3 ms     8 ms  209.85.172.217
  6    11 ms     5 ms     9 ms  108.170.251.103
  7    40 ms    33 ms    37 ms  209.85.246.164
  8     *       90 ms    89 ms  209.85.241.87
  9    89 ms    86 ms    89 ms  216.239.51.57
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19    87 ms    82 ms    87 ms  google-public-dns-a.google.com [8.8.8.8]

Trace complete.

C:\Users\ram>tracert resolver2.opendns.com

Tracing route to resolver2.opendns.com [208.67.220.220] over a maximum of 30 hops:

  1     3 ms     7 ms     8 ms  192.168.1.1
  2    12 ms    11 ms    41 ms  10.4.224.1
  3     *        *        *     Request timed out.
  4    21 ms    21 ms    51 ms  103.56.229.1
  5     *       62 ms    12 ms  115.248.235.150
  6     *      408 ms    65 ms  115.255.252.229
  7    43 ms    49 ms    40 ms  14.142.22.201.static-Mumbai.vsnl.net.in [14.142.22.201]
  8     *       41 ms    57 ms  172.23.78.237
  9    46 ms    32 ms    29 ms  172.19.138.86
 10    73 ms    46 ms    42 ms  115.110.234.50.static.Mumbai.vsnl.net.in [115.110.234.50]
 11    41 ms    64 ms    44 ms  resolver2.opendns.com [208.67.220.220]

Trace complete.

C:\Users\ram>

I am getting ERR_CERT_AUTHORITY_INVALID because my ISP-provided router is intercepting the connection and trying to show me a "helpful" configuration wizard. No Cloudflare DNS for me.

To be explicit: This is not Cloudflare's fault and we should blame the manufacturer of the router, or the ISP for deploying their custom "friendly" settings. But it is what it is.

Same problem here. It would be nice if Cloudflare created an alias to 1.1.1.1, because I can't access it at all.

Edit: 1.0.0.1 also takes me to the router configuration screen. And there's no configuration setting for it. :(

Same here, orange (FR)

I'm probably gonna switch my PiHole over from Google DNS. I trust Cloudflare more than Google to uphold my privacy. Not that I trust either very much.

Benchmarking Results for the interested: (sorted worst first, P value is bottom-X-percent)

    1.1.1.1:
      P00.5=48.2ms (55.8ms VPN)
      P50.0=32.8ms (37.0ms VPN)
      P95.0=29.1ms (33.0ms VPN)
      P99.5=29.1ms (32.7ms VPN)
    
    8.8.8.8:
      P00.5=225.4ms (71.5ms VPN)
      P50.0=48.0ms  (53.6ms VPN)
      P95.0=44.1ms  (51.3ms VPN)
      P99.5=43.8ms  (50.7ms VPN)

I've noticed I measured with my VPN on, so I put the VPN measurements in brackets behind the nominal values. The 8.8.8.8 benchmark is a bit odd but I repeated it several times with 100 iterations each and this is basically what I get.

Where are you located? I am in the rural north Bay Area California and my numbers are shocking:

Ping statistics for 1.1.1.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 2ms, Average = 1ms

Ping statistics for 8.8.8.8: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 25ms, Maximum = 27ms, Average = 26ms

Ping statistics for 8.8.4.4: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 26ms, Maximum = 28ms, Average = 27ms

Why isn't your pihole a stand-alone DNS resolver instead on relying on 3rd-party services ?

> What many Internet users don't realize is that even if you're visiting a website that is encrypted — has the little green lock in your browser — that doesn't keep your DNS resolver from knowing the identity of all the sites you visit. That means, by default, your ISP, every wifi network you've connected to, and your mobile network provider have a list of every site you've visited while using them.

> Network operators have been licking their chops for some time over the idea of taking their users' browsing data and finding a way to monetize it.

The "1.1.1.1 stops ISPs/Starbucks from selling your browsing history" pitch is untrue and, given Cloudflare's expertise, seems disingenuous.

HTTPS transmits domains unencrypted in request headers, to support SNI. So even if DNS lookups are completely hidden, my ISP can still log all domains I visit by inspecting my HTTP(S) requests.

And the domain log from my web requests is more valuable than my DNS log. Advertisers and data aggregators can see the true timing and frequency of my browsing history, whereas a DNS log is affected by router/OS/browser lookup caching.

It’s a step in the right direction. Also is TLS1.3. not supposed to encrypt SNI?

This is super exciting -- Public DNS space frankly needs more entrants.

I've been a long time user of OpenDNS's public DNS service (and have come to adore it greatly). Other recent new entrant to this space worth mentioning includes Global Cyber Alliance's [0] Quad9 DNS service, launched in Q4 2017.

This to me looks like a good move by Cloudflare, business model wise, given the increasing awareness among general public to the dangers of privacy breaches -- aside from the supposed boost in network speed piggybacking off of Cloudflare's extensive server farm network [1].

Whether the service delivers on it's bold claims, however, is to be seen. I'm going to go give this a shot now.

[0] https://www.globalcyberalliance.org/initiatives/quad9.html [1] https://www.cloudflare.com/network/

9.9.9.9 [1] has been praised by a bunch of people in the thread from a couple days ago [2]. How do those two compare?

[1] https://www.quad9.net/

[2] https://news.ycombinator.com/item?id=16716606

Note that 9.9.9.9 is NOT a regular DNS service and does not give you an unrestricted view of the global internet domain name system.

They match your requests with IBM's X-Force threat intelligence database and give you filtered results.

https://www.theregister.co.uk/2017/11/20/quad9_secure_privat...

Quad9 not friendly to CDN.

  $ dig +short @8.8.8.8 icnerd-1e5f.kxcdn.com
  p-rumo00.kxcdn.com.
  188.42.31.172
  $ dig +short @1.1.1.1 icnerd-1e5f.kxcdn.com
  p-rumo00.kxcdn.com.
  188.42.31.172
  $ dig +short @9.9.9.9 icnerd-1e5f.kxcdn.com 
  con-na00.kvcdn.com.
  p-ussj00.kxcdn.com.
  209.58.130.199
  $ dig +short @9.9.9.10 icnerd-1e5f.kxcdn.com
  con-na00.kvcdn.com.
  p-ussj00.kxcdn.com.

"Here are some DNS measurements comparing @Google Public DNS, @Quad9DNS and @Cloudflare, v6 and v4. Sourced from AS3320 near Frankfurt. Quad9 is fastest in avg. The proposed v6 address from Cloudflare is not yet working, but the longer ones."

https://twitter.com/webernetz/status/980055981282484225

Logging: https://www.quad9.net/privacy/

I don't use them (even though I would love to) because it takes approximately 3x as long to reach the server.

To compare the two, together with Google's DNS as a reference, from a fast connection:

    64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=3.62 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=60 time=3.60 ms 
    64 bytes from 9.9.9.9: icmp_seq=5 ttl=60 time=9.20 ms

...and from a slower (home) connection:

    64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=11.1 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=11.9 ms
    64 bytes from 9.9.9.9: icmp_seq=5 ttl=59 time=34.2 ms

Note that I just used the speed of every fifth package instead of the average for five packets in order to keep the comment relatively short and more humanly readable than "rtt min/avg/max/mdev".

I love the fact that the consortium managed to get 9.9.9.9 (because Google's 8.8.8.8) and named themselves Quad9!

I'm curious to read the reports from the garbage traffic they get at their 1.x.x.x addresses. Must be a ton of computers sending traffic that way. On the other hand, there's probably quite a few networks where 1.x.x.x is unreachable or routed to a local captive network access server, too.

If you’re on macOS and would rather do this from the command line:

  sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1

There’s more to dns performance than query time. Cloudflare doesn’t seem to be sending the EDNS client subnet to authoritative resolvers, which means those resolvers can’t give sensible nearest-to-client responses. This is a crucial feature of what makes the modern web fast.

It would be hard to claim to be a dns service which helps protect your privacy while also forwarding your subnet info on to other DNS servers.

Cloudflare has a large number of PoPs and are increasing them rapidly. If the service is distributed to them all than the authoritative server is likely to give a response that is similar to that it would have provided if the subnet had been explicitly provided since the Cloudflare PoP sending the request will be located network wise close to the client that originally made the request. This isn't always going to be true but the slightly higher odds that you will not connect to the optimal location for the service you are connecting to is probably worth the increase in privacy.

You can get performance stats over here https://www.dnsperf.com/#!dns-resolvers

If you want to figure out what the fastest DNS server is for you, I suggest this freeware utility https://www.grc.com/dns/benchmark.htm

Is there a thing like this for macOS?

Is Cloudflare overriding TTLs on RRs?

If I send a request to 1.0.0.1 for a specific RR that I'm 99.9% certain isn't cached (although I didn't check the query logs on the authoritative DNS servers to verify a request actually came in), the response contains the (expected) TTL of 14400.

If I then send the same request to 1.1.1.1, I get a response that is identical except with a TTL of 3591 seconds.

According to the timestamps in my client, the second request was made nine seconds after the first one (3591+9=3600), hence my question: is Cloudflare "overriding" the TTL I explicitly set on this specific RR (14400s) with a different TTL (i.e., 3600s)?

Yes, there's a cap on both negative and positive cache lifetime. The reason is reducing the blast radius as accidents happen, and it hurts especially on long infrastructure records (mistake during repointing NSs, bad glue, expired DS etc.) We're going to be looking into making the cap more dynamic over time.

Thought this was an April Fool joke at first.

Queries are jumping anywhere from 10ms to 138ms compared to a flat 6ms on Google and OpenDNS in Australia. Maybe unexpected traffic?

I thought so too, especially the emphasis on April 1. But I'm not sure what the joke is.

Sorry, but the only DNS resolver which can really claim to be "privacy first" and can be completely trusted is the one built with opensource code running on your own system.

So a VPS with enough storage plus Unbound and you're pretty much done in regards to "privacy first" and "trust".

To whoever who downvoted this comment, thanks for proving my point.

> We committed to never writing the querying IP addresses to disk and wiping all logs within 24 hours.

> Cloudflare's business has never been built around tracking users or selling advertising. We don't see personal data as an asset; we see it as a toxic asset. While we need some logging to prevent abuse and debug issues, we couldn't imagine any situation where we'd need that information longer than 24 hours.

How about aggregate stats? Will CloudFlare be keeping track of any long term usage statistics per domain?

I'm not talking about tracking the person making the request. I'm referring to tracking the hostnames that are being resolved. Given the near 1:1 mapping between user's accessing a website and DNS resolution for that website[1], wide scale usage of something like this gives decent analytics on net usage of any website even if it's not served by CloudFlare.

[1]: Assuming the DNS response cache times are low enough that a new user session to a website would require a fresh DNS request to resolve the website's IP.

What about ipv6?

There were rumours that they were getting 2001:2001:: and 2001:2001:2001::, but I can neither ping those addresses not use them to resolve.

https://developers.cloudflare.com/1.1.1.1/setting-up-1.1.1.1...

    2606:4700:4700::1111
    2606:4700:4700::1001

Not as memorable, unfortunately.

Lately I’ve been thinking about some concerns about domain name privacy:

• My ISP can spoof DNS responses.

• My ISP can sniff DNS requests.

• My ISP can sniff SNI.

• My ISP can look up reverse DNS on the IPs I visit.

DNS over TLS is nice—I just set up Unbound on my router to use 1.1.1.1@853 and 1.0.0.1@853 as forwarding zones. That eliminates the first bullet, at the cost of allowing CloudFlare to track my DNS requests.

I wonder how easy it is to route DNS‐over‐TLS over Tor?

What’s your threat model? The latency you’re going to introduce with TOR will make everyday browsing slow

I would love using better DNS resolvers like this than crappy ISP provided ones.

My only complain is when you connect to public wifi that requires to display some wifi capture page, acceptance of ToS, to sign in with your room number, airliner wifi, etc. Usually they break when you don't use their automated provided DNS servers. Requiring you to remove your preferred DNS entries, waiting for the wifi popup to open, do the required thing, and put back your preferred DNS servers. I end up just keeping the defaults, and that's a shame.

Wish they were a good solution. Any tips?

Put this DNS in your home router and not directly in your PC. Now your PC will fetch DNS at your home from this fast DNS and on pubic wifi, it will use theirs.

Is there anything to worry about with these types of services? Why are they competing for free? Where is the hook?

If everyone* just ran a full recursing resolver would that cause undue load on the root-servers? Seems like a sane way to decentralise.

* Actually only ~1% of internet users, the kind of people that install openwrt

Root servers get basically no traffic anyway. It's basically all cached by recursors.

Well, OpenWRT, DD-WRT, pfSense and OPNSense eh.

Chile, Temuco:

--- 1.1.1.1 ping statistics --- 26 packets transmitted, 26 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 56.440/62.916/106.933/10.084 ms

--- 8.8.8.8 ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 27.454/30.733/33.344/1.456 ms

--- 9.9.9.9 ping statistics --- 13 packets transmitted, 13 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 29.041/35.952/75.558/11.780 ms

Very impressed so far. I wonder if Cloudflare already has or is going to provide an IP address lookup service too, like OpenDNS and Google have? I find it quite useful to be able to just do something like:

dig -4 +short myip.opendns.com a @resolver1.opendns.com

dig -6 +short myip.opendns.com aaaa @resolver1.ipv6-sandbox.opendns.com

dig -4 +short o-o.myaddr.l.google.com txt @8.8.8.8

dig -6 +short o-o.myaddr.l.google.com txt @2001:4860:4860::8888

to get back my IPv4/IPv6 addresses; especially if Cloudflare can do it faster. Does anyone know if they already have something like this?

A big PITA for me right now with friends and family is changing DNS. They all have these Xfinity cable modem boxes that have integrated WiFi and Ethernet. It's not possible to change the DNS through the web interface. So I have to convince everyone to buy a separate AP or a 3rd party (but ISP approved) cable modem, and then what ensues is I'm now responsible for that device because Xfinity washes their hands entirely if there are any problems.

It's also a PITA to change this on each device.

I'm not sure which modem you have, but the Cisco modem I used to use with the built-in WiFi just as you describe absolutely has the ability to go in and edit the DNS servers assigned by DHCP under Connection > Local IP Network.

I also have the remote access enabled for my family members so I can diagnose and make changes like this directly on their modem.

Does it work well with (non-CloudFlare) CDNs or is this another DNS service that won’t work with Netflix on a Friday night because it routes everyone to a single edge mode?

From Comcast in San Francisco, I'm seeing that CloudFlare is the slowest of Google Public DNS, OpenDNS, Level 3, and Comcast's resolver.

Definitely not what I was expecting...

CloudFlare:

  $ ping -c 240 -i 0.25 1.1.1.1
  ...
  --- 1.1.1.1 ping statistics ---
  240 packets transmitted, 240 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 16.271/17.286/25.105/1.236 ms

Google Public DNS:

  $ ping -c 240 -i 0.25 8.8.8.8
  ...
  --- 8.8.8.8 ping statistics ---
  240 packets transmitted, 240 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 5.092/10.083/35.949/2.426 ms

OpenDNS:

  $ ping -c 240 -i 0.25 208.67.222.222
  ...
  --- 208.67.222.222 ping statistics ---
  240 packets transmitted, 240 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 8.596/9.847/25.898/1.788 ms

Level 3:

  $ ping -c 240 -i 0.25 4.2.2.2
  ...
  --- 4.2.2.2 ping statistics ---
  240 packets transmitted, 240 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 8.479/9.563/18.971/1.336 ms

Comcast's Resolver:

  $ ping -c 240 -i 0.25 75.75.75.75
  ...
  --- 75.75.75.75 ping statistics ---
  240 packets transmitted, 240 packets received, 0.0% packet loss
  round-trip min/avg/max/stddev = 8.410/9.717/19.428/1.487 ms

It even looks like OpenDNS and Level 3 are better than Google Public DNS in terms of latency.

You should be measuring DNS time, not ping time. There's more to how fast a DNS resolver responds than the time it takes to send the packet over the wire.

As a Comcast@Home subscriber in SF, 1.1.1.1 is approximately 3x as fast as Comcast's own DNS (testing using dig).

1.0.0.1 and 2606:4700:4700::1001 return the same PTR info as 1.1.1.1 and 2606:4700:4700::1111 do.

  $ host 1.0.0.1
  1.0.0.1.in-addr.arpa domain name pointer 1dot1dot1dot1.cloudflare-dns.com.

  $ host 2606:4700:4700::1001
  1.0.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.7.4.0.0.7.4.6.0.6.2.ip6.arpa domain name pointer 1dot1dot1dot1.cloudflare-dns.com.

I would've expected these to return 1dot0dot0dot1.cloudflare-dns.com.

A couple of years ago there was a tool built by some Google employee called namebench which benchmarked a couple of DNS servers and helped you to find the best one based on your browser history. Unfortunately, the project seems abandoned:

https://github.com/google/namebench

I remember being in France it was huge speedup over the providers default DNS.

Cape Town, South Africa

My ISP

Pinging 168.210.2.2 with 32 bytes of data:

Reply from 168.210.2.2: bytes=32 time=1ms TTL=58

Google

Pinging 8.8.8.8 with 32 bytes of data:

Reply from 8.8.8.8: bytes=32 time=18ms TTL=54

CloudFlare

Pinging 1.1.1.1 with 32 bytes of data:

Reply from 1.1.1.1: bytes=32 time=22ms TTL=246

Reply from 1.1.1.1: bytes=32 time=21ms TTL=246

I see a lot of criticism of the choice of KPMG.

Who should they have chosen as auditors? And which is the better fast privacy-minded DNS service I should be using?

Maybe they could do some form of auditing that is traceable by the average consumer. For instance:

They could make their deployment setup completely automated and publish the tooling to github, and have video evidence of them deploying the same SHA-256 stamped tooling to their data centers. They could expose operational details and transactions on their DNS servers as far as possible without revealing identifiable information. They could have regular physical audits by a constantly rotating set of well known and trusted parties (i.e. EFF, Mozilla).

Cloudflare, are you planning to support the OpenNIC initiative with this later on, rather than just being a regular, alternative DNS resolver?

From Sydney

--- 1.1.1.1 ping statistics ---