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

241–250 of 695 posts

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

#241

Post by tialaramex »

Bromskloss wrote: post #222
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…

Does KPMG employ technology people? I thought they did only financial audits.

First of all, KPMG is the name of a group. All the Big Four are arranged as group companies, a single financial entity owns the name (e.g "KPMG", "EY") from some friendly place, (London in all but one case) and licenses out the right to operate a member company to professional services companies in various jurisdictions around the world. The group has the famous name, and sets some rules about training and compliance, but the employees will (almost all) work for the local member companies even though reporting for lay people will say the group name, as they do here.

Secondly, the idea in audit is not really about digging into the engineering. So although they will need people who have some idea what DNS is, they don't need experts - this isn't code review. The auditors tend to spend most of their time looking at paperwork and at policy - so e.g. we don't expect auditors to discover a Raspberry Pi configured for packet logging hidden in a patchbay, but we do expect them to find if "Delete logs every morning" is an ambition and it's not anybody's job to actually do that, nor is it anybody's job to check it got done.

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

#242

Post by tyingq »

IshKebab wrote: post #233
tyingq wrote: post #220

Earlier quoted context omitted.

Dns over https would be harder for governments and other middleman to block or intercept, despite it being less efficient. It would look like any other https request. Especially if browsers agreed to universally support it.

No it wouldn't. They're both encrypted with the same method so they can't tell whether http is used or not.

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

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

#243

Post by discreditable »

tux3 wrote: post #122
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…

You can also use the decimal value of the IP, without the dots: https://16843009

Hex works too: https://0x1010101

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

#244

Post by sigjuice »

avip wrote: post #191
dieulot wrote: post #144

Earlier quoted context omitted.

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

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?

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

#245

Post by chrissnell »

ocdtrekkie wrote: post #225
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…

Bear in mind, they dropped Daily Stormer because they were claiming Cloudflare agreed with their ideology. Which someone in the previous discussion pointed out was a Terms of Service violation. DNS resolving offers no such terms and no such reason to make such a claim. I don't see that playing here. And bear in mind, when the CEO did it, he wrote about how dangerous it was that companies had that power. I don't feel…

Cloudflare is a private company and they're free to do what they want but their reasoning for the Daily Stormer termination felt like a convenient excuse to me. I'm sure that it was the best business decision for them but when I read a blog post touting 1.1.1.1 as being anti-censorship, I roll my eyes.

Anti-censorship so long as Matthew Prince doesn't have a bad morning.

I run my own DNS-over-TLS resolver at a trusted hosting provider. It upstreams to a selection of roots for which I have reasonable trust. My resolver does DNS-over-TLS, DNS-over-HTTPS, and plain DNS. Multiple listening ports for the secure stuff so that I have something that works for most circumstances.

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

#246

Post by kpcyrd »

IshKebab wrote: post #233
tyingq wrote: post #220

Earlier quoted context omitted.

Dns over https would be harder for governments and other middleman to block or intercept, despite it being less efficient. It would look like any other https request. Especially if browsers agreed to universally support it.

No it wouldn't. They're both encrypted with the same method so they can't tell whether http is used or not.

tls isn't magic, you can still observe the encrypted stream and make assumptions based on bytes sent/received on the wire, protocol patterns and timing. See the crime and breach attack.

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

#247

Post by kentonv »

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…

There's a pretty big difference between terminating a business relationship (which is what Cloudflare did to Daily Stormer, and which Google also did a couple days before Cloudflare did) and refusing to answer DNS queries for third-party domains with which there is no business relationship. It's hard to imagine how the former could be used as precedent to compel the latter.

Cloudflare has no interest in censorship -- the whole reason the Daily Stormer thing was such a big deal was because it's the only time Cloudflare has ever terminated a customer for objectionable content. Be sure to read the blog post to understand: https://blog.cloudflare.com/why-we-terminated-daily-stormer/

(Disclosure: I work for Cloudflare but I'm not in a position to set policy.)

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

#248

Post by gpm »

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…

Toronto - (ISP: Bell)

    $ ping 1.1.1.1
    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=55 time=22.0 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=19.7 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=55 time=17.6 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=55 time=20.2 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=55 time=18.2 ms
    ^C
    --- 1.1.1.1 ping statistics ---
    5 packets transmitted, 5 received, 0% packet loss, time 4006ms
    rtt min/avg/max/mdev = 17.691/19.610/22.080/1.559 ms
    [normal@inspiron ~]$ ping 8.8.8.8
    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=56 time=7.12 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=5.28 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=8.24 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=5.28 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=4.01 ms
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=6.37 ms
    ^C
    --- 8.8.8.8 ping statistics ---
    6 packets transmitted, 6 received, 0% packet loss, time 5007ms
    rtt min/avg/max/mdev = 4.014/6.053/8.240/1.380 ms
Post reply on HN