&gt; Frankly, we don’t want to know what you do on the Internet—it’s none of our businessIn the DNS resolver space, what is their business?

Serious question: where is that quote from?  The link above is just to the resolver address.

Yes they have:&quot;Privacy First: Guaranteed.
We will never sell your data or use it to target ads. Period.
We will never log your IP address (the way other companies identify you). And we’re not just saying that. We’ve retained KPMG to audit our systems annually to ensure that we&#x27;re doing what we say.Frankly, we don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical steps to ensure we can’t.&quot;

Both encrypted extensions are of course inspectable at the end-point, which is the privacy model being discussed.What is intriguing to me is why Cloudflare are offering this. Perhaps it is to provide data on traffic that is &#x27;invisible&#x27; to them, as in it doesn&#x27;t currently touch their networks. Possibly as a sales-lead generator.Or is the plan to become dominant and then use DNS blackholing to shutdown malware that is a threat to their systems?

It seems like bait-and-switch though? They tell about DNS over https and dns without logging, and then direct to an installation instruction where you can learn to start to use, &quot;DNS without logging&quot;, but nothing that&#x27;s encrypted? What am I missing?

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

Google is one of the first ones using DNS over HTTPS.BTW if you want to use DNS over HTTPS on Linux&#x2F;Mac I strongly recommend dnscrypt proxy V2 (golang rewrite) <a href="https:&#x2F;&#x2F;github.com&#x2F;jedisct1&#x2F;dnscrypt-proxy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jedisct1&#x2F;dnscrypt-proxy</a> and put e.g. cloudflare in their config toml file to make use of it.

I&#x27;ve switched to cloudflare and none of the dns leak tests are showing my DNS, which I find interesting. They always showed google.

On the contrary, they&#x27;ve taken 2 big steps that are better than ISPs (not sure about Google):* no logging* DNS over HTTPS

They are NOT saying Google is lying and collecting the data. They are saying the business model of Google inherently provides such incentive.Cloudflare is somewhat right: Means, Motive and Opportunity - but for a conviction you have to prove someone acted on the Opportunity. The Motive of Google is tampered with severe risk for loosing trust.Cloudflare can make an argument they are fundamentally better positioned and that is all they do. As with all US based operations the NSA may cook up some convincing counterarguments and we may never know.

&gt; they insinuate that Google both sells and uses DNSI don&#x27;t think it&#x27;s intended to say anything about Google specifically. Keep in mind that there are many other DNS services out there, and some of them are known for being pretty scummy, e.g. replacing NXDOMAIN results with &quot;smart search&quot; &#x2F; ad pages.

Cloudflare is making a public pronouncement that they&#x27;re not going to sell your DNS data nor track your IP address, with the implication that they will also not use the usage data to upsell you services. That&#x27;s about the only additional &quot;privacy&quot; edge they offer.In the same breath, they insinuate that Google both sells and uses DNS usage from their 8.8.8.8 and 8.8.4.4 resolvers.

Where is the technical audit report published? Open access url please.

&gt;&quot;Now, audits are generally not worth very much (even, perhaps even especially, from a Big Four group like KPMG)&quot;Indeed, see the recent KPMG scandal:<a href="https:&#x2F;&#x2F;www.marketwatch.com&#x2F;story&#x2F;kpmg-indictment-suggests-many-who-werent-charged-knew-regulator-data-was-stolen-2018-01-23" rel="nofollow">https:&#x2F;&#x2F;www.marketwatch.com&#x2F;story&#x2F;kpmg-indictment-suggests-m...</a>

Worth noting they have already edited the article (less than 2hours later) and taken out the &quot;We will never log your IP&quot; bit...&quot;We committed to never writing the querying IP addresses to disk and wiping all logs within 24 hours.&quot;&quot;While we need some logging to prevent abuse and debug issues, we couldn&#x27;t imagine any situation where we&#x27;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&#x27;re doing what we said we would.&quot;

Does KPMG employ technology people? I thought they did only financial audits.

How do we know they are not lying (or forced to lie, they are a US company after all)?

&quot;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&#x27;re doing what we say.&quot;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&#x27;t doing something they promised they would not do) they&#x27;re about the best we have.

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

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

That&#x27;s not in fact true.  There are quite a lot of cache misses in the normal course of affairs, to start with.

Root servers get basically no traffic anyway. It&#x27;s basically all cached by recursors.

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

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

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

Using an ip instead of a domain name like this allows the possibility of dns rebinding attacks, right?

Yup, the Subject Alternative Name (often misunderstood as an alias, but &quot;Alternative&quot; here is meant in the sense of this is the Internet&#x27;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 &quot;wildcard&quot; 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&#x27;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&#x27;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 <a href="https:&#x2F;&#x2F;some-dns-server.example&#x2F;" rel="nofollow">https:&#x2F;&#x2F;some-dns-server.example&#x2F;</a> the certificate needs to be for some-dns-server.example (or *.example) and a certificate for 1.1.1.1 doesn&#x27;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 <a href="https:&#x2F;&#x2F;1.1.1.1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;1.1.1.1&#x2F;</a> into browsers...[edited, I have &quot;Servers&quot; on the brain, it&#x27;s _Subject_ Alternative Name, you can use them to name email recipients, and lots of things that aren&#x27;t servers]

Edit: I had not realised what the parent comment here meant, that you can coonect to an IP address without getting an error by adding the IP to the SAN. My explanation bellow is about finding certs installed for a given IP&#x2F;hotname, typically with openssl.Yes, but...This only works if they don&#x27;t use SNI[1]. If they use SNI then you just get the default cert. They might have more certs for other hostnames served on that IP address.1: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Server_Name_Indication" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Server_Name_Indication</a>

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

I can flush Google&#x27;s DNS entries <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;speed&#x2F;public-dns&#x2F;cache" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;speed&#x2F;public-dns&#x2F;cache</a> and OpenDNS <a href="https:&#x2F;&#x2F;cachecheck.opendns.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cachecheck.opendns.com&#x2F;</a> which is very handy when you play with your DNS entries of your servers.

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

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

Anonymized logging to improve the service and security. Is this different from Cloudflare?

Logging: <a href="https:&#x2F;&#x2F;www.quad9.net&#x2F;privacy&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.quad9.net&#x2F;privacy&#x2F;</a>

&quot;Here are some DNS measurements comparing @Google Public DNS, @Quad9DNS and @Cloudflare, v6 and v4. Sourced from AS3320 near Frankfurt. Quad9 is fastest in avg. The proposed v6 address from Cloudflare is not yet working, but the longer ones.&quot;<a href="https:&#x2F;&#x2F;twitter.com&#x2F;webernetz&#x2F;status&#x2F;980055981282484225" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;webernetz&#x2F;status&#x2F;980055981282484225</a>

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

Do you think that ~23ms is going to make any real, perceptible difference to your internet performance? Considering that a) your browser will make any DNS requests it needs in parallel when loading a web page, and b) most DNS requests will be cached anyway.

