I still find myself wondering about things like the iphones DNS service though. You can’t change it while connected to a cell network and it always seemed strange to me that was considered okay.
1.1.1.1: Fast, privacy-first consumer DNS service
381–390 of 695 posts
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#382And look at these ping times: CloudFlare Google DNS Quad9 OpenDNS NewYork 2 msec 1 msec 2 msec 19 msec Toronto 2 msec 28 msec 17 msec 27 msec Atlanta 1 msec 2 msec 1 msec 19 msec Dallas 1 msec 9 msec 1 msec 7 msec San Francisco 3 msec 21 msec 15 msec 20 msec London 1 msec 12 msec 1 msec 14 msec Amsterdam 2 msec 6 msec 1 msec 6 msec Frankfurt 1 msec 9 msec 2 msec 9 msec Tokyo 2 msec 2 msec 81 msec 77 msec Singapore 2…
I live I Greece, Google’s DNS are 20-30% faster.
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#383Is Cloudflare overriding TTLs on RRs?
If I send a request to 1.0.0.1 for a specific RR that I'm 99.9% certain isn't cached (although I didn't check the query logs on the authoritative DNS servers to verify a request actually came in), the response contains the (expected) TTL of 14400.
If I then send the same request to 1.1.1.1, I get a response that is identical except with a TTL of 3591 seconds.
According to the timestamps in my client, the second request was made nine seconds after the first one (3591+9=3600), hence my question: is Cloudflare "overriding" the TTL I explicitly set on this specific RR (14400s) with a different TTL (i.e., 3600s)?
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#384And look at these ping times: CloudFlare Google DNS Quad9 OpenDNS NewYork 2 msec 1 msec 2 msec 19 msec Toronto 2 msec 28 msec 17 msec 27 msec Atlanta 1 msec 2 msec 1 msec 19 msec Dallas 1 msec 9 msec 1 msec 7 msec San Francisco 3 msec 21 msec 15 msec 20 msec London 1 msec 12 msec 1 msec 14 msec Amsterdam 2 msec 6 msec 1 msec 6 msec Frankfurt 1 msec 9 msec 2 msec 9 msec Tokyo 2 msec 2 msec 81 msec 77 msec Singapore 2…
Poznań, Poland
1.1.1.1: ~17ms (the first one took 179ms, but after that it's pretty fast)
8.8.8.8: ~16msRe: 1.1.1.1: Fast, privacy-first consumer DNS service
#385Earlier 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…
Seems like they're just trying to be clear.
It's not uncommon to retain logs like that for debugging purposes, abuse prevention purposes, etc, but then to go back later and wipe them or anonymize them.
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#386EDIT: 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 t…
I have ATT and seeing the same issues, but my tracert is different.
tracert 1.1.1.1
Tracing route to 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1] 1 1 ms 1 ms 1 ms 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
tracert 1.0.0.1
Tracing route to 1dot1dot1dot1.cloudflare-dns.com [1.0.0.1] 1 3 ms In a browser, 1.1.1.1 comes back as connection refused. 1.0.0.1 loads.
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#387>"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).
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.
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#388Earlier 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…
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.
AT&T Fiber Gigabit in Nashville TN.
iMac ~ 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=64 time=0.688 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.814 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.153 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=0.752 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=0.755 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=0.789 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=0.876 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=64 time=0.869 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=64 time=0.830 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=64 time=1.387 ms
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.688/0.891/1.387/0.204 ms
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#389How was Cloudflare able to get a wildcard certificate with IP Address SANs added to it? How do I obtain one from DigiCert because I don't see the option on their site.
Fun fact: they had never issued an IPv6 SAN before (which Safari fails to validate due to a bug). Try browsing to https://[2606:4700:4700::1111] with desktop Safari. (It's a known issue and we're working with Apple to get it fixed.)
I understand that, and I've had to use the IPv6 address since Comcast is null routing 1.1.1.1 in my area, but that doesn't explain how a wildcard certificate was issued with IP addresses in the SAN.
Am I able to buy one for my own website? If so, how? If not, why not? I couldn't even get past the DigiCert cert selection page since a wildcard cert can't have SANs, and a SAN cert can't contain a wildcard. The only thing I haven't tried yet is supplying my own CSR.
Re: 1.1.1.1: Fast, privacy-first consumer DNS service
#390Earlier quoted context omitted.
Where is the technical audit report published? Open access url please.
Having dealt with KPMG recently (which I do at least once a year...), I would not expect to see the report. KPMG's risk department - the lawyers' lawyers - appears to be violently allergic to their customers disclosing any report to outside parties. Based on my experience you can get a copy, but first you and the primary customer need to submit some paperwork. And among the conditions you need to agree with is that y…
> KPMG's risk department - the lawyers' lawyers - appears to be violently allergic to their customers disclosing any report to outside parties.
Isn't that the entire point of such an audit? To be able to present it to outside third-parties?
For examples, Mozilla (CA/B) requires audits for root CAs. The CA must provide a link to the audit on the auditor's public web site -- forwarding a copy or hosting it on their own isn't sufficient.