Live data from Hacker News

1.1.1.1: Fast, privacy-first consumer DNS service

blog.cloudflare.com

451–460 of 695 posts

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

#451

Earlier quoted context omitted.

I do know about this story. The purpose of the fake accounts was to meet sales quotas. Fees earned for the bank were accidental and usually nonexistent, for the obvious reason that if you charge your unwitting customer money, they are much more likely to realize they have an account with you.

>"Fees earned for the bank were accidental and usually nonexistent," "Approximately 85,000 of the accounts opened incurred fees, totaling $2 million. Customers' credit scores were also likely hurt by the fake accounts.[43] The bank was able to prevent customers from pursuing legal action as the opening of an account mandated customers enter into private arbitration with the bank." "The bank paid $110 million to consu…

I'm pretty confident that when 85,000 out of "more than a million" accounts earn fees, it's fair to say that fees are "usually nonexistent". You're talking about accounts that Wells Fargo didn't want and fees that it assessed by mistake. By a normal analysis, that wouldn't be a scandal of any kind, and it would call for no more than returning the accidental fees, without a 55x punitive damages award.

> "The bank was able to prevent customers from pursuing legal action as the opening of an account mandated customers enter into private arbitration with the bank."

That's really not going to work if the customer didn't intend to open the account. The fact that (by your numbers) average damages among those who were damaged at all were up to $23.50 may have had more to do with lack of legal action by customers.

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

#452

Earlier quoted context omitted.

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.

Wonder if this will pave the way for other protocols over HTTPS.

Hopefully not. One needs to stop working around crappy setups from crappy networks. Which X-over-HTTPS really is all about.

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

#453

Earlier quoted context omitted.

If you are on ethernet, I am able to get 1-2ms pings. On same AT&T Fiber Gigabit. Wifi ruins both bandwidth and latency for me.

I'm on Ethernet and fiber all the way. This may have to do more with how AT&T has constructed their fiber in this region. Where do you live? https://chrissnell.com/hn/traceroute-1.1.1.1.png

How did you get that beautiful traceroute output?

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

#454
post #447

So, one thing I'd love to see clarified: APNIC was interested in studying the junk traffic to 1.1.1.1. Cloudflare's DNS will not log or track. So what is logged and tracked for APNIC's research purposes? Everything but DNS? Everything but DNS and HTTPS requests directly to 1.1.1.1 (presumably people looking for details on Cloudflare DNS?). What's being studied? Fun fact: CCNA classes regularly use 1.1.1.1 as a router…

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.

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

#455

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

Genuinely asking, what are some companies that would be a good choice for this sort of thing?

As genuine as your question is, there are no good answers. The way we ended up with a Big Four is that the Fifth member of the Big Five (Arthur Andersen) audited Enron, essentially telling everybody that it wasn't an enormous fraud, but it was. All the senior people at AA avoided jail but the audit firm was so obviously untrustworthy it folded. But that doesn't mean the other Four are fine, it just means the "Too Big To Fail" problem is far worse for audit firms than for banking. If we took down one of the Big Four it would probably tank the whole world economy, and they know that, which is Not Good.

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

#456
post #429

Earlier quoted context omitted.

Right, that's why it's amusing to think we're supposed to believe that KPMG are going to audit a code base and logging infrastructure.

Agreed. Anecdotal but... We have had to supply information to KPMG “IT Auditors” at a client due to some software we wrote. In most cases the auditors are young grads who have never worked in an actual IT/software dev team. So they have very naive view and never ask the right questions. If one wanted to hide something it would be super easy.

Audits provide reasonable assurance, not total. When auditors test access controls for a homegrown application for example, it is unreasonable to ask that a full code review is done to check 100% that checking the box next to Admin confers that, and that checking Read Only restricts it always. In my experiences performing these tests (as a young grad who had never worked on a software dev team), we would ask what the permissions were designed to provide and limit, and observe in the system that they did that. If a developer had programmed a backdoor that when you press A+B+3 and whisper into a microphone grants unlogged admin access, our test would miss that. But that's why we also test change controls and who has access to push to live, etc.

Edit - and to speak more to the topic at hand, there were plenty of people at the firm I worked with who absolutely had the technical expertise to perform such an in depth audit. They are simply engaged when higher levels of assurance are required. What level of scrutiny should your auditors provide your bathroom time monitoring system?

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

#457

Earlier quoted context omitted.

Where are you testing from? I'm going to guess: a datacenter. Residential customers won't see anything this fast. I'm in a small town in Kansas, connected by 1 Gbit ATT fiber. I'm getting ~26ms to 1.1.1.1 and ~19ms to my private DNS resolver that I host in a datacenter in Dallas. Google DNS comes in around 19ms. I suspect that Cloudflare and Google DNS both have POPs in Dallas, which accounts for the similar numbers…

Comcast in Northern NJ USA about 45 MI from NYC $ 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=56 time=10.8 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=11.3 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=10.7 ms 64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=10.9 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=60 time=10.7…

