1.1.1.1: Fast, privacy-first consumer DNS service

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

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

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

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

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

* no logging

* DNS over HTTPS

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.

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

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.

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

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

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

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

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

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

PING 8.8.8.8 (8.8.8.8): 56 data bytes

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

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

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

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

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

Things are a bit quicker in the US:

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

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

BTW if you want to use DNS over HTTPS on Linux/Mac I strongly recommend dnscrypt proxy V2 (golang rewrite) https://github.com/jedisct1/dnscrypt-proxy and put e.g. cloudflare in their config toml file to make use of it.

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

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

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

     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/avg/max/stddev = 3.018/3.164/3.301/0.096 ms

What is intriguing to me is why Cloudflare are offering this. Perhaps it is to provide data on traffic that is 'invisible' to them, as in it doesn'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?

https://stackoverflow.com/questions/1095780/are-ssl-certific...

Pinging 8.8.8.8 with 32 bytes of data:

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

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

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

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

Pinging 1.1.1.1 with 32 bytes of data:

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

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

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

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

(Switzerland)

  sudo networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1

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.

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

In the DNS resolver space, what is their business?

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.

    [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)]$

Yes, but...

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

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

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.

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?

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/

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 / APNIC Blog.

     Host                                                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 192.168.1.254                                         0.0%    75    1.3   1.6   1.1  14.8   1.6
  2. bbXXX-XXX-XXX-XX.singnet.com.sg                       0.0%    75    3.4   2.8   1.9  18.7   2.5
  3. 202.166.123.134                                       0.0%    75    3.2   3.5   2.7  15.9   2.0
  4. 202.166.123.133                                       0.0%    75    3.0   3.0   2.4   6.6   0.7
  5. ae8-0.tp-cr03.singnet.com.sg                          0.0%    75    3.1   3.3   2.8   6.9   0.7
  6. ae4-0.tp-er03.singnet.com.sg                          0.0%    75    2.9   3.1   2.6   6.7   0.5
  7. 203.208.191.197                                       0.0%    75    7.8   4.6   2.9  18.3   3.6
  8. 203.208.149.138                                       0.0%    75    3.0   7.5   2.7  67.2  13.4
  9. 203.208.153.126                                       0.0%    75  182.8 186.9 174.4 327.7  20.5
     203.208.172.226
     203.208.172.178
     203.208.158.50
     203.208.152.214
     203.208.173.106
     203.208.149.58
     203.208.149.30
  10. ix-xe-0-1-2-0.tcore2.pdi-palo-alto.as6453.net         0.0%    74  201.4 190.5 183.9 210.1   5.9
  11. if-ae-5-2.tcore2.sqn-san-jose.as6453.net              0.0%    74  181.4 184.7 179.4 197.9   4.6
  12. if-ae-1-2.tcore1.sqn-san-jose.as6453.net              0.0%    74  177.8 177.3 172.0 190.0   4.8
  13. 63.243.205.106                                        0.0%    74  179.2 184.2 179.1 196.2   4.5
  14. 1dot1dot1dot1.cloudflare-dns.com                      0.0%    74  191.9 184.7 172.4 202.3   6.6

Might send CloudFlare a quick email as they'll probably want singtel to correct this.

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

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

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

    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

https://quad9.net has been serving me well.

Besides, "In your router’s configuration page, locate the DNS server settings."

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?

>"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."[1]

[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6

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

Do you have any actual points against or are you just trying to nitpick? And do you have anything better?

    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

    --- 8.8.8.8 ping statistics ---
    23 packets transmitted, 20 received, 13% packet loss, time 22093ms
    rtt min/avg/max/mdev = 37.756/51.634/75.856/12.714 ms

    --- 1.1.1.1 ping statistics ---
    7 packets transmitted, 7 received, 0% packet loss, time 6007ms
    rtt min/avg/max/mdev = 38.920/43.627/52.355/4.547 ms

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

Cloudflare is a for-profit corporation--you know, "duty to shareholders" and all that. We must assume, almost by definition, that they actually have their own self-interests at heart.

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

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

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

So what do you see as the threat profile?

Indeed, see the recent KPMG scandal:

https://www.marketwatch.com/story/kpmg-indictment-suggests-m...

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

I pay them to access the internet, every further information they gather about my internet activity does not mean any benefit for me.

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

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

From MyRepublic 8.8.8.8 is 2 hops shorter and about a millisecond faster.

Disclaimer: I probably don't know what I'm doing :D

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.

I'm in Wellington.

    64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=37.9 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=36.9 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=36.7 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=35.9 ms

    64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=35.4 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=35.2 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=35.2 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=35.7 ms

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

see: http://www.revolutionwifi.net/revolutionwifi/2011/03/explain...

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

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.

  1.2 -> 1.0.0.2
  1.2.3 -> 1.2.0.3

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.

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

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

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

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)

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

