1.1.1.1: Fast, privacy-first consumer DNS service • Hacker News Board

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

#171

Post by ValentineC » Sun, Apr 01, 2018, 2:40 PM UTC

wakokueh wrote: post #26

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 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=2.099 ms 64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=2.073 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=1.963 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=2.089 ms PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=60 time=1.908 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=1.888 ms 64 bytes from…

M1 Business:

  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

MyRepublic:

  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

Looks like Google DNS's still a little bit faster.

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

#172

Post by 0x006A » Sun, Apr 01, 2018, 2:40 PM UTC

phoe-krk wrote: post #50

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

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.

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

#173

Post by ebikelaw » Sun, Apr 01, 2018, 2:41 PM UTC

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.

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

#174

Post by oneweekwonder » Sun, Apr 01, 2018, 2:42 PM UTC

aexaey wrote: post #134

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…

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

It work as expected if you give it the http://1.2.3 schema prefix.

The input bar is a search bar in modern browsers.

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

#175

Post by zackbloom » Sun, Apr 01, 2018, 2:45 PM UTC

antoncohen wrote: post #133

Someone1234 wrote: post #111

Earlier quoted context omitted.

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

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

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

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

#176

Post by JD557 » Sun, Apr 01, 2018, 2:46 PM UTC

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

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

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

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

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

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

#177

Post by zackbloom » Sun, Apr 01, 2018, 2:47 PM UTC

JD557 wrote: post #176

I wish that they talked a bit more about their stance regarding censorship. They have a small paragraph talking about the problem, but they don't talk about the "solution". While Cloudflare has been pretty neutral about censoring sites in the past (notably, pirate sites), the Daily Stormer incident put them in a though spot[1]. They talk a bit about Project Galileo (the link is broken BTW, it should be https://www.cl…

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

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

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

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

#178

Post by pvsukale3 » Sun, Apr 01, 2018, 2:48 PM UTC

I am not a pro computer Networks.

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

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

#179

Post by opencl » Sun, Apr 01, 2018, 2:49 PM UTC

akquise wrote: post #120

cptskippy wrote: post #75

Earlier quoted context omitted.

The whole point of encrypting DNS traffic is to hide it from the likes of Google.

For me personally it is much more important to hide my DNS traffic from my ISP instead of Google, etc., even though I don't live in the US. I pay them to access the internet, every further information they gather about my internet activity does not mean any benefit for me.

Hiding DNS traffic from your ISP is pointless when you have to give them the IP that gets resolved anyway for them to route your traffic.

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

#180

Post by mandelbulb » Sun, Apr 01, 2018, 2:52 PM UTC

0x0 wrote: post #100

infinisil wrote: post #12

9.9.9.9 [1] has been praised by a bunch of people in the thread from a couple days ago [2]. How do those two compare? [1] https://www.quad9.net/ [2] https://news.ycombinator.com/item?id=16716606

Note that 9.9.9.9 is NOT a regular DNS service and does not give you an unrestricted view of the global internet domain name system. They match your requests with IBM's X-Force threat intelligence database and give you filtered results. https://www.theregister.co.uk/2017/11/20/quad9_secure_privat...

https://quad9.net/faq/#Is_there_a_service_that_Quad9_offers_...

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