
1.1.1.1: Fast, privacy-first consumer DNS service - satysin
https://blog.cloudflare.com/announcing-1111/
======
cleanbrowsing
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.

~~~
chrissnell
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.

~~~
matthberg
Ping from University of Rochester, over wifi:

Cloudflare:

    
    
      64 bytes from 1.1.1.1: icmp_seq=0 ttl=128 time=2 ms
      64 bytes from 1.1.1.1: icmp_seq=1 ttl=128 time=2 ms
      64 bytes from 1.1.1.1: icmp_seq=2 ttl=128 time=2 ms
      64 bytes from 1.1.1.1: icmp_seq=3 ttl=128 time=9 ms
      64 bytes from 1.1.1.1: icmp_seq=4 ttl=128 time=2 ms
    

Google:

    
    
      64 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=12 ms
      64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=11 ms
      64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=13 ms
      64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=45 ms
      64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=14 ms
      64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=11 ms
      64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=34 ms
    

Quad9:

    
    
      64 bytes from 9.9.9.9: icmp_seq=0 ttl=53 time=10 ms
      64 bytes from 9.9.9.9: icmp_seq=1 ttl=53 time=69 ms
      64 bytes from 9.9.9.9: icmp_seq=2 ttl=53 time=14 ms
      64 bytes from 9.9.9.9: icmp_seq=3 ttl=53 time=58 ms
      64 bytes from 9.9.9.9: icmp_seq=4 ttl=53 time=52 ms
    

One thing I noticed is that when I first pinged 1.1.1.1 I got 14ms, which then
quickly dropped to ~3ms consistently:

    
    
      64 bytes from 1.1.1.1: icmp_seq=0 ttl=128 time=14 ms
      64 bytes from 1.1.1.1: icmp_seq=1 ttl=128 time=14 ms
      64 bytes from 1.1.1.1: icmp_seq=2 ttl=128 time=2 ms
      64 bytes from 1.1.1.1: icmp_seq=3 ttl=128 time=3 ms
      64 bytes from 1.1.1.1: icmp_seq=4 ttl=128 time=1 ms
      64 bytes from 1.1.1.1: icmp_seq=5 ttl=128 time=4 ms

~~~
Tree1993
Beijing:

    
    
      PING 1.1.1.1 (1.1.1.1): 56 data bytes
      64 bytes from 1.1.1.1: icmp_seq=0 ttl=52 time=241.529 ms
      64 bytes from 1.1.1.1: icmp_seq=1 ttl=52 time=318.034 ms
      64 bytes from 1.1.1.1: icmp_seq=2 ttl=52 time=337.291 ms
      64 bytes from 1.1.1.1: icmp_seq=3 ttl=52 time=255.748 ms
      64 bytes from 1.1.1.1: icmp_seq=4 ttl=52 time=247.765 ms
      64 bytes from 1.1.1.1: icmp_seq=5 ttl=52 time=235.611 ms
      64 bytes from 1.1.1.1: icmp_seq=6 ttl=52 time=239.427 ms
      64 bytes from 1.1.1.1: icmp_seq=7 ttl=52 time=247.911 ms
      64 bytes from 1.1.1.1: icmp_seq=8 ttl=52 time=260.911 ms
      64 bytes from 1.1.1.1: icmp_seq=9 ttl=52 time=281.153 ms
      64 bytes from 1.1.1.1: icmp_seq=10 ttl=52 time=300.363 ms
      64 bytes from 1.1.1.1: icmp_seq=11 ttl=52 time=234.296 ms

~~~
bgdkbtv
Australia :(

    
    
      64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=17.580 ms
      64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=18.025 ms
      64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=17.780 ms
      64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=18.231 ms
      64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=17.906 ms
      64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=18.447 ms

~~~
marcus_holmes
Cambodia - crappy office wifi

    
    
      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.806 ms
      64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=23.321 ms
      64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=24.379 ms
      64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=25.869 ms
      64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=24.485 ms
      64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=24.165 ms
    
      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=23.005 ms
      64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=22.867 ms
      64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=24.461 ms
      64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=23.680 ms
      64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=35.581 ms
      64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=21.033 ms
      64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=41.634 ms

~~~
kukkukb
Johannesburg, South Africa. 100mb/s home fibre:

    
    
      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=58 time=1.36 ms
      64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=1.32 ms
      64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=1.34 ms
      64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=1.38 ms
      64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=1.37 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=1.33 ms
      64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=1.38 ms
      64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=1.35 ms
      64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=1.36 ms
      64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=1.35 ms

------
bluejekyll
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](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).

~~~
chimera77
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.

~~~
ori_b
I've implemented DNS before. Doing this saves an entire 300 lines of code. At
the same time, it makes the DNS server much more complicated. On top of that,
implementing a compliant posix libc will now either use a completely different
code path, or pull in a huge amount of code to implement HTTP, HTTP/2, and
QUIC. If the simpler, cleaner, and more performant route is taken, it
willgbreak when someone screws up "legacy" dns without noticing, because it
works in the browser.

It's not worth the complexity of multiple protocols that do the same thing.
And it's not worth making the base system insanely complicated so that the
magic 4 letters 'http' can show up.

TLS? Yeah, since the simpler secure DNSes failed, we might as well use that.
But let's try to keep http complexity contained.

------
DyslexicAtheist
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

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

~~~
aexaey
_0_ , which is a shorthand for _0.0.0.0_ is likely the most code-golf-y way to
write _localhost_ , as many [EDIT: Linux] systems alias 0.0.0.0 to 127.0.0.1:

    
    
      $ ping 0
      PING 0 (127.0.0.1) 56(84) bytes of data.
      64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.032 ms
    

Of course, don't expect this to work universally. A lot of software will try
to be clever with input validation, and fail.

Tangentially related:
[https://fosdem.org/2018/schedule/event/email_address_quiz/](https://fosdem.org/2018/schedule/event/email_address_quiz/)

~~~
pishpash
0.0.0.0 is not localhost. It's "any address".

~~~
aexaey
Yes, you're right.

What I was trying to say is - On Linux, INADDR_ANY (0.0.0.0) supplied to
connect() or sendto() calls is treated as a synonym for INADDR_LOOPBACK
(127.0.0.1) address.

Not so for bind() or course.

------
JD557
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](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...](https://torrentfreak.com/cloudflare-doesnt-want-daily-stormer-
evidence-at-piracy-trial-180327/)