Other 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'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's "-O" option that detects the OS from the TCP/IP protocol implementation.

  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

Edit: formatting

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.

The OP did not say that cloudflare is "saying" that. The OP very clearly said they are "insinuating" it. And yes under the heading "DNS's Privacy Problem" the post mentions:

"With all the concern over the data that companies like Facebook and Google are collecting on you,..."

I think that juxtaposition of this statement under a bolded heading of "DNS's Privacy Problem" is very much insinuating that.

>"The trouble with fighting for human freedom is that one spends most of one's time defending scoundrels. For it is against scoundrels that oppressive laws are first aimed, and oppression must be stopped at the beginning if it is to be stopped at all."

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

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

Even with TLS 1.3 0-RTT?

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/attempt to cache that.

So the difference is how long the logs are kept, and possibly what the log data is used for.

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

  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

  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

The input bar is a search bar in modern browsers.

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

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

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

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

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

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

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

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

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

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

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

  1.1/

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

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

i.e python:

    octets = ip_str.split('.')
    if len(octets) != 4:
        raise AddressValueError("Expected 4 octets in %r" % ip_str)

Aside it's strange https everywhere has been pushed aggressively by many here under the bogeyman of ISP adware and spying while completely ignoring the much larger adware and privacy threats posed by the stalking of Google, Facebook and others. It is disingenuous and insincere.

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

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.

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

You guys are 100ms from anywhere cool.

> rfc 8336

I'll have to read up on this, thanks for the link.

> h2 coalescing

