221–230 of 695 posts
https://github.com/google/namebench
I remember being in France it was huge speedup over the providers default DNS.
This is the Cloudflare resolver, right? What's the "privacy-first" part about? It's just another third party DNS host. They haven't changed the protocol to be uninspectable and AFAIK haven't made any guarantees about logging or whatnot that would enhance privacy vs. using whatever you are now. This just means you're trusting Cloudflare instead of Comcast or Google or whoever.
"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…
$ 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…
For example, from my network google is averaging a faster response by ~.5ms
$ 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=59 time=28.0 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=19.2 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=19.1 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=19.0 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=20.5 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=19.6 ms
^C
--- 1.1.1.1 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5010ms
rtt min/avg/max/mdev = 19.043/20.950/28.072/3.226 ms
$ 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=54 time=19.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=20.6 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=54 time=21.1 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=54 time=21.9 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=54 time=19.4 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5008ms
rtt min/avg/max/mdev = 19.114/20.414/21.922/0.988 ms
$ for domain in microsoft.com google.com cloudflare.com facebook.com twitter.com; \
do cloudflare=$(dig @1.1.1.1 ${domain} | awk '/msec/{print $4}'); \
google=$(dig @8.8.8.8 ${domain} | awk '/msec/{print $4}');\
printf "${domain}:\tcloudflare ${cloudflare}ms\tgoogle ${google}ms\n";\
done
microsoft.com: cloudflare 22ms google 23ms
google.com: cloudflare 19ms google 22ms
cloudflare.com: cloudflare 19ms google 23ms
facebook.com: cloudflare 21ms google 20ms
twitter.com: cloudflare 19ms google 21ms
Earlier quoted context omitted.
I don't use them (even though I would love to) because it takes approximately 3x as long to reach the server. To compare the two, together with Google's DNS as a reference, from a fast connection: 64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=3.62 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=60 time=3.60 ms 64 bytes from 9.9.9.9: icmp_seq=5 ttl=60 time=9.20 ms ...and from a slower (home) connection: 64 bytes from 1.1.1.1…
Do you think that ~23ms is going to make any real, perceptible difference to your internet performance? Considering that a) your browser will make any DNS requests it needs in parallel when loading a web page, and b) most DNS requests will be cached anyway.
I'm not sure what you meant in point (a) but, of course, DNS cannot be parallelized with HTTP since the browser doesn't know where to connect until DNS completes. Also, DNS requests for subresources can't start until the referring resource has been loaded. So you could easily see a few serialized DNS requests in the long pole for loading a web site.
Also note that the timing above were ping times. An actual DNS query will have to recurse if the result is not cached at the DNS server -- which in these days of 60-second TTLs for is not uncommon. Cloudflare, though, happens to be the authoritative DNS for quite a few web sites, in which case no recursion is necessary.
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…
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 other companies running other DNS services hold that level of concern or awareness.
When you consider that their "competitor" in the space of free DNS resolvers with easy-to-remember IPs is Google, who recently tried blocking the word "gun" in Google Shopping... it's hard not to see the introduction of a Cloudflare DNS resolver as at least a net positive for resisting censorship. And more options is almost always better.
I find it slightly amusing that they do not need to register a domain name for that one.
to get the ssl certificate they had to get a domain: cloudflare-dns.com, ips only works as alternative names but not as the main domain name.
Because the BRs say that the subject Common Name, if present (which it usually will be for really crappy software that still doesn't implement standards from _last god-damn century_) must be chosen from the list of SANs, these certificates will have an IP address as their CN, plus an ipAddress SAN.
Here is an example, which my records say had an IP address as its only name, but at time of writing crt.sh is timing out for me so forgive me if this some completely unrelated cert and I've pasted the wrong one:
I've been a long time user of OpenDNS's public DNS service (and have come to adore it greatly). Other recent new entrant to this space worth mentioning includes Global Cyber Alliance's [0] Quad9 DNS service, launched in Q4 2017.
This to me looks like a good move by Cloudflare, business model wise, given the increasing awareness among general public to the dangers of privacy breaches -- aside from the supposed boost in network speed piggybacking off of Cloudflare's extensive server farm network [1].
Whether the service delivers on it's bold claims, however, is to be seen. I'm going to go give this a shot now.
[0] https://www.globalcyberalliance.org/initiatives/quad9.html [1] https://www.cloudflare.com/network/
Earlier quoted context omitted.
rfc 8336. h2 coalescing. h2 push. caching. it starts to add up to a very interesting story.
Thank you for responding, Patrick. As one of the authors of the RFC, your views on this are a great contribution to the conversation. > rfc 8336 I'll have to read up on this, thanks for the link. > h2 coalescing DNS is already capable of using TCP/TLS (and by it's nature UDP) for multiple DNS requests at a time. Is there some additional benefit we get here? > h2 push This one is interesting, but DNS already has optim…
wrt coalescing/origin/secondary-certificates its a powerful notion to consider your recursive resolver's ability to serve other http traffic on the same connection. That has implications for anti-censorship and traffic analysis.
Additionally the ability to push DNS information that it anticipates you will need outside the real time moment of an additional record has some interesting properties.
DoH right now is limited to the recursive resolver case. But it does lay the groundwork for other http servers being able to publish some DNS information - that's something that needs some deep security based thinking before it can be allowed, but this is a step towards being compatible with that design.
wrt caching - some apps might want a custom dns cache (as firefox does), but some may simply use an existing http cache for that purpose without having to invent a dns cache. leveraging code is good. There are lots of other little things like that which http brings for free - media type negotiation, proxying, authentication, etc..
After currency, it's close to being the second killer app for blockchain.
Anything else, as in anything centralized, will be vulnerable to random state actor censorship, be they China, the Google, USG, Turkey or any other deplorables and is therefore broken.
Namecoin was an early attempt at that (almost as old as bitcoin), but it came in too early.
Time to restart that train.
There’s more to dns performance than query time. Cloudflare doesn’t seem to be sending the EDNS client subnet to authoritative resolvers, which means those resolvers can’t give sensible nearest-to-client responses. This is a crucial feature of what makes the modern web fast.
Cloudflare has a large number of PoPs and are increasing them rapidly. If the service is distributed to them all than the authoritative server is likely to give a response that is similar to that it would have provided if the subnet had been explicitly provided since the Cloudflare PoP sending the request will be located network wise close to the client that originally made the request. This isn't always going to be true but the slightly higher odds that you will not connect to the optimal location for the service you are connecting to is probably worth the increase in privacy.