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

501–510 of 695 posts

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

#501

Post by ori_b »

chimera77 wrote: post #202
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…

One of the use cases for DNS-over-HTTPS given in the draft was to allow web applications access to DNS directly via existing browser APIs.

I've implemented DNS before. Doing this saves an entire 300 lines of code. At the same time, it makes the DNS server much more complicated. On top of that, implementing a compliant posix libc will now either use a completely different code path, or pull in a huge amount of code to implement HTTP, HTTP/2, and QUIC. If the simpler, cleaner, and more performant route is taken, it willgbreak when someone screws up "legacy" dns without noticing, because it works in the browser.

It's not worth the complexity of multiple protocols that do the same thing. And it's not worth making the base system insanely complicated so that the magic 4 letters 'http' can show up.

TLS? Yeah, since the simpler secure DNSes failed, we might as well use that. But let's try to keep http complexity contained.

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

#502

Post by written »

herodotus wrote: post #362

This looks good, but I assume that any DNS request I make is still routed through my ISP. Therefore, I assume there is no way to stop my ISP from keeping a log of every URL I visit. Is that correct?

No, DNS only deals with domains, not the whole URLs.

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

#503

Post by written »

jason_slack wrote: post #436
jlgaddis wrote: post #423

Earlier quoted context omitted.

It basically comes down to being insecure. It's all plain-text over UDP. This is easily exploited for various purposes: spoofing (DDoS attacks), surveillance (such as by ISPs), hijacking/tampering, censorship, privacy concerns, and so on. As everything else relies on DNS, the DNS must also be secure.

Are there replacement options being worked on? What about wrapping each request and unwrapping on the other end. Something like how Tor wraps requests in many layers?

https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...

+ DNS-over-TLS for privacy

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

#504

Post by rhabarba »

zackbloom wrote: post #495
rhabarba wrote: post #279

I cannot trust a service provided by a company which implies that Tor users are mostly bad people. No, thanks.

Talking about the distribution of traffic over Tor is very different than the people who use it. Cloudflare built Privacy Pass with the specific intent of allowing people who use Tor to have a better experience: https://blog.cloudflare.com/cloudflare-supports-privacy-pass...

Artificially limiting the choice of browsers is not really something that should be honored. But I thank you for this insight - I did not know this link.

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

#505

Post by lopmotr »

quotemstr wrote: post #325

But will it report your DNS lookups to the authorities if Cloudflare's CEO wakes up one morning and decides he doesn't like you? Sorry, but I don't trust Cloudflare with anything anymore.

Especially since they advertise being actively involved in certain political movements and promise to defend those ones. That's a scarily biased attitude for a DNS. How does someone's sexuality have anything to do with IP address lookups?

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

#506

Post by xuande »

ocdtrekkie wrote: post #454
ENOTTY wrote: post #447

Earlier quoted context omitted.

Really hoping this question gets answered. It seemed contradictory to me.

My strong impression is that they wouldn't give APNIC any data that can be used to identify users of their DNS service, but I'd definitely love a more detailed answer than what the site currently provides.

Found this: https://labs.apnic.net/?p=1127

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

#507

Post by gsich »

lossolo wrote: post #484
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…

> to audit our code and practices annually and publish a public report confirming we're doing what we said we would Some exec to developer: Hey John, KPMG wrote to us that they will be here on friday to make an audit, lets just remove those 10 lines that until audit finishes. I don't want to imply anything about Cloudflare here, just a comment about how useful that kind of private audits are generally.

That's just it, it's not verifiable. Proving something by letting one audit doesn't change that. It's similar when companies get certified by ISO9001 or 270001, it doesn't prove much.

Publishing the full source code could help a little bit, but not much; one doesn't know what code is actually running.

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

#508

Post by _arvin »

herodotus wrote: post #362

This looks good, but I assume that any DNS request I make is still routed through my ISP. Therefore, I assume there is no way to stop my ISP from keeping a log of every URL I visit. Is that correct?

ISP will be aware of all traffic to your IP, but consider that most people have their DNS set to use their ISPs, meaning the ISP easily sees this information in logs. Some people use Google DNS or another provider to bypass the ISP's DNS, which is a step better.

Now Cloudflare is providing a very fast and privacy-driven DNS, so to me this is a step up from others (Quad9, OpenDNS being formidable alternatives)

Say you're on a public WIFI and don't want DNS queries from your machine, there's also DNS-over-HTTPS (which Cloudflare and a couple others support) which doesn't use the DNS protocol and would make a POST request to say, https://1.1.1.1/.well-known/dns-query instead.

Also with HTTPS, ISPs won't see the full URL, just that a secure connection was made to that domain.

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

#510

Post by dfox »

tialaramex wrote: post #253
markonen wrote: post #232

Earlier quoted context omitted.

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…

It is hard because of the TLS's pre-PFS legacy and to some extent also because of (very meaningful) intention to reduce roundtrips. The way to do SNI-like stuff is obvious: negotiate unauthenticated encrypted channel (by means of some EDH variant, you need one roundtrip for that) and perform any endpoint authentication steps inside that channel. This is what SSH2 does and AFAIK Microsoft's implementation of encrypted ISO-on-TCP (eg. rdesktop) does something similar.

Edit: in SSH2 the server authentication happens in the first cryptographic message from server (for the obvious efficiency reasons), and thus for doing SNI-style certificate selection there would have to be some plaintext server-ID in first clients message, but the security of the protocol does not require that as long as the in-tunnel authentication is mutual (it is for things like kerberos).

Post reply on HN