DNS is already capable of using TCP/TLS (and by it's nature UDP) for multiple DNS requests at a time. Is there some additional benefit we get here?

> h2 push

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

> caching

DNS has caching built-in, TTLs on each record. Is there something this is providing over that innate caching built into the protocol?

> it starts to add up to a very interesting story.

I'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're connecting to being capable of preemptively passing DNS resolution to web clients over the same connection?

Thanks!

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?

This is a very exciting development, thank you for posting this.

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

Universal free speech is not laudable, it's suicidal. If your free speech doesn't protect you from those who want to take it away, they will win, on a long enough time horizon. They only need to win once.

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

https://github.com/google/namebench

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

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

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

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

I'm not sure what you meant in point (a) but, of course, DNS cannot be parallelized with HTTP since the browser doesn't know where to connect until DNS completes. Also, DNS requests for subresources can't start until the referring resource has been loaded. So you could easily see a few serialized DNS requests in the long pole for loading a web site.

Also note that the timing above were ping times. An actual DNS query will have to recurse if the result is not cached at the DNS server -- which in these days of 60-second TTLs for is not uncommon. Cloudflare, though, happens to be the authoritative DNS for quite a few web sites, in which case no recursion is necessary.

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

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

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

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

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

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

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

wrt coalescing/origin/secondary-certificates its a powerful notion to consider your recursive resolver's ability to serve other http traffic on the same connection. That has implications for anti-censorship and traffic analysis.

Additionally the ability to push DNS information that it anticipates you will need outside the real time moment of an additional record has some interesting properties.

DoH right now is limited to the recursive resolver case. But it does lay the groundwork for other http servers being able to publish some DNS information - that's something that needs some deep security based thinking before it can be allowed, but this is a step towards being compatible with that design.

wrt caching - some apps might want a custom dns cache (as firefox does), but some may simply use an existing http cache for that purpose without having to invent a dns cache. leveraging code is good. There are lots of other little things like that which http brings for free - media type negotiation, proxying, authentication, etc..

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.

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.

That was a lie. It was a commenter on an article.

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

http://www.cbc.ca/news/business/canada-revenue-kpmg-secret-a...

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

Secondly, the idea in audit is not really about digging into the engineering. So although they will need people who have some idea what DNS is, they don't need experts - this isn't code review. The auditors tend to spend most of their time looking at paperwork and at policy - so e.g. we don't expect auditors to discover a Raspberry Pi configured for packet logging hidden in a patchbay, but we do expect them to find if "Delete logs every morning" is an ambition and it's not anybody's job to actually do that, nor is it anybody's job to check it got done.

Anti-censorship so long as Matthew Prince doesn'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.

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

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

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

Reading a little between the lines here, would you say that at some point we effectively replace the existing DNS resolution graph with something implemented entirely over http? Where features like forwarding and proxying would have more common off the shelf tooling?

I can start see a picture here that looks to be more about common/shared code, and less about actual features of the underlying protocols.

If it was easy, it would have been done during the TLS 1.3 process, but after a lot of discussion we're down to basically "Here is what people expect 'SNI encryption' would do for them, here's why all the obvious stuff can't achieve that, and here are some ugly, slow things that could work, now what?"

https://code.google.com/archive/p/namebench/downloads

PING 8.8.8.8 (8.8.8.8): 56 data bytes

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

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

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

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

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

PING 1.1.1.1 (1.1.1.1): 56 data bytes

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

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

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

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

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

I don't think it'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 "smart search" / ad pages.

> a.b

> Part a specifies the first byte of the binary address. Part b is interpreted as a 24-bit value that defines the rightmost three bytes of the binary address. This notation is suitable for specifying (outmoded) Class C network addresses.

[0]: https://linux.die.net/man/3/inet_aton

And SNI… :(

Also Cloudflare gets vastly more negative opinions that they don't check enough and serve too many unsavory sites so it seems there's no way to win with the HN crowd.

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.

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

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

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

  $ 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

Tangentially related: https://fosdem.org/2018/schedule/event/email_address_quiz/

  $ cat 127.1.c
  #include <stdio.h>
  #include <arpa/inet.h>
   
  int main(int argc, char *argv[])
  {
      struct in_addr addr;
   
      if (inet_aton(argv[1], &addr))
          printf("%08x\n", addr.s_addr);
   
      return 0;
  }
  $ make 127.1 CFLAGS=-Wall
  cc -Wall     127.1.c   -o 127.1
  $ ./127.1 1.1
  01000001
  $ ./127.1 127.1
  0100007f

KPMG's risk department - the lawyers' lawyers - appears to be violently allergic to their customers disclosing any report to outside parties. Based on my experience you can get a copy, but first you and the primary customer need to submit some paperwork. And among the conditions you need to agree with is that you don't redistribute the report or its contents.

Disclosure: I deal with security audits and technical aspects of compliance.

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

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.

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

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

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

This is cool.

> 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

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

                                   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

Google is mentioned 13 times in this post and their resolvers 3. That's 16 total mentions of Google in their post.

"to audit our code and practices annually and publish a public report confirming we're doing what we said we would."

I run an investment fund (hedge fund) and we are completing our required annual audit (not by KPMG). It is quite thorough, they manually check balances in our bank accounts directly with the bank, they verify balances directly off blockchain (it's a crypto fund) and have us prove ownership of keys by signing messages, etc. And they do do a due diligence (lots of doodoo there) that we are not doing scammy things like the equivalent of having a raspberry pi attached to the network. Now this is extremely tough of course, and they are limited in what they can accomplish there, but the thought does cross their mind. All firms are different, but from what we've seen most auditors do decent good jobs most of the time. Their reputation can only be hit so many times before their name is no longer valuable to be an auditor.

My-MacBook-Pro:bottle mrkstu$ ping 0 PING 0 (0.0.0.0): 56 data bytes ping: sendto: No route to host

What does this mean? I have 8.8.8.8/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`.

  $ 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

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.

Microsoft Windows [Version 10.0.16299.309] (c) 2017 Microsoft Corporation. All rights reserved.

C:\Users\ram>tracert 1.1.1.1

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

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

C:\Users\ram>tracert 8.8.8.8

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

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

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

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

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

C:\Users\ram>

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

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.

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

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

2) yup

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

I meant that DNS requests are parallelized within the browser. Once it loads the initial resource (html), there might be 10 more dependencies it needs at various different URLs under different domain names. It's usually loading all these dependencies that make up the vast majority of the load time on a complex web page.

Those subsequent DNS requests can of course be made in parallel, so if your DNS latency is 20ms then you're adding ~20ms, not 10 x 20ms.

Even then, DNS is probably making up a small fraction of the overall load time. If a complex page is taking, say, 3000ms to load and render, then adding 20-40ms of DNS time is not going to make a perceptible difference.

I'm not a lawyer, though.

I think it's great if people are running their own DNS. :) But I'm certainly not mad that Cloudflare's offering yet another public alternative. As I said, more choices is better.

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