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

251–260 of 695 posts

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

#251

Post by jvolkman »

ebikelaw wrote: post #240
tssva wrote: post #230

Earlier quoted context omitted.

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 Cloud…

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.

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

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

#252

Post by bluejekyll »

patrickmcmanus wrote: post #228
bluejekyll wrote: post #207

Earlier quoted context omitted.

Thank you for responding, Patrick. As one of the authors of the RFC, your views on this are a great contribution to the conversation. > 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 optim…

this story will evolve as the http ecosystem evolves - but that's part of the point. 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 m…

> There are lots of other little things like that which http brings for free - media type negotiation, proxying, authentication, etc..

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.

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

#253

Post by tialaramex »

markonen wrote: post #232
xioxox wrote: post #212

Earlier quoted context omitted.

Even with https, the name of the site is sent in clear when the connection to the site is established (this is SNI).

Back when they chose this design for SNI, I’m sure someone argued that it was fine because DNS had already leaked the hostname anyway :)

It's really hard to fix this. https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encrypti... is the state of the art -- note that's a Draft, and really, really not finished, help is doubtless welcome.

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

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

#254

Post by telesilla »

s3nnyy wrote: post #250
mastax wrote: post #239

If you want to figure out what the fastest DNS server is for you, I suggest this freeware utility https://www.grc.com/dns/benchmark.htm

Is there a thing like this for macOS?

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

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

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

#255

Post by kentonv »

otoburb wrote: post #14
ajross wrote: post #3

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

Cloudflare is making a public pronouncement that they'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's about the only additional "privacy" 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.

> they insinuate that Google both sells and uses DNS

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.

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

#256

Post by telesilla »

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…

Rome: about the same for me.

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

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

#257

Post by nerdwaller »

sigjuice wrote: post #244
avip wrote: post #191

Earlier quoted context omitted.

Don'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: octets = ip_str.split('.') if len(octets) != 4: raise AddressValueError("Expected 4 octets in %r" % ip_str)

What spec says that 127.1 and 127.0.0.1 are equivalent?

I don’t actually think it’s in a spec formally but is in a common c lib[0].

> 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

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

#258

Post by ebikelaw »

jvolkman wrote: post #251
ebikelaw wrote: post #240

Earlier quoted context omitted.

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.

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

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

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

#259

Post by future31 »

lorenzhs wrote: post #76
ComputerGuru wrote: post #71

This is bad, bad, bad advice. You don't set the DNS on your local machine. That breaks things. The DNS needs to be set at the gateway. If you change your PC/mac's DNS to an external service, you won't be able to resolve any addresses on the local network. Come on, CloudFlare. You guys know better than that. Please stop breaking the (local) internet.

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

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!

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

#260

Post by indigodaddy »

telesilla wrote: post #254
s3nnyy wrote: post #250

Earlier quoted context omitted.

Is there a thing like this for macOS?

Namebench hasn't been updated since 2010, but I just checked and it's running fine on my Sierra box. https://code.google.com/archive/p/namebench/downloads

The browser doesn't open after the operation/queries finish for me on High Sierra
Post reply on HN