I don&#x27;t use them (even though I would love to) because it takes approximately 3x as long to reach the server.To compare the two, together with Google&#x27;s DNS as a reference, from a fast connection:<pre><code> 64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=3.62 ms
 64 bytes from 8.8.8.8: icmp_seq=5 ttl=60 time=3.60 ms 
 64 bytes from 9.9.9.9: icmp_seq=5 ttl=60 time=9.20 ms
</code></pre>
...and from a slower (home) connection:<pre><code> 64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=11.1 ms
 64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=11.9 ms
 64 bytes from 9.9.9.9: icmp_seq=5 ttl=59 time=34.2 ms
</code></pre>
Note that I just used the speed of every fifth package instead of the average for five packets in order to keep the comment relatively short and more humanly readable than &quot;rtt min&#x2F;avg&#x2F;max&#x2F;mdev&quot;.

Quad9 not friendly to CDN.<pre><code> $ dig +short @8.8.8.8 icnerd-1e5f.kxcdn.com
 p-rumo00.kxcdn.com.
 188.42.31.172
 $ dig +short @1.1.1.1 icnerd-1e5f.kxcdn.com
 p-rumo00.kxcdn.com.
 188.42.31.172
 $ dig +short @9.9.9.9 icnerd-1e5f.kxcdn.com 
 con-na00.kvcdn.com.
 p-ussj00.kxcdn.com.
 209.58.130.199
 $ dig +short @9.9.9.10 icnerd-1e5f.kxcdn.com
 con-na00.kvcdn.com.
 p-ussj00.kxcdn.com.</code></pre>

<a href="https:&#x2F;&#x2F;quad9.net&#x2F;faq&#x2F;#Is_there_a_service_that_Quad9_offers_that_does_not_have_the_blocklist_or_other_security" rel="nofollow">https:&#x2F;&#x2F;quad9.net&#x2F;faq&#x2F;#Is_there_a_service_that_Quad9_offers_...</a>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.112Unsecure 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.10Note: 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:
<a href="https:&#x2F;&#x2F;quad9.net&#x2F;faq&#x2F;#Is_there_IPv6_support_for_Quad9" rel="nofollow">https:&#x2F;&#x2F;quad9.net&#x2F;faq&#x2F;#Is_there_IPv6_support_for_Quad9</a>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-SubnetUnsecure IPv6: 2620:fe::10 No blocklist, DNSSEC, send EDNS Client-Subnet

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&#x27;s X-Force threat intelligence database and give you filtered results.<a href="https:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2017&#x2F;11&#x2F;20&#x2F;quad9_secure_private_dns_resolver&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2017&#x2F;11&#x2F;20&#x2F;quad9_secure_privat...</a>

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] <a href="https:&#x2F;&#x2F;www.quad9.net&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.quad9.net&#x2F;</a>[2] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16716606" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16716606</a>

I thought so too, especially the emphasis on April 1. But I&#x27;m not sure what the joke is.

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?

Just him. Starhub Fiber:<pre><code> ping 1.1.1.1
 PING 1.1.1.1 (1.1.1.1): 56 data bytes
 64 bytes from 1.1.1.1: icmp_seq=0 ttl=59 time=3.111 ms
 64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=3.172 ms
 64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=3.301 ms
 64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=3.018 ms
 64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=3.218 ms
 ^C
 --- 1.1.1.1 ping statistics ---
 5 packets transmitted, 5 packets received, 0.0% packet loss
 round-trip min&#x2F;avg&#x2F;max&#x2F;stddev = 3.018&#x2F;3.164&#x2F;3.301&#x2F;0.096 ms

</code></pre>
fwiw Google DNS is around the same, 2.942ms average.

M1 Business:<pre><code> 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=3.57 ms
 64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=3.30 ms
 64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=3.31 ms
 64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=3.21 ms
 64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=3.21 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=3.15 ms
 64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=3.17 ms
 64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=2.34 ms
 64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=2.93 ms
 64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=3.19 ms
</code></pre>
MyRepublic:<pre><code> 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=60 time=1.88 ms
 64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=1.93 ms
 64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=1.96 ms
 64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=1.85 ms
 64 bytes from 1.1.1.1: icmp_seq=5 ttl=60 time=1.85 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=59 time=1.86 ms
 64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=1.66 ms
 64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=1.40 ms
 64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=1.38 ms
 64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=1.60 ms
</code></pre>
Looks like Google DNS&#x27;s still a little bit faster.

PING 1.1.1.1 (1.1.1.1): 56 data bytes64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=2.099 ms64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=2.073 ms64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=1.963 ms64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=2.089 msPING 8.8.8.8 (8.8.8.8): 56 data bytes64 bytes from 8.8.8.8: icmp_seq=0 ttl=60 time=1.908 ms64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=1.888 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=1.993 ms64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=1.891 msFrom SG too. Could it be... just you?

~3ms average for both from Western Europe

EU, but my network setup is shitty as one can be:<pre><code> --- 8.8.8.8 ping statistics ---
 23 packets transmitted, 20 received, 13% packet loss, time 22093ms
 rtt min&#x2F;avg&#x2F;max&#x2F;mdev = 37.756&#x2F;51.634&#x2F;75.856&#x2F;12.714 ms

 --- 1.1.1.1 ping statistics ---
 7 packets transmitted, 7 received, 0% packet loss, time 6007ms
 rtt min&#x2F;avg&#x2F;max&#x2F;mdev = 38.920&#x2F;43.627&#x2F;52.355&#x2F;4.547 ms
</code></pre>
same same

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

Just curious if that is from a residential internet connection.

