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

371–380 of 695 posts

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

#371

Post by anjbe »

deeebug wrote: post #355
anjbe wrote: post #294

Lately I’ve been thinking about some concerns about domain name privacy: • 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 reques…

What’s your threat model? The latency you’re going to introduce with TOR will make everyday browsing slow

It’s not like I’d be running everything over Tor. DNS requests for newly‐visited domains would slow down, but unbound’s prefetch feature would keep popular frequently‐used domains cached. Adding one of those advertising domain blacklists might help performance too.

The point would be to keep Cloudflare from being able to track my DNS requests.

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

#372

Post by forapurpose »

aquis wrote: post #205
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…

Worth noting they have already edited the article (less than 2hours later) and taken out the "We will never log your IP" bit... "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…

> Worth noting they have already edited the article (less than 2hours later) and taken out the "We will never log your IP" bit...

> "We committed to never writing the querying IP addresses to disk ..."

A DNS resolver does need to record the querying IP for at least a few moments because, you know, they have to respond to your query.

However, I don't know why they changed that sentence; it could be for other reasons too.

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

#373

Post by slowsun »

QasimK wrote: post #306
slowsun wrote: post #238

> What many Internet users don't realize is that even if you're visiting a website that is encrypted — has the little green lock in your browser — that doesn't keep your DNS resolver from knowing the identity of all the sites you visit. That means, by default, your ISP, every wifi network you've connected to, and your mobile network provider have a list of every site you've visited while using them. > Network operato…

It’s a step in the right direction. Also is TLS1.3. not supposed to encrypt SNI?

I agree that a non-Google public resolver, which comes with guarantees about how they'll use your data, is a good thing.

I'm taking exception with Cloudflare's announcement, which makes a pitch to end users that CF can protect your domain history from ISP snooping, then links to a two-minute setup guide for people with "no technical skill". They really can't protect your domain history, and I feel bad for people using this service who have been led to believe otherwise.

AFAIK there is nothing in the TLS 1.3 draft [1] about SNI encryption. There are other draft proposals for SNI encryption that build on top of TLS 1.3 [2]. It's a hard problem and there are no deployed solutions I'm aware of.

