Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1.1.1.1: Fast, privacy-first consumer DNS service

blog.cloudflare.com

Post reply on HN
Print view View original

141–150 of 695 posts

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#141

Post by Reason077 »

nubela wrote: post #19

$ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=47 time=214.866 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=47 time=173.416 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=45 time=256.007 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=45 time=196.638 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=45 time=294.694 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=45 time=314.883 ms 64 bytes from 1.1.1.1: ic…

Here in London, Cloudflare seems a bit faster:

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

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

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#142

Post by r1ch »

gizmodo59 wrote: post #85
veidr wrote: post #55

Earlier quoted context omitted.

Tokyo, Japan: [mason@iMac-Pro-No-5 fubastardo (master)]$ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=56 time=2.310 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=2.287 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=2.103 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=2.785 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=2.276 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl…

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?

If you're using a cable or DSL modem, most of that latency is from the signal modulation between you and your ISP.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#143

Post by ge0rg »

DyslexicAtheist wrote: post #129

so is a DHCP server address of 1.1.1.1 still perfectly valid for wireless local area networks? see: http://www.revolutionwifi.net/revolutionwifi/2011/03/explain...

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

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

RFC 1918 " rel="nofollow">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.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#144

Post by dieulot »

DyslexicAtheist wrote: post #116

TIL you can also use 1.1 and it will expand to 1.0.0.1 $> ping 1.1 PING 1.1 (1.0.0.1) 56(84) bytes of data. 64 bytes from 1.0.0.1: icmp_seq=1 ttl=55 time=28.3 ms 64 bytes from 1.0.0.1: icmp_seq=2 ttl=55 time=33.0 ms 64 bytes from 1.0.0.1: icmp_seq=3 ttl=55 time=43.6 ms 64 bytes from 1.0.0.1: icmp_seq=4 ttl=55 time=41.7 ms 64 bytes from 1.0.0.1: icmp_seq=5 ttl=55 time=56.5 ms 64 bytes from 1.0.0.1: icmp_seq=6 ttl=55 t…

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

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#145

Post by tscs37 »

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

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

    1.1.1.1:
      P00.5=48.2ms (55.8ms VPN)
      P50.0=32.8ms (37.0ms VPN)
      P95.0=29.1ms (33.0ms VPN)
      P99.5=29.1ms (32.7ms VPN)
    
    8.8.8.8:
      P00.5=225.4ms (71.5ms VPN)
      P50.0=48.0ms  (53.6ms VPN)
      P95.0=44.1ms  (51.3ms VPN)
      P99.5=43.8ms  (50.7ms VPN)
I've noticed I measured with my VPN on, so I put the VPN measurements in brackets behind the nominal values. The 8.8.8.8 benchmark is a bit odd but I repeated it several times with 100 iterations each and this is basically what I get.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#146

Post by bluejekyll »

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

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

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

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

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#147

Post by wtmt »

tbyehl wrote: post #99
dictum wrote: post #48

Earlier quoted context omitted.

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

Could be a precursor to launching an OpenDNS competitor.

Is OpenDNS even as relevant as it was earlier, before Google DNS appeared (and then OpenDNS was bought by Cisco)?

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#148

Post by pdkl95 »

fwgwgwgch wrote: post #89
rdsubhas wrote: post #84

> We will never sell your data or use it to target ads. Period. Won't sell != Won't collect > We will never log your IP address (the way other companies identify you) Never log IP != Never log anything Bonus: The way other companies identify you ~= There are other ways Edit: Looks like many people assume I'm nitpicking. So here are more specific questions: * Is logging a hashcode of the IP considered as "not logging…

AFAIK the only data is domain name, record and the incoming ip. I don'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?

> the only data is domain name, record and the incoming ip

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.

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#149

Post by cromulen »

nubela wrote: post #19

$ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=47 time=214.866 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=47 time=173.416 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=45 time=256.007 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=45 time=196.638 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=45 time=294.694 ms 64 bytes from 1.1.1.1: icmp_seq=5 ttl=45 time=314.883 ms 64 bytes from 1.1.1.1: ic…

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

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

Edit: formatting

Re: 1.1.1.1: Fast, privacy-first consumer DNS service

#150

Post by anonnyj »

bogomipz wrote: post #113
tialaramex wrote: post #17

Earlier quoted context omitted.

"We will never log your IP address (the way other companies identify you). And we’re not just saying that. We’ve retained KPMG to audit our systems annually to ensure that we're doing what we say." Now, audits are generally not worth very much (even, perhaps even especially, from a Big Four group like KPMG), but for this type of thing (verifying that a company isn't doing something they promised they would not do) th…

>"Now, audits are generally not worth very much (even, perhaps even especially, from a Big Four group like KPMG)" Indeed, see the recent KPMG scandal: https://www.marketwatch.com/story/kpmg-indictment-suggests-m...

Seems we need an auditor auditor.
Post reply on HN