~~~
kentonv
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/](https://blog.cloudflare.com/why-we-terminated-daily-stormer/)

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

~~~
JD557
I probably should have made a clearer point instead of linking to
TorrentFreak.

I did not mean that I was worried that CloudFlare's DNS would start blocking
sites whose content they disagree with (although that would also be
worrisome).

I'm worried that copyright holders might be able to use the Daily Stormer case
as a precedent to force CloudFlare to stop offering services to infringing
sites.

If they are able to do that, I can also see them attempting to force
CloudFlare to remove DNS entries as well.

~~~
kentonv
Right, as I said, it's hard for me to see how one could be used as precedent
for the other given how different the situations are. And if you could use it,
you could just as easily do the same against Google DNS.

I'm not a lawyer, though.

------
jlgaddis
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](https://developers.google.com/speed/public-dns/faq)

~~~
DesertBattery
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"

~~~
jlgaddis
Are you in .ru?

You might direct your questions at your ISP instead as it appears that someone
may be intercepting your DNS requests.

\---- To elaborate a bit, the differences in the (74.125.x.x) IP addresses
being returned is somewhat normal and would usually be attributed to simple
load balancing (as _d33_ pointed out). That is, 8.8.8.8 is actually a load
balancer with several servers (including 74.125.46.8, 74.125.46.11, and
74.125.74.3) behind it.

The differences seen in the returned "edns0-client-subnet", however, are,
well, "interesting".

As you've directed the requests to 8.8.8.8 directly (as opposed to your
system's default resolver, whatever that is), the response returned for
"edns0-client-subnet" _should_ normally either be your own IP address or a
supernet that includes it. (In my case, for example, the value is the static
IP address (/32) of my own resolver.) When sending multiple requests such as
you have, the "edns0-client-subnet" shouldn't really be changing from one
request/response to the next; at the least, the values shouldn't change _this
much_.

The fact that the responses are changing would seem to indicate that Google
DNS servers are receiving the requests from different IP addresses when they
should, in fact, all be coming from the same IP address (yours). These changes
would lead me to suspect that someone (i.e., your ISP) is intercepting your
DNS requests and "transparently proxying" them on your behalf.

If your ISP is using CGNAT (and issues you a private IP address) or something
similar, that might explain it. Otherwise, I would be suspicious.

~~~
DesertBattery
I have static public /32\. My ISP intercepting DNS traffic for censorship
purposes. But i strongly doubt that this traffic is forwarded somewhere.

    
    
      [user@v-fed-1 ~]$ dig txt o-o.myaddr.test.l.google.com @8.8.8.8 +short
      "173.194.98.4"
      "edns0-client-subnet 94.181.44.185/32"
      [user@v-fed-1 ~]$ dig txt o-o.myaddr.test.l.google.com @8.8.8.8 +short
      "173.194.98.4"
      "edns0-client-subnet 94.181.44.185/32"
      [user@v-fed-1 ~]$ dig txt o-o.myaddr.test.l.google.com @8.8.8.8 +short
      "173.194.98.4"
      "edns0-client-subnet 94.181.44.185/32"
    
      [user@v-fed-1 ~]$ dig txt edns-client-sub.net @8.8.8.8 +short
      "{'ecs_payload':{'family':'1','optcode':'0x08','cc':'RU','ip':'94.181.44.0','mask':'24','scope':'0'},'ecs':'True','ts':'1522656335.56','recursive':{'cc':'FI','srcip':'74.125.74.4','sport':'40964'}}"
      [user@v-fed-1 ~]$ dig txt edns-client-sub.net @8.8.8.8 +short
      "{'ecs_payload':{'family':'1','optcode':'0x08','cc':'RU','ip':'94.181.44.0','mask':'24','scope':'0'},'ecs':'True','ts':'1522656336.4','recursive':{'cc':'US','srcip':'74.125.46.4','sport':'51510'}}"
      [user@v-fed-1 ~]$ dig txt edns-client-sub.net @8.8.8.8 +short
      "{'ecs_payload':{'family':'1','optcode':'0x08','cc':'RU','ip':'94.181.44.0','mask':'24','scope':'0'},'ecs':'True','ts':'1522656337.96','recursive':{'cc':'US','srcip':'74.125.46.4','sport':'54992'}}"
    
    

127.1 is a DNS-over-HTTPS proxy.

    
    
      [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @127.1 +short
      "173.194.98.11"
      "edns0-client-subnet 94.181.44.0/24"
      [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @127.1 +short
      "173.194.98.11"
      "edns0-client-subnet 94.181.44.0/24"
      [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @127.1 +short
      "173.194.98.6"
      "edns0-client-subnet 193.151.48.130/32
    

Some story from other (business) connection.

    
    
      [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
      "74.125.74.3"
      "edns0-client-subnet 37.113.134.30/32"
      [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
      "74.125.46.4"
      "edns0-client-subnet 85.29.165.14/32"
      [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short
      "173.194.98.13"
      "edns0-client-subnet 77.234.25.49/32"

~~~
sashametro
If you run those commands without the +short you will see that the TTL values
for those responses are less than 59 (which for Google Public DNS, indicates
they are cached, and explaining why the IP addresses shown are not yours).

The o-o.myaddr.l.google.com domain is a feature of Google's authoritative name
servers (ns[14].google.com) and not of 8.8.8.8. You can send similar queries
through 1.1.1.1 (where you will see that there is no EDNS Client Subnet data
provided, improving the privacy of your DNS but potentially returning less
accurate answers, as Google's authoritative servers do not have your IP
subnet, but only the IP address of the CloudFlare resolver forwarding your
query.

~~~
DesertBattery
Aren't o-o.myaddr.l.google.com is intended for troubleshooting and should show
correct ECS? o-o.myaddr.test.l.google.com always show correct ECS.

------
ajross
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.

~~~
tialaramex
"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.

~~~
aquis
Worth noting they have already edited the article (less than 2hours later) and
taken out the "We will never log your IP" bit...

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

"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.
And we wanted to put our money where our mouth was, so we committed to
retaining KPMG, the well-respected auditing firm, to audit our code and
practices annually and publish a public report confirming we're doing what we
said we would."

~~~
iwalsh
Not sure if they edited anything. Your quote is from the blog post[1] but the
aforementioned quote by tialaramex is from the 1.1.1.1 site itself[2].

[1]
[https://blog.cloudflare.com/announcing-1111/](https://blog.cloudflare.com/announcing-1111/)
[2] [https://1.1.1.1](https://1.1.1.1)

------
antoncohen
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/](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?

~~~
Someone1234
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?

~~~
antoncohen
That is a good point, though I wasn't thinking about it from a security
perspective. I was more imagining an ISP or nation that is trying to control
content by blocking/faking DNS queries. They could block the first DNS query
if DNS-over-HTTPS doesn't use an IP for the resolver.

Of course an ISP or nation could block/reroute the IP 1.1.1.1 too, so maybe it
doesn't matter. Neither way would allow MITM, I was just thinking about ways
oppressive ISPs/nations could stop DNS-over-HTTPS from working.

~~~
zackbloom
You can also query 1.1.1.1 using the DNS-over-HTTPS URL schema if you like,
you don't have to use cloudflare-dns.com.

------
contingencies
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

~~~
larrysalibra
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.

~~~
nik736
Peer for free? Anything to back that up because I doubt that highly?

Maybe DTAG and UPC will peer for free in mighty LA as well. /s

~~~
jlgaddis
PeeringDB seems to indicate as much.

~~~
nik736
[https://www.peeringdb.com/net/308](https://www.peeringdb.com/net/308)

I don't see any free peering?

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

~~~
tialaramex
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/](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/](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]

~~~
tomputer
Thanks for the clarification. I did know it was possible when setting up CA's
for VPN servers, they can use certificates with DNS and/or IP as identifiers.
Somehow I never thought about certificates for public IP addresses.

~~~
jlgaddis
FWIW, until a few years ago, it was also possible to get certificates for
_private_ IP addresses (and "private" hostnames, such as .local).

------
driverdan
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)

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

------
ocdtrekkie
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.

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

~~~
ocdtrekkie
My strong impression is that they wouldn't give APNIC any data that can be
used to identify users of their DNS service, but I'd definitely love a more
detailed answer than what the site currently provides.

~~~
xuande
Found this: [https://labs.apnic.net/?p=1127](https://labs.apnic.net/?p=1127)

~~~
ENOTTY
An excellent find!

> We will be destroying all “raw” DNS data as soon as we have performed
> statistical analysis on the data flow. We will not be compiling any form of
> profiles of activity that could be used to identify individuals, and we will
> ensure that any retained processed data is sufficiently generic that it will
> not be susceptible to efforts to reconstruct individual profiles.
> Furthermore, the access to the primary data feed will be strictly limited to
> the researchers in APNIC Labs, and we will naturally abide by APNIC’s non-
> disclosure policies.

So it's a 5 year research program, with options to extend it as a research
program. To me, that means they intend to keep DNS data for up to 5 years (or
longer) before performing statistical analysis and processing on it. Here is
APNIC Labs's privacy policy
[http://labs.apnic.net/privacy.shtml](http://labs.apnic.net/privacy.shtml) and
APNIC's privacy policy [https://www.apnic.net/about-apnic/corporate-
documents/docume...](https://www.apnic.net/about-apnic/corporate-
documents/documents/corporate/privacy/#2.4)

So much for "privacy-first".

~~~
ocdtrekkie
Most of those terms relate to APNIC "ad" placement, and it specifies as such.
They likely do not apply here, as it seems Cloudflare is not tracking the IP
address, and things like browser fingerprinting wouldn't even show up in a DNS
request.

The highlight point to me is that they not only say that won't collect data
that could be used to identify individuals, but seem to realize even seemingly
anonymized data can be traced back to individuals too, hence the further
claim.

I'm inclined to give APNIC the benefit of the doubt, they're a nonprofit, and
a fundamental part of the Internet's addressing structure, but it'd be nice to
get a bit more detail from them on what they :do: collect.

------
mike-cardwell
"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](https://twitter.com/philpennock/status/980561009961299968)

~~~
kentonv
edns-client-subnet leads to a surprising number of privacy concerns. See:
[https://00f.net/2013/08/07/edns-client-
subnet/](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.

------
nubela
$ 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

~~~
veidr
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)]$

~~~
technion
You're just trying to make Australians jealous aren't you?

    
    
        ping 1.1.1.1
    
        Reply from 1.1.1.1: bytes=32 time=366ms TTL=58
        Reply from 1.1.1.1: bytes=32 time=366ms TTL=58
        Reply from 1.1.1.1: bytes=32 time=365ms TTL=58
        Reply from 1.1.1.1: bytes=32 time=365ms TTL=58
    
        ping 8.8.8.8
    
        Reply from 8.8.8.8: bytes=32 time=402ms TTL=59
        Reply from 8.8.8.8: bytes=32 time=373ms TTL=59
        Reply from 8.8.8.8: bytes=32 time=373ms TTL=59
        Reply from 8.8.8.8: bytes=32 time=374ms TTL=59

~~~
NamTaf
I'm getting ~40-50ms on both on Internode from Brisbane.

~~~
lugg
What do you get to internode from there? (@192.231.203.132)

I'm halfway up to newcastle getting ~10ms across the board, 1.1.1.1, 8.8.8.8,
and 192.231.203.132.

Of course performance on each is a different matter.

1.1.1.1 is giving the best response times @ 8-11ms.

Internode's is giving decent @ 10-14ms

8.8.8.8 is a bit wonky, sometimes I hit a 10ms route once they cache it, but
propagation is very slow and most responses are 140-180ms.

~~~
NamTaf
Sorry for the late response: to Internode (192.231.203.132) I get 36 ms. This
is all on (rather terrible) ADSL 2+

------
icebergonfire
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.

~~~
rmsaksida
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. :(

~~~
tialaramex
Yup, these ranges are poisonous, which is why APNIC kept them, so this is
effectively to be expected. It would actually be extraordinary if, since the
range was determined to be poisonous and so mustn't be delegated this had
magically fixed itself. So I was sort-of expecting to see some comments in the
last thread about 1.1.1.1 like yours.

The "good" news is that this isn't being used for anything you really need -
imagine if 1.1.1.1 had been delegated and now it was the resolution for
www.facebook.com or indeed news.ycombinator.com ...

The bad news is that idiots do not learn from their mistakes, that's Dunning
Kruger, the people who built your device don't understand why this was the
Wrong Thing™ and won't now seek to do better in future. If we're lucky they'll
go out of business, but that's the best we can hope for.

------
tscs37
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.

~~~
sgc
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

~~~
tscs37
I'm in Southern Germany, my ISP is a bit of a quack when I'm not using their
own ad-riddled DNS (I suspect it's intentional)

------
slowsun
> 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.

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

~~~
slowsun
I agree that a non-Google public resolver, which comes with guarantees about
how they'll use your data, is a good thing.

I'm taking exception with Cloudflare's announcement, which makes a pitch to
end users that CF can protect your domain history from ISP snooping, then
links to a two-minute setup guide for people with "no technical skill". They
really can't protect your domain history, and I feel bad for people using this
service who have been led to believe otherwise.

AFAIK there is nothing in the TLS 1.3 draft [1] about SNI encryption. There
are other draft proposals for SNI encryption that build on top of TLS 1.3 [2].
It's a hard problem and there are no deployed solutions I'm aware of.

[1] [https://tools.ietf.org/html/draft-ietf-tls-
tls13-28](https://tools.ietf.org/html/draft-ietf-tls-tls13-28)

[2] [https://tools.ietf.org/html/draft-ietf-tls-sni-
encryption-00](https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00)

------
abhiminator
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](https://www.globalcyberalliance.org/initiatives/quad9.html)
[1] [https://www.cloudflare.com/network/](https://www.cloudflare.com/network/)

------
infinisil
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/](https://www.quad9.net/)

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

~~~
0x0
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...](https://www.theregister.co.uk/2017/11/20/quad9_secure_private_dns_resolver/)

~~~
mandelbulb
[https://quad9.net/faq/#Is_there_a_service_that_Quad9_offers_...](https://quad9.net/faq/#Is_there_a_service_that_Quad9_offers_that_does_not_have_the_blocklist_or_other_security)

Is there a service that Quad9 offers that does not have the blocklist or other
security?

The primary IP address for Quad9 is 9.9.9.9, which includes the blocklist,
DNSSEC validation, and other security features. However, there are alternate
IP addresses that the service operates which do not have these security
features. These might be useful for testing validation, or to determine if
there are false positives in the Quad9 system.

Secure IP: 9.9.9.9 Provides: Security blocklist, DNSSEC, No EDNS Client-Subnet
sent. If your DNS software requires a Secondary IP address, please use the
secure secondary address of 149.112.112.112

Unsecure IP: 9.9.9.10 Provides: No security blocklist, DNSSEC, sends EDNS
Client-Subnet. If your DNS software requires a Secondary IP address, please
use the unsecure secondary address of 149.112.112.10

Note: Use only one of these sets of addresses – secure or unsecure. Mixing
secure and unsecure IP addresses in your configuration may lead to your system
being exposed without the security enhancements, or your privacy data may not
be fully protected

\--------------------------

IPV6:
[https://quad9.net/faq/#Is_there_IPv6_support_for_Quad9](https://quad9.net/faq/#Is_there_IPv6_support_for_Quad9)

Is there IPv6 support for Quad9?

Yes. Quad9 operates identical services on a set of IPv6 addresses, which are
on the same infrastructure as the 9.9.9.9 systems.

Secure IPv6: 2620:fe::fe Blocklist, DNSSEC, No EDNS Client-Subnet

Unsecure IPv6: 2620:fe::10 No blocklist, DNSSEC, send EDNS Client-Subnet

------
0x0
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.

------
latexr
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

------
ebikelaw
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.

~~~
tssva
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.

~~~
ebikelaw
What exactly is the privacy threat model in this situation? If you are about
to connect to the resolved service it makes no difference that you hid your
subnet from that service’s DNS server.

~~~
jvolkman
What if a client blackholes all traffic to some network due to some privacy-
related reason? If cloudflare tells that provider (via name resolution) who's
resolving names, some of that client's PII is possibly shared before the
blackhole decision can even be made.

~~~
ebikelaw
That seems a bit contrived but just rolling with it, this hypothetical org
with ultra-sensitive opsec should have also blacklisted the domain in question
at their inside resolver.

------
jimaek
You can get performance stats over here [https://www.dnsperf.com/#!dns-
resolvers](https://www.dnsperf.com/#!dns-resolvers)

------
mastax
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](https://www.grc.com/dns/benchmark.htm)

~~~
s3nnyy
Is there a thing like this for macOS?

~~~
telesilla
Namebench hasn't been updated since 2010, but I just checked and it's running
fine on my Sierra box.

[https://code.google.com/archive/p/namebench/downloads](https://code.google.com/archive/p/namebench/downloads)

~~~
indigodaddy
The browser doesn't open after the operation/queries finish for me on High
Sierra

~~~
telesilla
It should still save the results, check your console and open the .html file

> Saving detailed results to
> /var/folders/j8/vd7q07z7r_5wt0s2mq00vgn/T/namebench_2018-04-01_1856.csv

> default 18:56:37.001803 +0200 namebench Opening
> /var/folders/j8/vd7q07z7r_5wt0s2mq00vgn/T/namebench_2018-04-01_1856.html

------
jlgaddis
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)?

~~~
vavrusa
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.

~~~
LinuxBender
I do this at home as well, using Unbound DNS to set a min and max TTL. It's
taboo on public DNS recursors, but totally makes sense. Some folks try to use
DNS as real time load balancers and will set crazy low TTL's like 1 second or
even 0 (which violates RFC's)

------
TheWoodsy
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?

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

------
mindcrash
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".

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

------
koolba
> 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._

------
dorfsmay
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.

~~~
ancarda
[https://developers.cloudflare.com/1.1.1.1/setting-
up-1.1.1.1...](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.

~~~
wila
2606:4700:4700::1111

You could make it slightly more memorable by decoding from hex to ascii, but
that does not help too much either in this case:

& ACK:G NUL: G NUL::1111

~~~
visitante
.

------
anjbe
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?

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

~~~
anjbe
It’s not like I’d be running everything over Tor. DNS requests for
newly‐visited domains would slow down, but unbound’s prefetch feature would
keep popular frequently‐used domains cached. Adding one of those advertising
domain blacklists might help performance too.

The point would be to keep Cloudflare from being able to track my DNS
requests.

~~~
cmstoken
Why not use a VPN like PIA?

~~~
jerheinze
> Why not use a VPN like PIA?

A VPN gives you little protection against browser fingerprinting, which may
alone leak enough information about you to identify you. Also privacy-by-
policy is in no way near privacy-by-design. If you want privacy, use the Tor
Browser.

~~~
plb4333
What a bunch of false security you're providing. NSA had broken the TOR
traffic quite a while back. Worthless.

------
hartator
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?

~~~
adityapatadia
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.

~~~
jads
Some ISPs and their routers don't allow for the DNS settings to be changed,
unfortunately. Still can be worked around, but sometimes the easiest solution
is to just edit the DNS settings directly.

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

------
mkj
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

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

~~~
JdeBP
That's not in fact true. There are quite a lot of cache misses in the normal
course of affairs, to start with.

------
ktosobcy
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

------
iod
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?

------
cmurf
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.

~~~
RKearney
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.

~~~
cmurf
ARRIS Group, Inc. TG1682G less than a year old. This is what everyone has in
Denver, as far as I'm aware. Most of the devices settings aren't managable by
its own web interface, I have to go to xfinity.com/myxfi and login to the
account, and then it pushes changes to the cable modem/AP. This includes the
login password for the device's web interface. Thoroughly screwy in my
opinion.

Anyway, there is a Connection > Local IP Network. But no DNS settings
anywhere.

------
gok
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?

------
TheSwordsman
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.

~~~
eridius
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).

------
dojo999
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.

------
stadeschuldt
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](https://github.com/google/namebench)

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

------
christogreeff
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

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

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

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

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

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

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=22ms TTL=246

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

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

------
Angostura
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?

~~~
colordrops
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).

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

------
dbg31415
From Sydney

\--- 1.1.1.1 ping statistics ---

100 packets transmitted, 100 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 10.536/13.084/19.910/3.284 ms

\--- 8.8.4.4 ping statistics ---

100 packets transmitted, 100 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 10.931/15.141/32.453/6.498 ms

\--- 1.0.0.1 ping statistics ---

100 packets transmitted, 100 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 10.219/16.709/29.498/6.960 ms

\--- 9.9.9.9 ping statistics ---

100 packets transmitted, 100 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 10.290/22.336/43.267/10.238 ms

\--- 208.67.222.222 ping statistics ---

100 packets transmitted, 100 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 12.985/22.786/46.929/10.036 ms

\--- 208.67.220.220 ping statistics ---

100 packets transmitted, 100 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 16.273/27.225/49.783/10.246 ms

\--- 8.8.8.8 ping statistics ---

100 packets transmitted, 100 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 10.581/35.527/125.641/33.204 ms

------
SeoxyS
My main problem with these DNS services is that they often break gated wifi
networks that require a login page to access. It's horrible that it has become
standard practice to take over DNS to redirect to a access gate — but as
users, your choices are either: suck it up, or no internet.

Does anyone have a better solution for this?

(Also — why no IPv6 DNS?)

------
pmoriarty
_" Visit [https://1.1.1.1/](https://1.1.1.1/) from any device to get started
with the Internet's fastest, privacy-first DNS service."_

When I try, my browser tells me:

    
    
      Bad cert ident from 1.1.1.1: dNSName=*.cloudflare-dns.com cloudf: accept? (y or n)

~~~
cwp
I get ERR_CONNECTION_REFUSED

~~~
prdonahue
Likely that IP address is being used (inadvisably) by something on your
network.

~~~
cwp
Looks that way. 1.0.0.1 works fine though.

~~~
cwp
And now, so does 1.1.1.1. I suspect it was something sonic.net was doing, and
they had to fix it when this announcement was made.

------
cpeterso
Here are instructions for testing DoH (DNS-over-HTTPS) in Firefox Nightly:

[https://gist.github.com/mcmanus/766a9564a51325b6543644983539...](https://gist.github.com/mcmanus/766a9564a51325b6543644983539e7ff)

~~~
alwillis
DoH on Firefox nightly working great:

    
    
        Version: 61.0a1 (2018-04-01)
        OS: macOS High Sierra 10.13.4 (17E199)

~~~
cpeterso
According to the Firefox bug report, this was an Apple bug (related to TCP
Fast Open) fixed in macOS 10.13.4. When I updated to 10.13.4, the panic went
away.

------
squarefoot

      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.6 ms
      64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=11.2 ms
      64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=10.8 ms
      64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=11.1 ms
      64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=10.9 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=57 time=15.0 ms
      64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=15.9 ms
      64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=15.1 ms
      64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=15.0 ms
      64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=15.1 ms
    
    

FTTC, southern EU.

------
natbobc
Not accessible from Buenos Aires, Argentina on Fibertel.

    
    
      ping 1.1.1.1                                                       
      PING 1.1.1.1 (1.1.1.1): 56 data bytes
      Request timeout for icmp_seq 0
      Request timeout for icmp_seq 1

~~~
huxflux
Same here (timeout), Shanghai, China on China Unicom.

Pinging 1.1.1.1 with 32 bytes of data: Request timed out. Request timed out.
Request timed out. Request timed out.

Ping statistics for 1.1.1.1: Packets: Sent = 4, Received = 0, Lost = 4 (100%
loss),

~~~
natbobc
Found out via Twitter you can also use 1.0.0.1 which is another of their
resolvers and works for me in Argentina.

Although 1.1.1.1 is accessible for me know so I suspect it was a propagation
issue.

------
brightball
I still find myself wondering about things like the iphones DNS service
though. You can’t change it while connected to a cell network and it always
seemed strange to me that was considered okay.

~~~
LeoPanthera
You can change the iPhone DNS servers by installing a profile. Apps like "DNS
Override" (not a recommendation) will do it for you.

------
lenova
Is there a way to use Cloudflare's new DNS servers with Simple DNSCrypt?
([https://simplednscrypt.org/](https://simplednscrypt.org/))

~~~
jedisct1
Yes, just select "Cloudflare" in the list.

It's been available in the public list for quite some time already.

~~~
lenova
I see it on the list, but is it referring to the 1.1.1.1 server?

~~~
jedisct1
Yes, this is it.

------
2bitencryption
Does Windows/all my devices support DNS-over-HTTPS (or TLS) right now?

I.e. if I set everything to use 1.1.1.1, will all my devices know to use the
secure protocols, or will it be regular old unsecure DNS?

~~~
jlgaddis
Your best bet would be to configure your own DNS server (on your router, for
example, assuming support) to use DNS-over-(HTTPS|TLS) and then have all of
your other devices use your router as their DNS server.

------
buremba
> DNS resolvers inherently can't use a catchy domain because they are what
> have to be queried in order to figure out the IP address of a domain. It's a
> chicken and egg problem. And, if we wanted the service to be of help in
> times of crisis like the attempted Turkish coup, we needed something easy
> enough to remember and spraypaint on walls.

In fact, people wrote that DNS address on walls just to get away with the
censorship of the government so you wouldn't be helping the government..

------
eeZah7Ux
Any reason why DNS over TLS is preferred over DNSCurve?

~~~
therealmarv
I'm guessing less "sophisticated reinvention" and usage of existing TLS
connection technology. You can use both (even at the same time) with DNScrypt-
proxy V2 [https://github.com/jedisct1/dnscrypt-
proxy](https://github.com/jedisct1/dnscrypt-proxy) ;)

------
ogud
Official now Privacy and Speed are the goals [https://blog.cloudflare.com/dns-
resolver-1-1-1-1/](https://blog.cloudflare.com/dns-resolver-1-1-1-1/)
[https://blog.cloudflare.com/announcing-1111/](https://blog.cloudflare.com/announcing-1111/)

------
sajal83
[https://pulse.turbobytes.com/results/5ac1deefecbe4078c200ed8...](https://pulse.turbobytes.com/results/5ac1deefecbe4078c200ed8a/)

Query times and rechability from 58 locations. 3 locations still can't reach
1.1.1.1, but for most users cached response is faster from Cloudflare.

------
15charlimitdumb
mid missouri US sample size;

gregs-Air:~ greg$ 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=55 time=51.035 ms 64 bytes from 1.1.1.1:
icmp_seq=1 ttl=55 time=52.024 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=55
time=52.945 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=77.263 ms 64
bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=53.427 ms 64 bytes from 1.1.1.1:
icmp_seq=5 ttl=55 time=57.311 ms 64 bytes from 1.1.1.1: icmp_seq=6 ttl=55
time=192.017 ms 64 bytes from 1.1.1.1: icmp_seq=7 ttl=55 time=174.206 ms 64
bytes from 1.1.1.1: icmp_seq=8 ttl=55 time=142.224 ms 64 bytes from 1.1.1.1:
icmp_seq=9 ttl=55 time=288.815 ms ^C \--- 1.1.1.1 ping statistics --- 10
packets transmitted, 10 packets received, 0.0% packet loss round-trip
min/avg/max/stddev = 51.035/114.127/288.815/77.996 ms gregs-Air:~ greg$ curl
ifconfig.co 174.125.4.196 gregs-Air:~ greg$

------
akerro
Privacy-first from cloudflare? Wasn't cloudflare founded by ex-NSA employee
and heavily funded by NSA when it started?

~~~
kentonv
No. Where did you get that from?

------
nykolasz
Ran a comparison between all major DNS resolvers (including CloudFlare,
Google, OpenDNS, etc):

[https://medium.com/@nykolas.z/dns-resolvers-performance-
comp...](https://medium.com/@nykolas.z/dns-resolvers-performance-compared-
cloudflare-x-google-x-quad9-x-opendns-149e803734e5)

------
gerdesj
The Linux instructions don't mention adding 1.1.1.1, only 1.0.0.1! However, I
think I can work that out 8)

------
chiefalchemist
Three novice questions, please:

1) A VPN gives you privacy but this prevents your ISP from even knowing you're
using a VPN, correct?

2) This is a change you make to your wifi router, correct?

3) What is you're not on wifi, or you're using public wifi, is it possible to
still benefit from this?

Thanks in advance. I'll wait for my answers off the air :)

~~~
lallysingh
1) These requests are all in the clear, so your isp can read them and see
which hosts you're asking for. VPNs provide better privacy (assuming you
choose a private one).

2) yup

3) often. You can set it on your computer, but some public WiFi systems will
block it.

~~~
tonyztan
To add to #1, your ISP can also see that you're using OpenVPN or another VPN
protocol.

------
unicornporn
9.9.9.9

[https://quad9.net](https://quad9.net) has been serving me well.

------
davewasthere
In Bendigo Australia, and Steve Gibson's DNSBenchmark tells me that of my 50
optimised resolvers (with 1.1.1.1 and 9.9.9.9 added), the two fastest public
DNS services I should use are 9.9.9.9 followed by 8.8.8.8. I also add a couple
of others for redundancy..

------
arikr
What's the right way to set this up for cellular traffic on iOS? (The
instructions are for wi-fi only)

Is there anything better than
[https://www.dnsoverride.com/](https://www.dnsoverride.com/) (found via
google)?

------
mhuffman
Is this an April Fool's joke since Cloudflare overtly hates privacy (see
stance on TOR)?

~~~
zackbloom
Cloudflare invested a ton of time to create Privacy Pass to make it easier to
use with Tor: [https://blog.cloudflare.com/cloudflare-supports-privacy-
pass...](https://blog.cloudflare.com/cloudflare-supports-privacy-pass/)

------
lepouet
My FAI, Orange in France, seems to block/redirect acces to
[https://1.1.1.1](https://1.1.1.1) , i see great irony here.

Chrome security warning when i try to access it, ping <1ms when ping ip
adress.

~~~
halbritt
It's very likely that they have 1.1.1.1 in their "bogons" list and have for a
very long time.

Bogons are a list of prefixes that most ISPs blackhole as there is usually
never any legitimate traffic bound for those destinations. RFC1918 addresses,
for example.

I can't reach 1.1.1.1 either, but 1.0.0.1 works fine. Maybe try that.

~~~
plb4333
Could it be that 1.1.1.1 is blocked because it uses a secure protocol as
opposed to 1.0.0.1 which is unsecure. This would be for the sake of monitoring
traffic.

------
bogomipz
>"And we wanted to put our money where our mouth was, so we committed to
retaining KPMG, the well-respected auditing firm, to audit our code and
practices annually and publish a public report confirming we're doing what we
said we would."

It's worth pointing out that KPMG was Wells Fargo's independent auditor while
the bank recently committed fraud on a massive scale by creating more than a
million fake deposit accounts and 560,000 credit card applications for
customers without their knowledge or approval.[1]

Calling KPMG a "well-respected auditing firm" when they failed to detect over
a million fake bank accounts is a joke. See:

[https://www.reuters.com/article/wells-fargo-
kpmg/lawmakers-q...](https://www.reuters.com/article/wells-fargo-
kpmg/lawmakers-question-quality-of-kpmgs-wells-fargo-audits-idUSL1N1HX0XL)

[1]
[https://www.warren.senate.gov/files/documents/2016-10-27_Ltr...](https://www.warren.senate.gov/files/documents/2016-10-27_Ltr_to_KPMG_re_Wells_Fargo_Audits_FINAL.pdf)

~~~
jumelles
Genuinely asking, what are some companies that would be a good choice for this
sort of thing?

~~~
chrissnell
Many privacy activists believe that the best proof of a no-logging assertion
is for a court to order a provider to turn over logs and for the company to be
unable to do so.

~~~
geofft
Isn't the court system mostly powered by the threat of serious jail time if
you're found to be lying, and penalties for your lawyers, too?

If you say "We don't have those logs," and you swear to it and a lawyer puts
their name on the filing, it's not like Judge Alsup will start pentesting your
company to find the one employee who accidentally has Dropbox pointed at an
sftp mount of some production server.

------
huxflux
Timeout from Shanghai, China on China Unicom.

Pinging 1.1.1.1 with 32 bytes of data: Request timed out. Request timed out.
Request timed out. Request timed out.

Ping statistics for 1.1.1.1: Packets: Sent = 4, Received = 0, Lost = 4 (100%
loss),

~~~
cocoggu
In Shanghai, Jing'an with China Telecom Fiber

    
    
      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=188.730 ms
      64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=178.453 ms
      64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=179.869 ms
      64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=177.808 ms
    

Google :

    
    
      PING 8.8.8.8 (8.8.8.8): 56 data bytes
      Request timeout for icmp_seq 0
      64 bytes from 8.8.8.8: icmp_seq=1 ttl=42 time=58.368 ms
      Request timeout for icmp_seq 2
      Request timeout for icmp_seq 3
      Request timeout for icmp_seq 4
      64 bytes from 8.8.8.8: icmp_seq=5 ttl=42 time=51.636 ms
      64 bytes from 8.8.8.8: icmp_seq=6 ttl=42 time=55.772 ms
      Request timeout for icmp_seq 7
      64 bytes from 8.8.8.8: icmp_seq=8 ttl=42 time=42.365 ms
      64 bytes from 8.8.8.8: icmp_seq=9 ttl=42 time=45.782 ms
    

Cloudflare seems more stable here

------
switch007
Timeouts when connected to Private Internet Access. Not surprised at all!

(I don't use PIA's DNS because they return IPs for popular sites that are
different to my ISP/Google that cause issues, for some reason.)

------
veidr
Just curious: can somebody shed light on how they got the 1.1.1.1 IP address?

~~~
vidyesh
_APNIC 's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the
addresses were valid, so many people had entered them into various random
systems that they were continuously overwhelmed by a flood of garbage traffic.
APNIC wanted to study this garbage traffic but any time they'd tried to
announce the IPs, the flood would overwhelm any conventional network._

 _We talked to the APNIC team about how we wanted to create a privacy-first,
extremely fast DNS system. They thought it was a laudable goal. We offered
Cloudflare 's network to receive and study the garbage traffic in exchange for
being able to offer a DNS resolver on the memorable IPs. And, with that,
1.1.1.1 was born_

[https://blog.cloudflare.com/announcing-1111/](https://blog.cloudflare.com/announcing-1111/)

~~~
dang
Thanks. Since [https://1.1.1.1/](https://1.1.1.1/) was posted the other day
([https://news.ycombinator.com/item?id=16716606](https://news.ycombinator.com/item?id=16716606)),
we've changed the URL above to that blog post.

------
wnevets
According to grc's dns benchmark tool its not the fastest dns server for me

[https://www.grc.com/dns/benchmark.htm](https://www.grc.com/dns/benchmark.htm)

------
johnhenry
Not relevant, but I just realized that I've been ignoring this post for hours
and I think that it's because the "1.1.1.1" threw me off. I wonder if anyone
else has experienced this?

------
therealmarv
Interesting that [https://dnsleaktest.com/](https://dnsleaktest.com/) does not
work with Cloudflare's DNS... that's a first one for me.

~~~
peterburkimsher
[https://www.immigration.govt.nz](https://www.immigration.govt.nz) also
doesn't work - I just realised when reopening my browser.

Thankfully I noticed quickly, so I knew what the problem would be.

~~~
vavrusa
As it should fail in any validating resolver. The CNAME signature recently
expired:
[http://dnsviz.net/d/www.immigration.govt.nz/dnssec/](http://dnsviz.net/d/www.immigration.govt.nz/dnssec/)

------
BlueGh0st
In Florida I'm getting identical times with 1.1.1.1 and 8.8.8.8 ~56ms

------
herodotus
This looks good, but I assume that any DNS request I make is still routed
through my ISP. Therefore, I assume there is no way to stop my ISP from
keeping a log of every URL I visit. Is that correct?

~~~
_arvin
ISP will be aware of all traffic to your IP, but consider that most people
have their DNS set to use their ISPs, meaning the ISP easily sees this
information in logs. Some people use Google DNS or another provider to bypass
the ISP's DNS, which is a step better.

Now Cloudflare is providing a very fast and privacy-driven DNS, so to me this
is a step up from others (Quad9, OpenDNS being formidable alternatives)

Say you're on a public WIFI and don't want DNS queries from your machine,
there's also DNS-over-HTTPS (which Cloudflare and a couple others support)
which doesn't use the DNS protocol and would make a POST request to say,
[https://1.1.1.1/.well-known/dns-query](https://1.1.1.1/.well-known/dns-query)
instead.

Also with HTTPS, ISPs won't see the full URL, just that a secure connection
was made to that domain.

------
therealmarv
Where can I flush a address there (just asking for DevOps purposes)?

~~~
vimda
By setting a low TTL? Does any recursor allow you to manually flush?

~~~
therealmarv
I can flush Google's DNS entries [https://developers.google.com/speed/public-
dns/cache](https://developers.google.com/speed/public-dns/cache) and OpenDNS
[https://cachecheck.opendns.com/](https://cachecheck.opendns.com/) which is
very handy when you play with your DNS entries of your servers.

------
jason_slack
From someone that takes DNS for granted every day, can someone shed some light
on why the current state of DNS has been called archaic and needs to be
replaced with something better?

~~~
jlgaddis
It basically comes down to being insecure.

It's all plain-text over UDP. This is easily exploited for various purposes:
spoofing (DDoS attacks), surveillance (such as by ISPs), hijacking/tampering,
censorship, privacy concerns, and so on.

As everything else relies on DNS, the DNS must also be secure.

~~~
jason_slack
Are there replacement options being worked on? What about wrapping each
request and unwrapping on the other end. Something like how Tor wraps requests
in many layers?

~~~
jlgaddis
Yes, several: DNS-over-TLS, DNS-over-HTTPS, DNSSEC, DNSCrypt, DNSCurve, and
probably a few others I'm forgetting at the moment.

------
nk1tz
Montreal =>

8.8.8.8 : round-trip min/avg/max/stddev = 35.781/38.241/46.959/2.635 ms

1.1.1.1 : round-trip min/avg/max/stddev = 12.090/14.492/23.095/1.909 ms

------
RKearney
How was Cloudflare able to get a wildcard certificate with IP Address SANs
added to it? How do I obtain one from DigiCert because I don't see the option
on their site.

~~~
prdonahue
Fun fact: they had never issued an IPv6 SAN before (which Safari fails to
validate due to a bug).

Try browsing to
[https://[2606:4700:4700::1111]](https://\[2606:4700:4700::1111\]) with
desktop Safari. (It's a known issue and we're working with Apple to get it
fixed.)

~~~
RKearney
I understand that, and I've had to use the IPv6 address since Comcast is null
routing 1.1.1.1 in my area, but that doesn't explain how a wildcard
certificate was issued with IP addresses in the SAN.

Am I able to buy one for my own website? If so, how? If not, why not? I
couldn't even get past the DigiCert cert selection page since a wildcard cert
can't have SANs, and a SAN cert can't contain a wildcard. The only thing I
haven't tried yet is supplying my own CSR.

------
dpweb
Change DNS in Win10: Control Panel - Network and Internet - Network
Connections - <adapter> (right click) - Properties - Internet Protocol Version
4 (double click)

------
meow81
my results: [https://pastebin.com/TwjakL0Q](https://pastebin.com/TwjakL0Q)

Verizon still the fastest, my ISP, but switched to 1.1.1.1 for the perceived
privacy benefit. The speed difference wouldn't be noticeable for me between
Verizon, Google, Cloudflare.

used
[https://www.grc.com/dns/benchmark.htm](https://www.grc.com/dns/benchmark.htm)

------
y0ghur7_xxx
> Both DNS-over-TLS and DNS-over-HTTPS are open standards. And, at launch,
> we've ensured 1.1.1.1 supports both

I like this. Do the root servers support this too?

------
c8456
well.. for ipv6 doesn't perform that well..

== CloudFlare ==

Ping statistics for 1.1.1.1:

    
    
        Minimum = 10ms, Maximum = 10ms, Average = 10ms
    

Ping statistics for 2606:4700:4700::1111

    
    
        Minimum = 40ms, Maximum = 40ms, Average = 40ms
    

== OpenDNS ==

Ping statistics for 208.67.222.222:

    
    
        Minimum = 38ms, Maximum = 38ms, Average = 38ms
    

Ping statistics for 2620:0:ccc::2:

    
    
        Minimum = 34ms, Maximum = 34ms, Average = 34ms

------
mediaserf
Does anyone know if it caches beyond the specified TTL like some services do?
One of the things I love about Google's is that it honors TTL.

------
aquova
Can someone explain to me what exactly this is? I thought DNS was something to
match URLs with IP addresses? How exactly is it private and fast?

------
sofaofthedamned
How on earth did they get a cert for an IP address?!

~~~
gsich
Place the IP into the "Subject Alternative Name".

~~~
sofaofthedamned
Good to know, thank you!

~~~
gsich
Haven't tried this with Lets Encrypt, but would be nice if this worked there
aswell.

~~~
prdonahue
They don't support this.

------
Justsignedup
Can China block them? I know blocking Google means no Google services but
blocking cloudflare could mean blocking half the internet.

------
rdsubhas
> We will never sell your data or use it to target ads. Period.

Won't sell != Won't collect

> We will never log your IP address (the way other companies identify you)

Never log IP != Never log anything

Bonus: The way other companies identify you ~= There are other ways

Edit: Looks like many people assume I'm nitpicking. So here are more specific
questions:

* Is logging a hashcode of the IP considered as "not logging the IP"?

* Can combination of timestamp, packet info other than end IP (latency, hops, etc), geoIP and other factors be used for deep intelligence?

~~~
eastdakota
I'm fine with nitpicking. Let me try and be clear: We're not logging IPs. We
inherently receive them when they connect to the service, but we don't write
them to disk and flush them quickly (i.e., seconds or minutes). We're not
logging hashes of IPs. We're not logging ASNs of the IPs connecting to the
service. We do log the other parts of a DNS query in order to help prevent
abuse and debug issues. However, we've committed to wiping these logs within
24 hours. We have no interest in doing anything to deanonymize users. We have
a great business based in large part around making the Internet more private
and secure. Logically: we would never sacrifice that great business to get
into a crappy data sharing service.

~~~
feelin_googley
"... a crappy data sharing service."

Do you mean OpenDNS?

~~~
eastdakota
No. I mean most businesses that are based on sharing data. They are low margin
and not very interesting. I was thinking about businesses like Axicom when I
wrote the comment.

Have a ton of respect for David Ulevitch and the whole OpenDNS team. While
OpenDNS started with an ad-supported business model, they've completely
pivoted away from that. Now that they're part of Cisco, I believe their nearly
exclusive revenue stream today is their Umbrella product which is a network
security product aimed at businesses. While I don't know for sure, I'd be
highly surprised if OpenDNS were selling browsing data.

~~~
feelin_googley
What I meant was sharing not browsing data but _DNS lookup data_.

As always, too easy to be misunderstood in comments like these.

------
wemdyjreichert
Thanks, Cloudflare. Not just for the fast DNS (yay!) but also for being one of
the nice tech companies (ahem, Facebook).

------
DyslexicAtheist
so is a DHCP server address of 1.1.1.1 still _perfectly valid_ for wireless
local area networks?

see:
[http://www.revolutionwifi.net/revolutionwifi/2011/03/explain...](http://www.revolutionwifi.net/revolutionwifi/2011/03/explaining-
dhcp-server-1111.html)

~~~
ge0rg
It never was _perfectly valid_. That blog post is incorrect, and network
engineers are perfectly fine arguing against that practice. The IP address
1.1.1.1 was reserved by APNIC and now belongs to the APNIC and Cloudflare
research project.

Assigning an IP address you don't own on a local network usually means that
you cut off access to the actual owner of that address. You might not
(immediately) notice it because you don't need to access anything that's
located there. But it will set you up for unpleasant surprises in the future
when your users (or yourself) want to access a resource that happens to be
located there.

RFC 1918
<[https://tools.ietf.org/html/rfc1918>](https://tools.ietf.org/html/rfc1918>)
provides explicit IP ranges you should use for private resources (10.x.x.x,
~172.16.x.x, 192.168.x.x), which are not routed over the Internet and where
your organization is responsible to avoid IP address conflicts.

------
franga2000
Holy shit! Ping from a server in Germany: 8.8.8.8: 6.4 ms 1.1.1.1: 0.45 ms
That's really impressive! Well done!

~~~
MertsA
The call is coming from inside the data center!
[https://www.youtube.com/watch?v=rkcGm-
pWwsQ](https://www.youtube.com/watch?v=rkcGm-pWwsQ)

------
scooter_de
Too bad this was announced on 1st of April.

~~~
jason_slack
They state why they picked April 1, aka 4/1:

From the article: The only question that remained was when to launch the new
service? This is the first consumer product Cloudflare has ever launched, so
we wanted to reach a wider audience. At the same time, we're geeks at heart.
1.1.1.1 has 4 1s. So it seemed clear that 4/1 (April 1st) was the date we
needed to launch it.

------
milankragujevic
uhm how can you get an ssl cert for an IP?

~~~
rocqua
Apparently, you need to provide it as a Subject Alternative Name (SAN).

This is the entry for the cert used:

    
    
        DNS Name=*.cloudflare-dns.com
        IP Address=1.1.1.1
        IP Address=1.0.0.1
        DNS Name=cloudflare-dns.com
        IP Address=2606:4700:4700:0000:0000:0000:0000:1111
        IP Address=2606:4700:4700:0000:0000:0000:0000:1001

~~~
tialaramex
SAN is the only correct way to write any kind of name for servers on the
Internet in a certificate. The "Common Name" was left as a compatibility
feature like 20 years ago when SANs were invented and then it rusted into
place, but is no longer examined by current Firefox or Chrome browsers for
"real" certificates from the public Internet. Chrome shipped releases for a
while with a bug where they'd complain the server's cert had the wrong "Common
Name" when actually they never checked CN at all, and so it might even have
the right Common Name, but they really meant "Your SANs don't match fool" and
hadn't updated the error text.

Because crappy software (looking at you here OpenSSL) makes writing SANs into
a Certificate Subject Request way harder than it needs to be, a lot of CAs
(including Let's Encrypt) will take a CSR that says "My Common Name is
foo.example" and sigh, and issue a cert which adds SAN dnsName foo.example,
because they know that's what you want. Really somebody should fix the
software, one of these days.

In older Windows versions, SChannel (Microsoft's implementation of SSL/TLS)
doesn't understand ipAddress, and thinks the correct way to match an ipAddress
against a certificate is to turn the address into ASCII text of dotted
decimals and compare that to the dnsName entries. This, unsurprisingly, is not
standards compliant.

It's good to see a CA not trying to fudge this, but the consequence is
probably that if you have older Windows (XP? Maybe even something newer) these
certs don't check out as valid for the site. Eh. Upgrade already.

------
rhabarba
I cannot trust a service provided by a company which implies that Tor users
are mostly bad people. No, thanks.

~~~
zackbloom
Talking about the distribution of traffic over Tor is very different than the
people who use it. Cloudflare built Privacy Pass with the specific intent of
allowing people who use Tor to have a better experience:
[https://blog.cloudflare.com/cloudflare-supports-privacy-
pass...](https://blog.cloudflare.com/cloudflare-supports-privacy-pass/)

~~~
rhabarba
Artificially limiting the choice of browsers is not really something that
should be honored. But I thank you for this insight - I did not know this
link.

------
hennsen
Seems to be either blocked in Germany for T-Mobile LTE networks or built on a
not so stable architecture...

------
pvsukale3
I am not a pro computer Networks.

Quick Question: Can an ISP block DNS Queries or packets to a specific IP
address.

~~~
DesertBattery
ISP can do anything with you DNS traffic. That's why Cloudflare DNS support
DNS-over-TLS.

------
djfergus
Can't ISPs just monitor the DNS protocol and still gather a list of all sites
you visit?

------
phoe-krk
I find it slightly amusing that they do not need to register a domain name for
that one.

~~~
0x006A
to get the ssl certificate they had to get a domain: cloudflare-dns.com, ips
only works as alternative names but not as the main domain name.

~~~
tialaramex
Nope, certificates can be, and sometimes are, issued for plain IP addresses,
yes including in the Web PKI ("proper" certificates that work in common web
browsers).

Because the BRs say that the subject Common Name, if present (which it usually
will be for really crappy software that still doesn't implement standards from
_last god-damn century_) must be chosen from the list of SANs, these
certificates will have an IP address as their CN, plus an ipAddress SAN.

Here is an example, which my records say had an IP address as its only name,
but at time of writing crt.sh is timing out for me so forgive me if this some
completely unrelated cert and I've pasted the wrong one:

[https://crt.sh/?id=346170629](https://crt.sh/?id=346170629)

------
z3t4
Hopefully it will try secondary DNS if main is down, which Google DNS does
not.

------
vinniejames
How does this service, with DNS-over-HTTPS or DNS-over-TLS, compare to
something like DNS Crypt?
[https://www.opendns.com/about/innovations/dnscrypt/](https://www.opendns.com/about/innovations/dnscrypt/)

~~~
jedisct1
[https://dnscrypt.info/faq/](https://dnscrypt.info/faq/)

~~~
vinniejames
I more curious from a practical perspective, the FAQ appers to cliam DNScrypt
gives you most/all of what the others do, with easy setup.

The caveat that a "good amount of servers support the protocol" isn't very
clear, how many is a "good amount"? Does that hold true now? Unsupported
servers appear to fall back to traditional DNS resolution, oer the diagram; is
this not the case with the HTTP/TLS implementations?

------
tracker1
Looks like 1.1.1.1 gets about half the ping time of google's dns for me.

------
moeadham
Is this an april fools joke? We're trusting Cloudflare with privacy now?

------
Scramblejams
Anybody got a howto to get dnsmasq to makes its requests over https or tls?

~~~
jedisct1
You need dnscrypt-proxy for this.

------
riquito
Will the day come when we're able to set the dns on smartphones too?

------
a-b
Any suggestions about anonymous "Search Domains"?

------
relieferator
I wrote up a guide on how to configure a pfSense firewall with CloudFlare DNS
on my blog [here]([https://jasoncoltrin.com](https://jasoncoltrin.com)).

------
adityapatadia
[https://dns.watch/](https://dns.watch/) this is also good one. Proved to be
better than Google for me.

------
quantumofmalice
Will they allow sites with unpopular but legal content, like The Daily
Stormer, to resolve?

Or will this DNS service, like their DDoS service, be at the whim of their
CEO?

------
tbarbugli
> "Why Did We Build It?"

Marketing

------
jlgaddis
_EDIT: Looks like this might be an issue w / my AT&T-provided CPE, sorry!
(more details at the bottom)_

From my vantage point, 1.1.1.1 is inaccessible, while 1.0.0.1 seems to work
just fine.

Comments on the blog post blame this on "various reasons" but, at least in my
case, this seems to be a Cloudflare issue:

    
    
      $ ping -c 5 -q 1.0.0.1
      PING 1.0.0.1 (1.0.0.1) 56(84) bytes of data.
    
      --- 1.0.0.1 ping statistics ---
      5 packets transmitted, 5 received, 0% packet loss, time 4005ms
      rtt min/avg/max/mdev = 34.955/35.737/37.492/0.936 ms
    
      $ ping -c 5 -q 1.1.1.1
      PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
    
      --- 1.1.1.1 ping statistics ---
      5 packets transmitted, 0 received, 100% packet loss, time 4102ms
    
      $ traceroute 1.0.0.1
      traceroute to 1.0.0.1 (1.0.0.1), 30 hops max, 60 byte packets
      [...]
       3  * * *
       4  12.83.79.61 (12.83.79.61)  28.126 ms  28.663 ms  29.110 ms
       5  cgcil403igs.ip.att.net (12.122.132.121)  35.854 ms  37.532 ms  37.510 ms
       6  ae16.cr7-chi1.ip4.gtt.net (173.241.128.29)  33.997 ms  29.083 ms  29.647 ms
       7  xe-0-0-0.cr1-det1.ip4.gtt.net (89.149.128.74)  37.758 ms  35.165 ms  36.620 ms
       8  cloudflare-gw.cr0-det1.ip4.gtt.net (69.174.23.26)  36.946 ms  37.343 ms  38.574 ms
       9  1dot1dot1dot1.cloudflare-dns.com (1.0.0.1)  38.385 ms  36.621 ms  37.157 ms
    
      $ traceroute 1.1.1.1
      traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
      [...]
       3  * * *
       4  12.83.79.61 (12.83.79.61)  30.388 ms 12.83.79.41 (12.83.79.41)  30.601 ms  31.280 ms
       5  cgcil403igs.ip.att.net (12.122.132.121)  37.602 ms  37.873 ms  37.808 ms
       6  ae16.cr7-chi1.ip4.gtt.net (173.241.128.29)  33.441 ms  29.788 ms  29.678 ms
       7  xe-0-0-0.cr1-det1.ip4.gtt.net (89.149.128.74)  35.266 ms  35.124 ms  33.921 ms
       8  cloudflare-gw.cr0-det1.ip4.gtt.net (69.174.23.26)  35.294 ms  35.949 ms  35.455 ms
       9  * * *
      10  * * *
      11  * * *
      12  *^C
    

\----

 _EDIT:_ I have AT&T-provided CPE that I have to use due to 802.1X. If I log
into the device (over HTTP) and use the built-in (web-based) diagnostics
tools, I am able to successfully ping 1.1.1.1 from the device itself:

    
    
      ping successful: icmp seq:0, time=2.364 ms
      ping successful: icmp seq:1, time=1.085 ms
      ping successful: icmp seq:2, time=1.160 ms
      ping successful: icmp seq:3, time=1.245 ms
      ping successful: icmp seq:4, time=0.739 ms
    

These RTTs are _way_ too low, however. The RTT for a ping to the CPE's next-
hop/default gateway comes in at, minimum, ~20 ms.

When pinging 1.1.1.1 from my (pfSense-based) router sitting directly behind
the modem, however, no replies come back from the modem to the router
(confirmed via pcap on the upstream-facing interface).

Thus, it looks like this is an issue with the AT&T CPE (5268AC).

~~~
pgrote
I have ATT and seeing the same issues, but my tracert is different.

    
    
       tracert 1.1.1.1
    
       Tracing route to 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]

over a maximum of 30 hops:

    
    
         1     1 ms     1 ms     1 ms  1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
    
       tracert 1.0.0.1
    
       Tracing route to 1dot1dot1dot1.cloudflare-dns.com [1.0.0.1]

over a maximum of 30 hops:

    
    
         1     3 ms    <1 ms    <1 ms  192.168.1.254
         2    48 ms    18 ms    34 ms  99-153-196-1.lightspeed.stlsmo.sbcglobal.net [99.153.196.1]
         3    19 ms    17 ms    17 ms  64.148.120.125
         4    29 ms    24 ms    18 ms  71.144.225.112
         5    19 ms    18 ms    18 ms  71.144.224.85
         6    19 ms    18 ms    19 ms  12.83.40.161
         7    26 ms    27 ms    26 ms  cgcil403igs.ip.att.net 

[12.122.132.121] 8 27 ms 24 ms 28 ms ae16.cr7-chi1.ip4.gtt.net
[173.241.128.29] 9 32 ms 31 ms 31 ms xe-0-0-0.cr1-det1.ip4.gtt.net
[89.149.128.74] 10 31 ms 31 ms 31 ms cloudflare-gw.cr0-det1.ip4.gtt.net
[69.174.23.26] 11 31 ms 31 ms 35 ms 1dot1dot1dot1.cloudflare-dns.com [1.0.0.1]

In a browser, 1.1.1.1 comes back as connection refused. 1.0.0.1 loads.

~~~
jlgaddis
> _In a browser, 1.1.1.1 comes back as connection refused. 1.0.0.1 loads._

Yep, exactly. Using 1.0.0.1, everything works. Using 1.1.1.1, nothing (ping,
DNS, HTTPS) does.

 _EDIT:_ See earlier comment; looks like an issue w/ the AT&T-provided CPE
(5268AC).

------
anotheryou
It's april 1st, but I don't get the joke here...

------
bedros
how would you setup https with DNS?

------
7ewis
Not April Fools?

This is cool.

------
tajen
> Through the project we protect groups like LGBTQ organizations targeted in
> the Middle East, journalists covering political corruption in Africa, human
> rights workers in Asia, and bloggers on the ground covering the conflict in
> Crimea.

And in occident? Do they protect MRAs and Christians?

I love how their view of political targeting is limited to what the West wants
to impose to all countries. Yet, the organization “A Voice For Men” was
flagged as hate speech for funding the movie The Red Pill (2016), the most
censored movie of 2017 in occident. If they haven’t identified them as
political oppression victims, they don’t know much about Free Speech.

------
originalsimba
The idea is solid on the surface, but I don't trust it's parent. Setting up
hundreds of millions of internet machines to be reliant on a single
corporation's service offerings is asking for disaster, and Cloudflare has a
sleeeeaazy history.

But hey, they say their product is legitimate, so it must be true.

------
yorby
I think that Cloudflare has enough data as-is...

------
chisleu
I'm pretty sure that CloudFlare has people working with US intelligence and
supply information that cant be used in court, requiring parallel
reconstruction..

~~~
zackbloom
What is your evidence of this?

~~~
chisleu
I am not allowed to share that information. I now work for a Infosec/Intel
company. I've worked on IBM/Watson's days systems, and before that I worked at
another Intel Agency. I have terribly worked with Packet Forensics, FBI,
Secret Service, and yes... Cloudflare.

Don't be daft.

~~~
jlgaddis
He asked for _evidence_ , not more unverifiable claims.

I'm not a huge fan of Cloudflare and do not use any of their services but you
can't just go around making shit up and then refuse to back up your claims.

~~~
chisleu
Actually, I have every right to share information that I have.

People can complain and ask for information that I can't provide. That's your
right.

I have the same responsibility to provide proof as you do to believe me, even
if I provided "proof".

Bother someone else.

------
quotemstr
But will it report your DNS lookups to the authorities if Cloudflare's CEO
wakes up one morning and decides he doesn't like you?

Sorry, but I don't trust Cloudflare with anything anymore.

~~~
eganist
This is addressed with commitments and third party audits assuring 24h
retention for IP logs. There are other conversations in this thread
surrounding the viability of those audits, but that's somewhat of a tangential
debate.

This doesn't answer whether or not cloudflare will be able to protect against
someone intercepting their traffic and recording dns lookups independently,
but that's a problem for any dns provider.

------
peterhadlaw
I wish I was joking but is Cloudflare going to just decide one day to stop
resolving domains based on any morning whims of management?

------
ComputerGuru
This is bad, bad, bad advice. You don't set the DNS on your local machine.
That breaks things. The DNS needs to be set at the gateway. If you change your
PC/mac's DNS to an external service, you won't be able to resolve any
addresses on the local network.

Come on, CloudFlare. You guys know better than that. Please stop breaking the
(local) internet.

~~~
lorenzhs
Ordinary users don't _have_ anything that resolves to local IPs, so this is a
non-issue for just about anybody. Plus, many if not most ISP-provided modem-
router-AP-boxes don't let you configure the DNS server they use, making your
recommendation _impossible_ to follow for most users. Someone who runs
services on their local network likely knows enough to do as you say, but for
99% of people, these instructions are exactly what they need.

~~~
Spooky23
Most people own printers and other devices that use local DNS.

Don’t presume that joe public is a simpleton. Millions of people are not.

~~~
lorenzhs
Zeroconf (Avahi/Bonjour) takes care of making that wireless printer work
regardless of which DNS server you’re using.

I’m not insinuating that “joe public” is dumb. He just doesn’t need to care
about DNS on his local network, there’s software that handles it for him.

~~~
wpietri
Yes! People are smart enough to handle most things. But they don't have time
or attention to handle _all_ the things. When we're making technology for
users, we should do our best to make sure they only have to learn about the
things that are important to them.

------
booomagnolia
DNS needs to be moved to a blockchain system yesterday.

After currency, it's close to being the second killer app for blockchain.

Anything else, as in anything centralized, will be vulnerable to random state
actor censorship, be they China, the Google, USG, Turkey or any other
deplorables and is therefore broken.

Namecoin was an early attempt at that (almost as old as bitcoin), but it came
in too early.

Time to restart that train.