[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-28

[2] https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00

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

#374

Post by [deleted] »

auxym wrote: post #235
bogomipz wrote: post #113

Earlier quoted context omitted.

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

They were also implicated in tax evasion schemes in Canada. http://www.cbc.ca/news/business/canada-revenue-kpmg-secret-a...

[deleted]

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

#375

Post by jlgaddis »

EDIT: Looks like this might be an issue w/ my AT&T-provided CPE, sorry! (more details at the bottom)

From my vantage point, 1.1.1.1 is inaccessible, while 1.0.0.1 seems to work just fine.

Comments on the blog post blame this on "various reasons" but, at least in my case, this seems to be a Cloudflare issue:

  $ ping -c 5 -q 1.0.0.1
  PING 1.0.0.1 (1.0.0.1) 56(84) bytes of data.

  --- 1.0.0.1 ping statistics ---
  5 packets transmitted, 5 received, 0% packet loss, time 4005ms
  rtt min/avg/max/mdev = 34.955/35.737/37.492/0.936 ms

  $ ping -c 5 -q 1.1.1.1
  PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

  --- 1.1.1.1 ping statistics ---
  5 packets transmitted, 0 received, 100% packet loss, time 4102ms

  $ traceroute 1.0.0.1
  traceroute to 1.0.0.1 (1.0.0.1), 30 hops max, 60 byte packets
  [...]
   3  * * *
   4  12.83.79.61 (12.83.79.61)  28.126 ms  28.663 ms  29.110 ms
   5  cgcil403igs.ip.att.net (12.122.132.121)  35.854 ms  37.532 ms  37.510 ms
   6  ae16.cr7-chi1.ip4.gtt.net (173.241.128.29)  33.997 ms  29.083 ms  29.647 ms
   7  xe-0-0-0.cr1-det1.ip4.gtt.net (89.149.128.74)  37.758 ms  35.165 ms  36.620 ms
   8  cloudflare-gw.cr0-det1.ip4.gtt.net (69.174.23.26)  36.946 ms  37.343 ms  38.574 ms
   9  1dot1dot1dot1.cloudflare-dns.com (1.0.0.1)  38.385 ms  36.621 ms  37.157 ms

  $ traceroute 1.1.1.1
  traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
  [...]
   3  * * *
   4  12.83.79.61 (12.83.79.61)  30.388 ms 12.83.79.41 (12.83.79.41)  30.601 ms  31.280 ms
   5  cgcil403igs.ip.att.net (12.122.132.121)  37.602 ms  37.873 ms  37.808 ms
   6  ae16.cr7-chi1.ip4.gtt.net (173.241.128.29)  33.441 ms  29.788 ms  29.678 ms
   7  xe-0-0-0.cr1-det1.ip4.gtt.net (89.149.128.74)  35.266 ms  35.124 ms  33.921 ms
   8  cloudflare-gw.cr0-det1.ip4.gtt.net (69.174.23.26)  35.294 ms  35.949 ms  35.455 ms
   9  * * *
  10  * * *
  11  * * *
  12  *^C
----

EDIT: I have AT&T-provided CPE that I have to use due to 802.1X. If I log into the device (over HTTP) and use the built-in (web-based) diagnostics tools, I am able to successfully ping 1.1.1.1 from the device itself:

  ping successful: icmp seq:0, time=2.364 ms
  ping successful: icmp seq:1, time=1.085 ms
  ping successful: icmp seq:2, time=1.160 ms
  ping successful: icmp seq:3, time=1.245 ms
  ping successful: icmp seq:4, time=0.739 ms
These RTTs are way too low, however. The RTT for a ping to the CPE's next-hop/default gateway comes in at, minimum, ~20 ms.

When pinging 1.1.1.1 from my (pfSense-based) router sitting directly behind the modem, however, no replies come back from the modem to the router (confirmed via pcap on the upstream-facing interface).

Thus, it looks like this is an issue with the AT&T CPE (5268AC).

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

#376

Post by bogomipz »

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

It's worth pointing out that KPMG was Wells Fargo's independent auditor while the bank recently committed fraud on a massive scale by creating more than a million fake deposit accounts and 560,000 credit card applications for customers without their knowledge or approval.[1]

Calling KPMG a "well-respected auditing firm" when they failed to detect over a million fake bank accounts is a joke. See:

https://www.reuters.com/article/wells-fargo-kpmg/lawmakers-q...

[1] https://www.warren.senate.gov/files/documents/2016-10-27_Ltr...

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

#377

Post by skybrian »

Twirrim wrote: post #189
bluejekyll wrote: post #146

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…

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'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 benef…

I suppose there is also domain fronting [1], but it won't be fast or an easy-to-remember IP address anymore. And if you need that, you might need a VPN anyway?

[1] https://en.wikipedia.org/wiki/Domain_fronting

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

#378

Post by eastdakota »

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…

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

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

#379

Post by thenewwazoo »

bogomipz wrote: post #376

>"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." It's worth pointing out that KPMG was Wells Fargo's independent auditor while the bank recently committed fraud on a massive scale by creating more than a million fake deposit accou…

Speaking as a former KPMG employee who did infosec, the financial audit and controls people are far removed from anyone with technical skill in this domain. It may be cold comfort, but these kinds of special purpose attestations may as well be done by a different company (insert BearingPoint joke here).

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

#380

Post by patrickmcmanus »

forapurpose wrote: post #368
tyingq wrote: post #242

Earlier quoted context omitted.

Sorry, confused. Https requests are prolific, while encrypted DNS requests aren't. Why isn't the former less hard to detect?

Perhaps if the attacker filters traffic first by protocol, it's harder but not at all impossible. I'd guess that DNS-over-HTTPS packets won't be hard to identify by other means.

of course dns over https to cloudflare can be mixed on the same h2 connection with other https to the same host. It starts to get interesting.

(this is one of the advantages of https vs straight tls)

Post reply on HN