Sorry man :(Things are a bit quicker in the US:64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=0.421 ms64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=0.645 ms

If pings are anything to go by I should probably stay with Google (or my ISP, they ping at 1ms):Pinging 8.8.8.8 with 32 bytes of data:Reply from 8.8.8.8: bytes=32 time&lt;1ms TTL=57Reply from 8.8.8.8: bytes=32 time=1ms TTL=57Reply from 8.8.8.8: bytes=32 time&lt;1ms TTL=57Reply from 8.8.8.8: bytes=32 time&lt;1ms TTL=57Pinging 1.1.1.1 with 32 bytes of data:Reply from 1.1.1.1: bytes=32 time=6ms TTL=57Reply from 1.1.1.1: bytes=32 time=6ms TTL=57Reply from 1.1.1.1: bytes=32 time=6ms TTL=57Reply from 1.1.1.1: bytes=32 time=6ms TTL=57(Switzerland)

Google&#x27;s ones are also faster here by 8ms (Cyprus)

How are you getting those single digit times? I can never get below 15 ms for both Google and CloudFlare. Any tips to improve this or its beyond my control?

You&#x27;re just trying to make Australians jealous aren&#x27;t you?<pre><code> 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</code></pre>

Tokyo, Japan:<pre><code> [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&#x2F;avg&#x2F;max&#x2F;stddev = 2.103&#x2F;2.401&#x2F;2.785&#x2F;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&#x2F;avg&#x2F;max&#x2F;stddev = 1.807&#x2F;1.942&#x2F;2.217&#x2F;0.145 ms
 [mason@iMac-Pro-No-5 fubastardo (master)]$</code></pre>

Anycast is not based on latency, so that&#x27;s normal.

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

From Bogotá, Colombia it is slightly faster than Google:<pre><code> ~% ping 1.1.1.1 
 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=11.0 ms
 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=10.9 ms
 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=10.5 ms
 64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=10.0 ms
 64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=13.0 ms
 64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=10.1 ms
 ^C
 --- 1.1.1.1 ping statistics ---
 6 packets transmitted, 6 received, 0% packet loss, time 5006ms
 rtt min&#x2F;avg&#x2F;max&#x2F;mdev = 10.037&#x2F;10.953&#x2F;13.052&#x2F;1.010 ms

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

Here in London, Cloudflare seems a bit faster:<pre><code> $ ping 1.1.1.1
 PING 1.1.1.1 (1.1.1.1): 56 data bytes
 64 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=2.793 ms
 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=3.010 ms
 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=2.789 ms
 64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=2.963 ms
 64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=2.954 ms
 64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=1.330 ms
 ^C
 --- 1.1.1.1 ping statistics ---
 6 packets transmitted, 6 packets received, 0.0% packet loss
 round-trip min&#x2F;avg&#x2F;max&#x2F;stddev = 1.330&#x2F;2.640&#x2F;3.010&#x2F;0.592 ms

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

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

 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
 64 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=0.390 ms
 64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=0.565 ms
 64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=0.472 ms
 64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=0.556 ms
 64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=0.560 ms
 64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=0.573 ms
 64 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=0.359 ms
 64 bytes from 1.1.1.1: icmp_seq=8 ttl=57 time=0.575 ms
 64 bytes from 1.1.1.1: icmp_seq=9 ttl=57 time=0.543 ms
 64 bytes from 1.1.1.1: icmp_seq=10 ttl=57 time=0.548 ms
</code></pre>
From Zagreb, Croatia. 
I guess that new cloudflare POP is paying off.Edit: formatting

Using ping to compare the two may introduce a skew based on how the two networks prioritize ICMP.For example, from my network google is averaging a faster response by ~.5ms<pre><code> $ ping 1.1.1.1
 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
 64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=28.0 ms
 64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=19.2 ms
 64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=19.1 ms
 64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=19.0 ms
 64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=20.5 ms
 64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=19.6 ms
 ^C
 --- 1.1.1.1 ping statistics ---
 6 packets transmitted, 6 received, 0% packet loss, time 5010ms
 rtt min&#x2F;avg&#x2F;max&#x2F;mdev = 19.043&#x2F;20.950&#x2F;28.072&#x2F;3.226 ms
 
 $ ping 8.8.8.8
 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
 64 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=19.1 ms
 64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=20.1 ms
 64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=20.6 ms
 64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=21.1 ms
 64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=21.9 ms
 64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=19.4 ms
 ^C
 --- 8.8.8.8 ping statistics ---
 6 packets transmitted, 6 received, 0% packet loss, time 5008ms
 rtt min&#x2F;avg&#x2F;max&#x2F;mdev = 19.114&#x2F;20.414&#x2F;21.922&#x2F;0.988 ms
</code></pre>
However, if i do DNS lookups against a few major domains, google is actually slower by ~2ms<pre><code> $ for domain in microsoft.com google.com cloudflare.com facebook.com twitter.com; \
 do cloudflare=$(dig @1.1.1.1 ${domain} | awk &#x27;&#x2F;msec&#x2F;{print $4}&#x27;); \
 google=$(dig @8.8.8.8 ${domain} | awk &#x27;&#x2F;msec&#x2F;{print $4}&#x27;);\
 printf &quot;${domain}:\tcloudflare ${cloudflare}ms\tgoogle ${google}ms\n&quot;;\
 done
 microsoft.com:	cloudflare 22ms	google 23ms
 google.com:		cloudflare 19ms	google 22ms
 cloudflare.com:	cloudflare 19ms	google 23ms
 facebook.com:	cloudflare 21ms	google 20ms
 twitter.com:	cloudflare 19ms	google 21ms
</code></pre>
You&#x27;d have to run a bunch of queries to see if there is an actual impact vs. just an outlier (e.g. the first ping response from cloudflare), just wanted to point it out.

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

Rome: about the same for me.PING 8.8.8.8 (8.8.8.8): 56 data bytes64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=19.145 ms64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=18.927 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=19.258 ms64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=20.000 ms64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=20.428 msPING 1.1.1.1 (1.1.1.1): 56 data bytes64 bytes from 1.1.1.1: icmp_seq=0 ttl=53 time=21.351 ms64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=18.606 ms64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=19.451 ms64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=19.084 ms64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=18.989 ms

Colorado, US1.1.1.1 
round-trip min&#x2F;avg&#x2F;max&#x2F;stddev = 10.984&#x2F;12.221&#x2F;14.909&#x2F;1.239 ms8.8.8.8
round-trip min&#x2F;avg&#x2F;max&#x2F;stddev = 11.022&#x2F;12.702&#x2F;15.102&#x2F;1.317 ms

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

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

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

Comparison from EXCITEL ISP - New Delhi.Microsoft Windows [Version 10.0.16299.309]
(c) 2017 Microsoft Corporation. All rights reserved.C:\Users\ram&gt;tracert 1.1.1.1Tracing route to 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
over a maximum of 30 hops:<pre><code> 1 6 ms 11 ms 5 ms 192.168.1.1
 2 5 ms 5 ms 23 ms 10.4.224.1
 3 * * * Request timed out.
 4 15 ms 7 ms 10 ms 103.56.229.1
 5 * * * Request timed out.
 6 45 ms 56 ms 44 ms 115.255.252.225
 7 86 ms 84 ms 87 ms 62.216.144.77
 8 169 ms 173 ms 175 ms xe-2-0-4.0.cjr01.sin001.flagtel.com [62.216.129.161]
 9 174 ms 174 ms 169 ms ge-2-0-0.0.pjr01.hkg005.flagtel.com [85.95.25.41]
 10 173 ms 174 ms 170 ms xe-3-2-2.0.ejr04.seo002.flagtel.com [62.216.130.25]
 11 171 ms 173 ms 170 ms 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
</code></pre>
Trace complete.C:\Users\ram&gt;tracert 8.8.8.8Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:<pre><code> 1 88 ms 305 ms 98 ms 192.168.1.1
 2 13 ms 98 ms 102 ms 10.4.224.1
 3 * * * Request timed out.
 4 * 16 ms * 10.200.200.1
 5 9 ms 3 ms 8 ms 209.85.172.217
 6 11 ms 5 ms 9 ms 108.170.251.103
 7 40 ms 33 ms 37 ms 209.85.246.164
 8 * 90 ms 89 ms 209.85.241.87
 9 89 ms 86 ms 89 ms 216.239.51.57
 10 * * * Request timed out.
 11 * * * Request timed out.
 12 * * * Request timed out.
 13 * * * Request timed out.
 14 * * * Request timed out.
 15 * * * Request timed out.
 16 * * * Request timed out.
 17 * * * Request timed out.
 18 * * * Request timed out.
 19 87 ms 82 ms 87 ms google-public-dns-a.google.com [8.8.8.8]
</code></pre>
Trace complete.C:\Users\ram&gt;tracert resolver2.opendns.comTracing route to resolver2.opendns.com [208.67.220.220]
over a maximum of 30 hops:<pre><code> 1 3 ms 7 ms 8 ms 192.168.1.1
 2 12 ms 11 ms 41 ms 10.4.224.1
 3 * * * Request timed out.
 4 21 ms 21 ms 51 ms 103.56.229.1
 5 * 62 ms 12 ms 115.248.235.150
 6 * 408 ms 65 ms 115.255.252.229
 7 43 ms 49 ms 40 ms 14.142.22.201.static-Mumbai.vsnl.net.in [14.142.22.201]
 8 * 41 ms 57 ms 172.23.78.237
 9 46 ms 32 ms 29 ms 172.19.138.86
 10 73 ms 46 ms 42 ms 115.110.234.50.static.Mumbai.vsnl.net.in [115.110.234.50]
 11 41 ms 64 ms 44 ms resolver2.opendns.com [208.67.220.220]
</code></pre>
Trace complete.C:\Users\ram&gt;

&gt;5x improvement over Google for me<pre><code> ~ ping -c 10 1.1.1.1
 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=1.15 ms
 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.15 ms
 64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=1.06 ms
 64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=1.04 ms
 64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=1.03 ms
 64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=1.01 ms
 64 bytes from 1.1.1.1: icmp_seq=7 ttl=64 time=1.02 ms
 64 bytes from 1.1.1.1: icmp_seq=8 ttl=64 time=1.07 ms
 64 bytes from 1.1.1.1: icmp_seq=9 ttl=64 time=1.00 ms
 64 bytes from 1.1.1.1: icmp_seq=10 ttl=64 time=0.848 ms

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

 --- 8.8.8.8 ping statistics ---
 10 packets transmitted, 10 received, 0% packet loss, time 9011ms
 rtt min&#x2F;avg&#x2F;max&#x2F;mdev = 6.149&#x2F;6.433&#x2F;6.826&#x2F;0.248 ms</code></pre>

From Norway (fiber), seems to be a bit faster than google:$ ping -c 5 1.1.1.1PING 1.1.1.1 (1.1.1.1): 56 data bytes64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=1.606 ms64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=1.562 ms64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=1.540 ms64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=1.574 ms64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=1.564 ms--- 1.1.1.1 ping statistics ---5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min&#x2F;avg&#x2F;max&#x2F;std-dev = 1.540&#x2F;1.569&#x2F;1.606&#x2F;0.022 ms$ ping -c 5 8.8.8.8PING 8.8.8.8 (8.8.8.8): 56 data bytes64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=9.068 ms64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=8.923 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=8.974 ms64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=8.916 ms64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=8.931 ms--- 8.8.8.8 ping statistics ---5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min&#x2F;avg&#x2F;max&#x2F;std-dev = 8.916&#x2F;8.962&#x2F;9.068&#x2F;0.057 ms

Near Lisbon on residential FTTH:<pre><code> ping dig
 ----------------
 1.1.1.1 3.2 4
 1.0.0.1 2.9 4
 8.8.8.8 36.5 40
 8.8.4.4 36.3 42
</code></pre>
These are only averages though, and by testing a bit more with uncached domains I found the first hit will take a lot longer with cloudflare than with google.

$ ping 1.1.1.1PING 1.1.1.1 (1.1.1.1): 56 data bytes64 bytes from 1.1.1.1: icmp_seq=0 ttl=47 time=214.866 ms64 bytes from 1.1.1.1: icmp_seq=1 ttl=47 time=173.416 ms64 bytes from 1.1.1.1: icmp_seq=2 ttl=45 time=256.007 ms64 bytes from 1.1.1.1: icmp_seq=3 ttl=45 time=196.638 ms64 bytes from 1.1.1.1: icmp_seq=4 ttl=45 time=294.694 ms64 bytes from 1.1.1.1: icmp_seq=5 ttl=45 time=314.883 ms64 bytes from 1.1.1.1: icmp_seq=6 ttl=47 time=335.099 ms(From Singapore)Google&#x27;s 8.8.8.8 has about &lt;4ms

Place the IP into the &quot;Subject Alternative Name&quot;.

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

It&#x27;s just uncommon but supported<a href="https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1095780&#x2F;are-ssl-certificates-bound-to-the-servers-ip-address" rel="nofollow">https:&#x2F;&#x2F;stackoverflow.com&#x2F;questions&#x2F;1095780&#x2F;are-ssl-certific...</a>

SAN is the only correct way to write any kind of name for servers on the Internet in a certificate. The &quot;Common Name&quot; 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 &quot;real&quot; certificates from the public Internet. Chrome shipped releases for a while with a bug where they&#x27;d complain the server&#x27;s cert had the wrong &quot;Common Name&quot; when actually they never checked CN at all, and so it might even have the right Common Name, but they really meant &quot;Your SANs don&#x27;t match fool&quot; and hadn&#x27;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&#x27;s Encrypt) will take a CSR that says &quot;My Common Name is foo.example&quot; and sigh, and issue a cert which adds SAN dnsName foo.example, because they know that&#x27;s what you want. Really somebody should fix the software, one of these days.In older Windows versions, SChannel (Microsoft&#x27;s implementation of SSL&#x2F;TLS) doesn&#x27;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&#x27;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&#x27;t check out as valid for the site. Eh. Upgrade already.

Apparently, you need to provide it as a Subject Alternative Name (SAN).This is the entry for the cert used:<pre><code> 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</code></pre>

per rfc5280:&gt;&quot;4.2.1.6. Subject Alternative Name
The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier(URI). Other options exist, including completely local definitions.&quot;[1][1] <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc5280#section-4.2.1.6" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc5280#section-4.2.1.6</a>

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

It looks like any other TLS connection? Just a guess.

I&#x27;m guessing less &quot;sophisticated reinvention&quot; and usage of existing TLS connection technology. You can use both (even at the same time) with DNScrypt-proxy V2 <a href="https:&#x2F;&#x2F;github.com&#x2F;jedisct1&#x2F;dnscrypt-proxy" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jedisct1&#x2F;dnscrypt-proxy</a> ;)

Any reason why DNS over TLS is preferred over DNSCurve?

If you’re on macOS and would rather do this from the command line:<pre><code> sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1</code></pre>

You can get performance stats over here <a href="https:&#x2F;&#x2F;www.dnsperf.com&#x2F;#!dns-resolvers" rel="nofollow">https:&#x2F;&#x2F;www.dnsperf.com&#x2F;#!dns-resolvers</a>

Nope, certificates can be, and sometimes are, issued for plain IP addresses, yes including in the Web PKI (&quot;proper&quot; 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&#x27;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&#x27;ve pasted the wrong one:<a href="https:&#x2F;&#x2F;crt.sh&#x2F;?id=346170629" rel="nofollow">https:&#x2F;&#x2F;crt.sh&#x2F;?id=346170629</a>

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.

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

As it should fail in any validating resolver. The CNAME signature recently expired: <a href="http:&#x2F;&#x2F;dnsviz.net&#x2F;d&#x2F;www.immigration.govt.nz&#x2F;dnssec&#x2F;" rel="nofollow">http:&#x2F;&#x2F;dnsviz.net&#x2F;d&#x2F;www.immigration.govt.nz&#x2F;dnssec&#x2F;</a>

<a href="https:&#x2F;&#x2F;www.immigration.govt.nz" rel="nofollow">https:&#x2F;&#x2F;www.immigration.govt.nz</a> also doesn&#x27;t work - I just realised when reopening my browser.Thankfully I noticed quickly, so I knew what the problem would be.

Interesting that <a href="https:&#x2F;&#x2F;dnsleaktest.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;dnsleaktest.com&#x2F;</a> does not work with Cloudflare&#x27;s DNS... that&#x27;s a first one for me.

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

<a href="https:&#x2F;&#x2F;cloudflare-dns.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloudflare-dns.com&#x2F;</a> works, however it redirects to <a href="https:&#x2F;&#x2F;1.1.1.1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;1.1.1.1&#x2F;</a>

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&#x27;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 &quot;good&quot; news is that this isn&#x27;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&#x27;s Dunning Kruger, the people who built your device don&#x27;t understand why this was the Wrong Thing™ and won&#x27;t now seek to do better in future. If we&#x27;re lucky they&#x27;ll go out of business, but that&#x27;s the best we can hope for.

Same problem here. It would be nice if Cloudflare created an alias to 1.1.1.1, because I can&#x27;t access it at all.Edit: 1.0.0.1 also takes me to the router configuration screen. And there&#x27;s no configuration setting for it. :(

I am getting ERR_CERT_AUTHORITY_INVALID because my ISP-provided router is intercepting the connection and trying to show me a &quot;helpful&quot; configuration wizard. No Cloudflare DNS for me.To be explicit: This is not Cloudflare&#x27;s fault and we should blame the manufacturer of the router, or the ISP for deploying their custom &quot;friendly&quot; settings. But it is what it is.

Thanks. Since <a href="https:&#x2F;&#x2F;1.1.1.1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;1.1.1.1&#x2F;</a> was posted the other day (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16716606" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=16716606</a>), we&#x27;ve changed the URL above to that blog post.

APNIC&#x27;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&#x27;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&#x27;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<a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;announcing-1111&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;announcing-1111&#x2F;</a>

It is explained on the bottom of the page:Who’s behind this?1.1.1.1 is a partnership between Cloudflare and APNIC.Cloudflare runs one of the world’s largest, fastest networks. APNIC is a non-profit organization managing IP address allocation for the Asia Pacific and Oceania regions.Cloudflare had the network. APNIC had the IP address (1.1.1.1). Both of us were motivated by a mission to help build a better Internet. You can read more about each organization’s motivations on our respective posts: Cloudflare Blog &#x2F; APNIC Blog.

<a href="http:&#x2F;&#x2F;packetlife.net&#x2F;blog&#x2F;2010&#x2F;feb&#x2F;5&#x2F;ripe-plays-with-1-0-0-0-network-apnic-allocation&#x2F;" rel="nofollow">http:&#x2F;&#x2F;packetlife.net&#x2F;blog&#x2F;2010&#x2F;feb&#x2F;5&#x2F;ripe-plays-with-1-0-0-...</a>

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

Does anyone know if it caches beyond the specified TTL like some services do? One of the things I love about Google&#x27;s is that it honors TTL.

That is a good point, though I wasn&#x27;t thinking about it from a security perspective. I was more imagining an ISP or nation that is trying to control content by blocking&#x2F;faking DNS queries. They could block the first DNS query if DNS-over-HTTPS doesn&#x27;t use an IP for the resolver.Of course an ISP or nation could block&#x2F;reroute the IP 1.1.1.1 too, so maybe it doesn&#x27;t matter. Neither way would allow MITM, I was just thinking about ways oppressive ISPs&#x2F;nations could stop DNS-over-HTTPS from working.

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&#x27;s no risk of the protocol being downgraded to HTTP or easily spoofed.So what do you see as the threat profile?

When I&#x27;ve seen DNS-over-HTTPS in the past I&#x27;ve always thought it odd that it&#x27;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&#x27;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.<a href="https:&#x2F;&#x2F;developers.cloudflare.com&#x2F;1.1.1.1&#x2F;dns-over-https&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developers.cloudflare.com&#x2F;1.1.1.1&#x2F;dns-over-https&#x2F;</a>Is there a technical reason the DNS-over-HTTPS resolvers need their upstream resolvers to be looked up by name and not IP?

Official now Privacy and Speed are the goals 
<a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;dns-resolver-1-1-1-1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;dns-resolver-1-1-1-1&#x2F;</a>
<a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;announcing-1111&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;announcing-1111&#x2F;</a>

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.

This is bad. To run your own local DNS server is a part of good parenting. So, to break local services is very bad for us responsible parents, to say the least. I block all outbound DNS lookup except to my ISP. Sometime I redirect lookups to other resolvers (eg. 8.8.8.8) to my local DNS server. I don’t care if some app breaks because of this. Often it’s because of bad programming. So, don’t break local DNS!

Ordinary users don&#x27;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&#x27;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.

I have couple machines in a local network and never cared about them beeing discovarable &#x2F;sharing between.

This is useful for use cases for which that doesn&#x27;t matter. Using your computer or devices at home, on your own wifi, where there is no need to resolve local addresses. Or on public wifi, such as in a café, where there is no need to resolve local addresses, and you don&#x27;t control the gateway.

I&#x27;ve been running my own DNS servers since 1996, when I had my first dedicated connection (an ISDN line.)
I never use my ISP&#x27;s DNS.

How many people have local DNS at home? Not many, I&#x27;d wager. How many know how to access their router? Also not many.Besides, &quot;In your router’s configuration page, locate the DNS server settings.&quot;

Perhaps you missed the sections near the top titled &quot;DNS&#x27;s Privacy Problem&quot; and &quot;DNS&#x27;s Censorship Problem&quot; which explain why not everybody can trust their network operator?

&gt; If you change your PC&#x2F;mac&#x27;s DNS to an external service, you won&#x27;t be able to resolve any addresses on the local network.What does this mean? I have 8.8.8.8&#x2F;8.8.4.4 set and they work fine for resolving things on my local network?I can even connect to things with avahi like `xxyyzz.local`.

Unbound lets you forward queries to nameservers matched by the query (sub-)domain.*.internal queries can be sent to the local nameserver, for example, while others can be forwarded to the public nameserver.Minimal unbound.conf example:<pre><code> forward-zone:
 name: &quot;.&quot;
 forward-addr: 1.1.1.1
 forward-zone:
 name: &quot;internal&quot;
 forward-addr: 10.0.0.1
</code></pre>
Unbound also supports DNS-over-TLS, although stubby&#x27;s implementation is much better. It&#x27;s usually ideal to forward to a local stubby instance instead.

This is bad, bad, bad advice. You don&#x27;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&#x2F;mac&#x27;s DNS to an external service, you won&#x27;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.

9.9.9.9<a href="https:&#x2F;&#x2F;quad9.net" rel="nofollow">https:&#x2F;&#x2F;quad9.net</a> has been serving me well.

Unfortunately, nitpicking is quite necessary. Haven&#x27;t we seen enough instances of corporations lying through omission? Where is the trend that indicates we should give a more favorable, trustworthy reading to terms and promises like these? I don&#x27;t see it.Cloudflare is a for-profit corporation--you know, &quot;duty to shareholders&quot; and all that. We must assume, almost by definition, that they actually have their own self-interests at heart.

Fair point and (maybe) you are right, I am nitpicking but not ashamed to do so. Could have been stronger to say &quot;We won&#x27;t store your data&quot; rather than &quot;We won&#x27;t sell your data&quot;. And frankly, &quot;we will never log your IP address (the way other companies identify you)&quot;, like really? Talking very naively, what if they just store a hashcode or some other derivative of the IP instead, is that counted as logging the IP? And what about the timestamp, geoIP, reverse hostname and other factors, can deep intelligence be used to associate with other behavior?

&gt; the only data is domain name, record and the incoming ipOther data that can be logged:- timestamp - this can be very revealing when correlated with other datasets.j- ASN - can sometimes act like fingerprint on it&#x27;s own, and assists in correlating other data (e.g. the timestamp)- any identifiable variation in the structure or behavior between different DNS resolver implementations. See nmap&#x27;s &quot;-O&quot; option that detects the OS from the TCP&#x2F;IP protocol implementation.

AFAIK the only data is domain name, record and the incoming ip. I don&#x27;t care if they store the first two.Do you have any actual points against or are you just trying to nitpick? And do you have anything better?

It&#x27;s a private organization with no monopoly and lots of competition. Free speech doesn&#x27;t apply here.Also Cloudflare gets vastly more negative opinions that they don&#x27;t check enough and serve too many unsavory sites so it seems there&#x27;s no way to win with the HN crowd.

And since it&#x27;s cloudflare if some site&#x27;s politics don&#x27;t align with the owner&#x27;s politics they&#x27;ll just block it arbitrarily.

No that&#x27;s not fair. Everything is open to criticism.

&quot;I can&#x27;t be arsed to pay $3&#x2F;mo for a VPS that I can tunnel my DNS requests through, so I&#x27;m gonna nitpick on hackernews about a company trying their best to offer it to &#x2F;everyone&#x2F; for free&quot;

Well, the post sort of implies that they log everything for 24 hours, but instead of raw IP addresses they log hashed ones, as they still need to identify everyone. Which, sadly, doesn&#x27;t affect tracking practices at all.

Some more details can be found here: <a href="https:&#x2F;&#x2F;developers.cloudflare.com&#x2F;1.1.1.1&#x2F;commitment-to-privacy&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developers.cloudflare.com&#x2F;1.1.1.1&#x2F;commitment-to-priv...</a>

&quot;... a crappy data sharing service.&quot;Do you mean OpenDNS?

One edit: team corrected me that we do log ASNs in some cases in order to debug issues with networks that may have trouble connecting or have been blocked.

I&#x27;m fine with nitpicking. Let me try and be clear: We&#x27;re not logging IPs. We inherently receive them when they connect to the service, but we don&#x27;t write them to disk and flush them quickly (i.e., seconds or minutes). We&#x27;re not logging hashes of IPs. We&#x27;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&#x27;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.

&gt; We will never sell your data or use it to target ads. Period.Won&#x27;t sell != Won&#x27;t collect&gt; We will never log your IP address (the way other companies identify you)Never log IP != Never log anythingBonus: The way other companies identify you ~= There are other waysEdit: Looks like many people assume I&#x27;m nitpicking. So here are more specific questions:* Is logging a hashcode of the IP considered as &quot;not logging the IP&quot;?* Can combination of timestamp, packet info other than end IP (latency, hops, etc), geoIP and other factors be used for deep intelligence?

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. &#x2F;s

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&#x27;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.

From Shenzhen, China1.1.1.1&#x2F;1.0.0.1 rtt min&#x2F;avg&#x2F;max&#x2F;mdev = 198.036&#x2F;199.739&#x2F;202.978&#x2F;2.319 ms8.8.8.8&#x2F;8.8.4.4 rtt min&#x2F;avg&#x2F;max&#x2F;mdev = 12.798&#x2F;13.681&#x2F;14.408&#x2F;0.673 ms114.114.114.114&#x2F;114.114.115.115 rtt min&#x2F;avg&#x2F;max&#x2F;mdev = 15.508&#x2F;25.381&#x2F;38.815&#x2F;9.842 ms

I&#x27;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&#x27;s probably quite a few networks where 1.x.x.x is unreachable or routed to a local captive network access server, too.

You can also sing that number to the tune of the famous 8675309 song with very little robato.

Hex works too: <a href="https:&#x2F;&#x2F;0x1010101" rel="nofollow">https:&#x2F;&#x2F;0x1010101</a>

You can also use the decimal value of the IP, without the dots: <a href="https:&#x2F;&#x2F;16843009" rel="nofollow">https:&#x2F;&#x2F;16843009</a>

It work as expected if you give it the <a href="http:&#x2F;&#x2F;1.2.3" rel="nofollow">http:&#x2F;&#x2F;1.2.3</a> schema prefix.The input bar is a search bar in modern browsers.

<pre><code> 1.2 -&gt; 1.0.0.2
 1.2.3 -&gt; 1.2.0.3
</code></pre>
But then, much of software would fail here - Firefox&#x2F;Chrome for example would both threat that as bareword and redirect to search page.

Don&#x27;t try that in the wild, most sw out there would ignore spec and use some arbitrary regex to validate IP format.i.e python:<pre><code> octets = ip_str.split(&#x27;.&#x27;)
 if len(octets) != 4:
 raise AddressValueError(&quot;Expected 4 octets in %r&quot; % ip_str)</code></pre>

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:<pre><code> $ 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
</code></pre>
Of course, don&#x27;t expect this to work universally. A lot of software will try to be clever with input validation, and fail.Tangentially related: <a href="https:&#x2F;&#x2F;fosdem.org&#x2F;2018&#x2F;schedule&#x2F;event&#x2F;email_address_quiz&#x2F;" rel="nofollow">https:&#x2F;&#x2F;fosdem.org&#x2F;2018&#x2F;schedule&#x2F;event&#x2F;email_address_quiz&#x2F;</a>

The most useful case for this shortcut is 127.1 -&gt; 127.0.0.1

Interesting question related to this : <a href="https:&#x2F;&#x2F;superuser.com&#x2F;questions&#x2F;486788&#x2F;why-does-pinging-192-168-072-only-2-dots-return-a-response-from-192-168-0-58" rel="nofollow">https:&#x2F;&#x2F;superuser.com&#x2F;questions&#x2F;486788&#x2F;why-does-pinging-192-...</a>

TIL you can also use 1.1 and it will expand to 1.0.0.1<pre><code> $&gt; 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</code></pre>

2606:4700:4700::1111You could make it slightly more memorable by decoding from hex to ascii, but that does not help too much either in this case:&amp; ACK:G NUL: G NUL::1111

<a href="https:&#x2F;&#x2F;developers.cloudflare.com&#x2F;1.1.1.1&#x2F;setting-up-1.1.1.1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developers.cloudflare.com&#x2F;1.1.1.1&#x2F;setting-up-1.1.1.1...</a><pre><code> 2606:4700:4700::1111
 2606:4700:4700::1001
</code></pre>
Not as memorable, unfortunately.

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.

As that article mentions, it wasn&#x27;t &quot;perfectly valid&quot; even back then, it just didn&#x27;t hurt. If I understand the specific implementation mentioned there correctly, it&#x27;ll still work if the interception is done right (only catching DHCP and redirecting it to where it should go, leaving everything else untouched)

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&#x27;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&#x27;t need to access anything that&#x27;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 &lt;<a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc1918&gt;" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc1918&gt;</a> 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.

so is a DHCP server address of 1.1.1.1 still perfectly valid for wireless local area networks?see: <a href="http:&#x2F;&#x2F;www.revolutionwifi.net&#x2F;revolutionwifi&#x2F;2011&#x2F;03&#x2F;explaining-dhcp-server-1111.html" rel="nofollow">http:&#x2F;&#x2F;www.revolutionwifi.net&#x2F;revolutionwifi&#x2F;2011&#x2F;03&#x2F;explain...</a>

I&#x27;m not aware of any pihole native setting to enable a resolver instead of using forwarding.Third-party services like this will also have a huge range of queries cached so the response time will definitely be better than have a rasppi with little free memory try&#x2F;attempt to cache that.

Why isn&#x27;t your pihole a stand-alone DNS resolver instead on relying on 3rd-party services ?

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

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 = 1msPing 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 = 26msPing 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

I&#x27;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)<pre><code> 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)
</code></pre>
I&#x27;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.

yes, quic will make dns over https more resillient to packet loss than a tls based approach.

&gt;The article mentions QUIC as being something that might make HTTPS faster than standard TLS.Even with TLS 1.3 0-RTT?

Thank you for responding, Patrick. As one of the authors of the RFC, your views on this are a great contribution to the conversation.&gt; rfc 8336I&#x27;ll have to read up on this, thanks for the link.&gt; h2 coalescingDNS is already capable of using TCP&#x2F;TLS (and by it&#x27;s nature UDP) for multiple DNS requests at a time. Is there some additional benefit we get here?&gt; h2 pushThis one is interesting, but DNS already has optimizations built in for things like CNAME and SRV record lookups, where the IP is implicitly resolved when available and sent back with the original request. Is this adding something additional to those optimizations?&gt; cachingDNS has caching built-in, TTLs on each record. Is there something this is providing over that innate caching built into the protocol?&gt; it starts to add up to a very interesting story.I&#x27;d love to read about that story, if someone has written something, do you have a link?Also, a question that occurred to me, are we talking about the actual website you&#x27;re connecting to being capable of preemptively passing DNS resolution to web clients over the same connection?Thanks!

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

When we add TLS on top of the protocol, ISPs can only filter based on port at that point. We can run DNS on 443 if that helps, but as you said, static well-known IPs can then be blocked.&gt; I imagine most of the benefit is surely to people who can spin up their own resolvers.There are already many easily run DNS resolvers available. Is there a benefit you see in operating them over HTTPS that improves on that?

I suppose there is also domain fronting [1], but it won&#x27;t be fast or an easy-to-remember IP address anymore. And if you need that, you might need a VPN anyway?[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Domain_fronting" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Domain_fronting</a>

Some ISPs block outbound DNS from customers to anywhere but their resolvers, filtering based on target port.
This is a particularly common trick in countries that attempt to censor the internet.It&#x27;s a lot harder to do that with DNS-over-HTTPS because it looks like normal traffic.That said, in this case ISPs can just null route the IP address of the obvious main resolvers such as 1.1.1.1. I imagine most of the benefit is surely to people who can spin up their own resolvers.

Wonder if this will pave the way for other protocols over HTTPS.

I&#x27;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&#x2F;2, and QUIC. If the simpler, cleaner, and more performant route is taken, it willgbreak when someone screws up &quot;legacy&quot; dns without noticing, because it works in the browser.It&#x27;s not worth the complexity of multiple protocols that do the same thing. And it&#x27;s not worth making the base system insanely complicated so that the magic 4 letters &#x27;http&#x27; can show up.TLS? Yeah, since the simpler secure DNSes failed, we might as well use that. But let&#x27;s try to keep http complexity contained.

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.

Yes! And I plan to actually build in a default setup to use that now that it exists. I should have mentioned up front that this is the most exciting thing to me in the announcement.This is a very exciting development, thank you for posting this.

1.1.1.1 does support DNS-over-TLS as well: <a href="https:&#x2F;&#x2F;developers.cloudflare.com&#x2F;1.1.1.1&#x2F;dns-over-tls&#x2F;" rel="nofollow">https:&#x2F;&#x2F;developers.cloudflare.com&#x2F;1.1.1.1&#x2F;dns-over-tls&#x2F;</a>

Reverse DNS is a lot more difficult than just intercepting DNS requests. Especially with virtual hosts, caching proxies and so on.

How is any of this more secure against your ISP in any case given someone willing to do reverse lookup‘s on IP addresses?If someone controls routers is it not nearly useless?So for example all mobile 4g providers could laugh at this and build a nearly as good database of every site you visit?

No it wouldn&#x27;t. They&#x27;re both encrypted with the same method so they can&#x27;t tell whether http is used or not.

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

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

Cloudflare addresses this in the blog post:There are a couple of different approaches. One is DNS-over-TLS. That takes the existing DNS protocol and adds transport layer encryption. Another is DNS-over-HTTPS. It includes security but also all the modern enhancements like supporting other transport layers (e.g., QUIC) and new technologies like server HTTP&#x2F;2 Server Push. Both DNS-over-TLS and DNS-over-HTTPS are open standards. And, at launch, we&#x27;ve ensured 1.1.1.1 supports both.We think DNS-over-HTTPS is particularly promising — fast, easier to parse, and encrypted.

DNS-over-HTTPS 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, <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-ietf-doh-dns-over-https-04" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;draft-ietf-doh-dns-over-https-04</a>, 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&#x27;t bring myself to raise the priority enough to actually complete the HTTPS impl (granted it&#x27;s not a lot of work, but still, the tests etc, take time).

&gt; We committed to never writing the querying IP addresses to disk and wiping all logs within 24 hours.&gt; Cloudflare&#x27;s business has never been built around tracking users or selling advertising. We don&#x27;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&#x27;t imagine any situation where we&#x27;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&#x27;m not talking about tracking the person making the request. I&#x27;m referring to tracking the hostnames that are being resolved. Given the near 1:1 mapping between user&#x27;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&#x27;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&#x27;s IP.

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?

Montreal =&gt;8.8.8.8 : round-trip min&#x2F;avg&#x2F;max&#x2F;stddev = 35.781&#x2F;38.241&#x2F;46.959&#x2F;2.635 ms1.1.1.1 : round-trip min&#x2F;avg&#x2F;max&#x2F;stddev = 12.090&#x2F;14.492&#x2F;23.095&#x2F;1.909 ms

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.

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&#x27;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.

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.

The Galileo link works for me. It&#x27;s worth pointing out Google at the very least censors as easily as Cloudflare [1].My understanding of Cloudflare&#x27;s policies though are with the exception of exceptionally objectionable content, Cloudflare only takes sites down in response to a court order. I don&#x27;t know if it has been established that DNS is something which operators have a proactive obligation to censor, but I imagine it&#x27;s the kind of thing Cloudflare would go to court over.1- <a href="https:&#x2F;&#x2F;www.vox.com&#x2F;policy-and-politics&#x2F;2017&#x2F;8&#x2F;14&#x2F;16143820&#x2F;godaddy-and-google-wont-host-daily-stormer-domain" rel="nofollow">https:&#x2F;&#x2F;www.vox.com&#x2F;policy-and-politics&#x2F;2017&#x2F;8&#x2F;14&#x2F;16143820&#x2F;g...</a>

&gt;because they were claiming Cloudflare agreed with their ideology.That was a lie. It was a commenter on an article.

Cloudflare is a private company and they&#x27;re free to do what they want but their reasoning for the Daily Stormer termination felt like a convenient excuse to me. I&#x27;m sure that it was the best business decision for them but when I read a blog post touting 1.1.1.1 as being anti-censorship, I roll my eyes.Anti-censorship so long as Matthew Prince doesn&#x27;t have a bad morning.I run my own DNS-over-TLS resolver at a trusted hosting provider. It upstreams to a selection of roots for which I have reasonable trust. My resolver does DNS-over-TLS, DNS-over-HTTPS, and plain DNS. Multiple listening ports for the secure stuff so that I have something that works for most circumstances.

Bear in mind, they dropped Daily Stormer because they were claiming Cloudflare agreed with their ideology. Which someone in the previous discussion pointed out was a Terms of Service violation.DNS resolving offers no such terms and no such reason to make such a claim. I don&#x27;t see that playing here. And bear in mind, when the CEO did it, he wrote about how dangerous it was that companies had that power. I don&#x27;t feel other companies running other DNS services hold that level of concern or awareness.When you consider that their &quot;competitor&quot; in the space of free DNS resolvers with easy-to-remember IPs is Google, who recently tried blocking the word &quot;gun&quot; in Google Shopping... it&#x27;s hard not to see the introduction of a Cloudflare DNS resolver as at least a net positive for resisting censorship. And more options is almost always better.

I probably should have made a clearer point instead of linking to TorrentFreak.I did not mean that I was worried that CloudFlare&#x27;s DNS would start blocking sites whose content they disagree with (although that would also be worrisome).I&#x27;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.

There&#x27;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&#x27;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&#x27;s the only time Cloudflare has ever terminated a customer for objectionable content. Be sure to read the blog post to understand: <a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;why-we-terminated-daily-stormer&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;why-we-terminated-daily-stormer&#x2F;</a>(Disclosure: I work for Cloudflare but I&#x27;m not in a position to set policy.)

Actually, they have already suspended the service for sci-hub, albeit under a court order.<a href="https:&#x2F;&#x2F;yro.slashdot.org&#x2F;story&#x2F;18&#x2F;02&#x2F;05&#x2F;1944225&#x2F;cloudflare-terminates-service-to-sci-hub-domain-names" rel="nofollow">https:&#x2F;&#x2F;yro.slashdot.org&#x2F;story&#x2F;18&#x2F;02&#x2F;05&#x2F;1944225&#x2F;cloudflare-t...</a>

&quot;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&#x27;t talk about the &quot;solution&quot;.&quot;I think there&#x27;s a good way to put this to the test - establish a DNS &quot;mixer&quot; that will randomly direct DNS requests to either 1.1.1.1 or 8.8.8.8 or (whatever) and let the public have access to it.In this way, Cloudflare would bear some small expense from processing these DNS requests (essentially zero) but would receive no information about the initial requestor.It would be interesting to run this experiment and perhaps see some real traffic on the DNS mixer ... and then see how cloudflare responds.Would they block the mixer ?

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&#x27;t talk about the &quot;solution&quot;.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 <a href="https:&#x2F;&#x2F;www.cloudflare.com&#x2F;galileo" rel="nofollow">https:&#x2F;&#x2F;www.cloudflare.com&#x2F;galileo</a>), 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: <a href="https:&#x2F;&#x2F;torrentfreak.com&#x2F;cloudflare-doesnt-want-daily-stormer-evidence-at-piracy-trial-180327&#x2F;" rel="nofollow">https:&#x2F;&#x2F;torrentfreak.com&#x2F;cloudflare-doesnt-want-daily-storme...</a>

ISP can do anything with you DNS traffic. That&#x27;s why Cloudflare DNS support DNS-over-TLS.

yes of course.. common in totalitarian countries

I am not a pro computer Networks.Quick Question: Can an ISP block DNS Queries or packets to a specific IP address.

Timeouts when connected to Private Internet Access. Not surprised at all!(I don&#x27;t use PIA&#x27;s DNS because they return IPs for popular sites that are different to my ISP&#x2F;Google that cause issues, for some reason.)

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?

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?

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.

It&#x27;s very likely that they have 1.1.1.1 in their &quot;bogons&quot; 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&#x27;t reach 1.1.1.1 either, but 1.0.0.1 works fine. Maybe try that.

My AT&amp;T fiber is blocking 1.1.1.1, too. But 1.0.0.1 is working.

My FAI, Orange in France, seems to block&#x2F;redirect acces to <a href="https:&#x2F;&#x2F;1.1.1.1" rel="nofollow">https:&#x2F;&#x2F;1.1.1.1</a> , i see great irony here.Chrome security warning when i try to access it, ping &lt;1ms when ping ip adress.

1.1.1.1: Fast, privacy-first consumer DNS service