From a residential connection in New Zealand:

    $ ping 1.1.1.1

    Pinging 1.1.1.1 with 32 bytes of data:
    Reply from 1.1.1.1: bytes=32 time=4ms TTL=60
    Reply from 1.1.1.1: bytes=32 time=4ms TTL=60
    Reply from 1.1.1.1: bytes=32 time=4ms TTL=60
    Reply from 1.1.1.1: bytes=32 time=4ms TTL=60

    $ ping 8.8.8.8

    Pinging 8.8.8.8 with 32 bytes of data:
    Reply from 8.8.8.8: bytes=32 time=27ms TTL=60
    Reply from 8.8.8.8: bytes=32 time=27ms TTL=60
    Reply from 8.8.8.8: bytes=32 time=27ms TTL=60
    Reply from 8.8.8.8: bytes=32 time=28ms TTL=60
Seems that 1.1.1.1 is even faster than my local ISP's primary DNS:

    $ ping 202.180.64.10

    Pinging 202.180.64.10 with 32 bytes of data:
    Reply from 202.180.64.10: bytes=32 time=11ms TTL=61
    Reply from 202.180.64.10: bytes=32 time=11ms TTL=61
    Reply from 202.180.64.10: bytes=32 time=11ms TTL=61
    Reply from 202.180.64.10: bytes=32 time=11ms TTL=61

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

#458

For the Cloudflare folks hanging around: Please, please, please add some basic "features" (like Google does) that will help when troubleshooting resolution! For example, the following will show the unicast IP address of the server you're hitting when using 8.8.8.8: $ dig @8.8.8.8 txt o-o.myaddr.l.google.com. +short Additionally, with one other DNS query, we can get a list of what netblocks are being used (for Google…

I think i have questions to Google: [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short "74.125.46.8" "edns0-client-subnet 92.223.114.166/32" [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short "74.125.46.11" "edns0-client-subnet 176.36.247.0/24" [user@v-fed-1 ~]$ dig txt o-o.myaddr.l.google.com @8.8.8.8 +short "74.125.74.3" "edns0-client-subnet 94.181.44.185/32" [user@v-fed-1 ~]$ dig txt…

What is your question? I think we're seeing load balancing here.

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

#459
post #430

Earlier quoted context omitted.

Keep in mind that ping time isn't the only factor in DNS lookup speed. For me (sonic.net in Palo Alto): ping 1.1.1.1: ~22ms ping 8.8.8.8: ~19ms dig @1.1.1.1: ~45ms dig @8.8.8.8: ~70ms Disclaimer: Eyeballed averages over a few samples. A more rigorous test of DNS lookup times would be cool to see. Disclosure: I work for Cloudflare, but not on DNS.

I'm guessing Google's resolvers are a little busier than Cloudflare's right now, because pretty much nobody not on HN right now is hitting them. Will be a more interesting comparison in 6 months.

I'd be surprised if increased load has a negative effect on 1.1.1.1's performance.

We run a homogeneous architecture -- that is, every machine in our fleet is capable of handling every type of request. The same machines that currently handle 10% of all HTTP requests on the internet, and handle authoritative DNS for our customers, and serve the DNS F root server, are now handling recursive DNS at 1.1.1.1. These machines are not sitting idle. Moreover, this means that all of these services are drawing from the same pool of resources, which is, obviously, enormous. This service will scale easily to any plausible level of demand.

In fact, in this kind of architecture, a little-used service is actually likely to be penalized in terms of performance because it's spread so thin that it loses cache efficiency (for all kinds of caches -- CPU cache, DNS cache, etc.). More load should actually make it faster, as long as there is capacity, and there is a lot of capacity.

Meanwhile, Cloudflare is rapidly adding new locations -- 31 new locations in March alone, bringing the current total to 151. This not only adds capacity for running the service, but reduces the distance to the closest service location.

In the past I worked at Google. I don't know specifically how their DNS resolver works, but my guess is that it is backed by a small set of dedicated containers scheduled via Borg, since that's how Google does things. To be fair, they have way too many services to run them all on every machine. That said, they're pretty good at scheduling more instances as needed to cover load, so they should be fine too.

In all likelihood, what really makes the difference is the design of the storage layer. But I don't know the storage layer details for either Google's or Cloudflare's resolvers so I won't speculate on that.

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

#460
post #281

Earlier quoted context omitted.

0 , which is a shorthand for 0.0.0.0 is likely the most code-golf-y way to write localhost , as many [EDIT: Linux] systems alias 0.0.0.0 to 127.0.0.1: $ ping 0 PING 0 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.032 ms Of course, don't expect this to work universally. A lot of software will try to be clever with input validation, and fail. Tangentially related: https://fosdem.or…

0.0.0.0 is not localhost. It's "any address".

Yes, you're right.

What I was trying to say is - On Linux, INADDR_ANY (0.0.0.0) supplied to connect() or sendto() calls is treated as a synonym for INADDR_LOOPBACK (127.0.0.1) address.

Not so for bind() or course.

Post reply on HN