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.
"Privacy First: Guaranteed.
We will never sell your data or use it to target ads. Period.
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.
Frankly, we don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical steps to ensure we can’t."
They want fast resolution of names that point to websites hosted by Cloudflare. Cloudflare makes their money selling their network to businesses that use it, and anything that makes that service better for the end-user increases customer stickiness.
Maybe not _as_ relevant, but still a considerable number of clients are configured to trust OpenDNS, and their far more ambiguous stance on what exactly this is for is appealing to some people. For example, OpenDNS says yes, absolutely it is their business what you're looking up, and maybe you are a Concerned Parent™ who wants to ensure their children don't access RedTube, so that feels like a good idea.
I was thinking more along the lines of their SME offering. DNS filtering is an important layer in network security and CloudFlare’s position of being in the middle of a large portion of Internet traffic, alongside now trying to attract a chunk of general DNS queries, potentially gives them a great deal of insight into who the bad actors are.
Did you read the page? They're supporting DNS over TLS and DNS over HTTPS - both changes to the protocol to make in uninspectable. They've also said they're not logging IP info and they're getting independent auditors in to confirm what they're saying. Sounds trustworthy to me
Both encrypted extensions are of course inspectable at the end-point, which is the privacy model being discussed.
What is intriguing to me is why Cloudflare are offering this. Perhaps it is to provide data on traffic that is 'invisible' to them, as in it doesn't currently touch their networks. Possibly as a sales-lead generator.
Or is the plan to become dominant and then use DNS blackholing to shutdown malware that is a threat to their systems?
Cloudflare is already a significant enough player in handling Internet traffic. Maybe the company does want to do good for the sake of doing good, but I’m wary of companies taking over in this manner and making the Internet more like a monolith than a distributed system.
The goal is to make the sites that use Cloudflare ridiculously fast by putting the authoritative and recursive DNS on the same machine (for clients who use 1.1.1.1).
It seems like bait-and-switch though? They tell about DNS over https and dns without logging, and then direct to an installation instruction where you can learn to start to use, "DNS without logging", but nothing that's encrypted? What am I missing?
Google is one of the first ones using DNS over HTTPS.
BTW if you want to use DNS over HTTPS on Linux/Mac I strongly recommend dnscrypt proxy V2 (golang rewrite) https://github.com/jedisct1/dnscrypt-proxy and put e.g. cloudflare in their config toml file to make use of it.
Not really. Typically the query includes much more information (the site you want to visit) than the response (an IP potentially shared by thousands or millions of sites).
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 can't achieve that, and here are some ugly, slow things that could work, now what?"
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).
So, it feels like you're saying this is how SSH2 and rdesktop work, and then you caveat that by saying well, no, they actually don't offer this capability at all it turns out.
You are correct that you can do this if you spend one round trip first to set up the channel, and both the proposals for how we might encrypt SNI in that Draft do pay a round trip. Which is why I said they're slow and ugly. And as you noticed, SSH2 and rdesktop do not, in fact, spend an extra round trip to buy this capability they just go without.
This does not make sense. Either people are not concerned about hiding their traffic or if they are it follows they would be equally if not much more concerned about Google that can track them across devices and build far more indepth invasive profiles than the ISP.
Aside it's strange https everywhere has been pushed aggressively by many here under the bogeyman of ISP adware and spying while completely ignoring the much larger adware and privacy threats posed by the stalking of Google, Facebook and others. It is disingenuous and insincere.
I can only really discuss the UK, since that's the only place where I've bought home ISP service.
Only a handful of small specialist firms actually just move bits in the UK. Every single UK ISP big enough to advertise on television is signed up to filter traffic and block things for being "illegal" or maybe if Hollywood doesn't like them, or if they have "naughty" words mentioned, or just because somebody slipped. If you're thinking "Not mine" and it runs TV adverts then, oops, nope, you're wrong about that and have had your Internet censored without realising it. I wonder how ISPs got their bad reputation...
Cloudflare is making a public pronouncement that they're not going to sell your DNS data nor track your IP address, with the implication that they will also not use the usage data to upsell you services. That's about the only additional "privacy" edge they offer.
In the same breath, they insinuate that Google both sells and uses DNS usage from their 8.8.8.8 and 8.8.4.4 resolvers.
They are NOT saying Google is lying and collecting the data. They are saying the business model of Google inherently provides such incentive.
Cloudflare is somewhat right: Means, Motive and Opportunity - but for a conviction you have to prove someone acted on the Opportunity. The Motive of Google is tampered with severe risk for loosing trust.
Cloudflare can make an argument they are fundamentally better positioned and that is all they do. As with all US based operations the NSA may cook up some convincing counterarguments and we may never know.
>"They are NOT saying Google is lying and collecting the data."
The OP did not say that cloudflare is "saying" that. The OP very clearly said they are "insinuating" it. And yes under the heading "DNS's Privacy Problem" the post mentions:
"With all the concern over the data that companies like Facebook and Google are collecting on you,..."
I think that juxtaposition of this statement under a bolded heading of "DNS's Privacy Problem" is very much insinuating that.
Bear in mind, Google's changed its mind before and can again at any time. For instance, when they bought DoubleClick they promised not to connect it with the Google account data they had. Then they changed that policy later.
Is the suggestion that a company whose main business is targeting ads based on collecting data about you might be collecting data about you an unfair insinuation?
Please follow the thread - the question of whether an insinuation if "fair" is not what's being discussed. What's being discussed is whether or not Cloudflare said or insinuated that there were privacy concerns with using 8.8.8.8.
> they insinuate that Google both sells and uses DNS
I don't think it's intended to say anything about Google specifically. Keep in mind that there are many other DNS services out there, and some of them are known for being pretty scummy, e.g. replacing NXDOMAIN results with "smart search" / ad pages.
"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) they're about the best we have.
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 you don't redistribute the report or its contents.
Disclosure: I deal with security audits and technical aspects of compliance.
> 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.
You'd think, but it's surprisingly difficult to get the real full audit report. Mozilla's root policy _does_ require that they be shown the report, and has a bunch of extra requirements in there to ensure they're more detail, rather than some summary or overview document the auditors were persuaded to produce for this purpose. But the CA/B rules would allow just an audit letter which basically almost always says "Yes, we did an audit, and everything is fine" unless the auditors weren't comfortable writing "everything is fine". And almost always they feel that a footnote on a sub-paragraph buried in a detailed report is enough to leave "everything is fine" as the headline in the letter...
If you've ever been audited for some other reason, you'll know they find lots of things, and then you fix them, and that's "fine". But well, is it fine? Or, should we acknowledge that they found lots of things and what those things were, even if you subsequently fixed them? The CA/B says you have several months to hand over your letter after the audit period. Guess what those months are spent doing...
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 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 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.
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.
I think it's somewhere in between, the article itself states:
"to audit our code and practices annually and publish a public report confirming we're doing what we said we would."
I run an investment fund (hedge fund) and we are completing our required annual audit (not by KPMG). It is quite thorough, they manually check balances in our bank accounts directly with the bank, they verify balances directly off blockchain (it's a crypto fund) and have us prove ownership of keys by signing messages, etc. And they do do a due diligence (lots of doodoo there) that we are not doing scammy things like the equivalent of having a raspberry pi attached to the network. Now this is extremely tough of course, and they are limited in what they can accomplish there, but the thought does cross their mind. All firms are different, but from what we've seen most auditors do decent good jobs most of the time. Their reputation can only be hit so many times before their name is no longer valuable to be an auditor.
I think the whole point for such free services is to log that data and extract statistical meaning out of it - in this case, they pledge to use an anonymized format. On the other hand CloudFlare's mission (ensure secure, solid end to end connectivity) is much better aligned with the user's needs than Google's mission (sell more ads).
Yup, the Subject Alternative Name (often misunderstood as an alias, but "Alternative" here is meant in the sense of this is the Internet's _Alternative_ way to name things versus the X.500 series directory hierarchy that the X.509 certificates are originally intended for) can be one of several distinct types, the two relevant for servers are dnsName and ipAddress. dnsName can be any er, name, in the DNS hierarchy, or, as a special case, a "wildcard" with asterisks, whereas ipAddress can be any type of IP address, currently either IPv4 or IPv6.
The Baseline Requirements agreed between Web Browser vendors and root Certificate Authorities dictate how the CA can figure out if an applicant is allowed a certificate for a particular name, for dnsNames this is the Ten Blessed Methods, for ipAddress the rules are a bit... eh, rusty, but the idea is you can't get one for that dynamic IP you have from your cable provider for 24 hours, but somebody who really controls the IP address can get one. They're uncommon, but not rare, maybe a dozen a day are issued?
Your web browser requires that the name in the URL exactly matches the name in the certificate. So if you visit https://some-dns-server.example/ the certificate needs to be for some-dns-server.example (or *.example) and a certificate for 1.1.1.1 doesn't work, even if some-dns-server.example has IP address 1.1.1.1 - so this cert is only useful because they want people actually typing https://1.1.1.1/ into browsers...
[edited, I have "Servers" on the brain, it's _Subject_ Alternative Name, you can use them to name email recipients, and lots of things that aren't servers]
Thanks for the clarification. I did know it was possible when setting up CA's for VPN servers, they can use certificates with DNS and/or IP as identifiers. Somehow I never thought about certificates for public IP addresses.
Edit: I had not realised what the parent comment here meant, that you can coonect to an IP address without getting an error by adding the IP to the SAN. My explanation bellow is about finding certs installed for a given IP/hotname, typically with openssl.
Yes, but...
This only works if they don't use SNI[1]. If they use SNI then you just get the default cert. They might have more certs for other hostnames served on that IP address.
Cloudflare is saying they won't log and will have audits by KPMG yearly to prove as such. Not logging and logging anonymized data are different approaches.
FTA: 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.
So the difference is how long the logs are kept, and possibly what the log data is used for.
"Here are some DNS measurements comparing @Google Public DNS, @Quad9DNS and @Cloudflare, v6 and v4. Sourced from AS3320 near Frankfurt. Quad9 is fastest in avg. The proposed v6 address from Cloudflare is not yet working, but the longer ones."
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: icmp_seq=5 ttl=58 time=11.1 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=11.9 ms
64 bytes from 9.9.9.9: icmp_seq=5 ttl=59 time=34.2 ms
Note that I just used the speed of every fifth package instead of the average for five packets in order to keep the comment relatively short and more humanly readable than "rtt min/avg/max/mdev".
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 meant that DNS requests are parallelized within the browser. Once it loads the initial resource (html), there might be 10 more dependencies it needs at various different URLs under different domain names. It's usually loading all these dependencies that make up the vast majority of the load time on a complex web page.
Those subsequent DNS requests can of course be made in parallel, so if your DNS latency is 20ms then you're adding ~20ms, not 10 x 20ms.
Even then, DNS is probably making up a small fraction of the overall load time. If a complex page is taking, say, 3000ms to load and render, then adding 20-40ms of DNS time is not going to make a perceptible difference.
Is there a service that Quad9 offers that does not have the blocklist or other security?
The primary IP address for Quad9 is 9.9.9.9, which includes the blocklist, DNSSEC validation, and other security features. However, there are alternate IP addresses that the service operates which do not have these security features. These might be useful for testing validation, or to determine if there are false positives in the Quad9 system.
Secure IP: 9.9.9.9 Provides: Security blocklist, DNSSEC, No EDNS Client-Subnet sent. If your DNS software requires a Secondary IP address, please use the secure secondary address of 149.112.112.112
Unsecure IP: 9.9.9.10 Provides: No security blocklist, DNSSEC, sends EDNS Client-Subnet. If your DNS software requires a Secondary IP address, please use the unsecure secondary address of 149.112.112.10
Note: Use only one of these sets of addresses – secure or unsecure. Mixing secure and unsecure IP addresses in your configuration may lead to your system being exposed without the security enhancements, or your privacy data may not be fully protected
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=58 time=3.57 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=3.30 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=3.31 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=3.21 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=3.21 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=57 time=3.15 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=3.17 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=2.34 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=2.93 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=3.19 ms
MyRepublic:
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=60 time=1.88 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=1.93 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=1.96 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=1.85 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=60 time=1.85 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=59 time=1.86 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=1.66 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=1.40 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=1.38 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=1.60 ms
Looks like Google DNS's still a little bit faster.
How are you getting those single digit times? I can never get below 15 ms for both Google and CloudFlare. Any tips to improve this or its beyond my control?
My ISP peers with cloudflare in Sydney (~40ms), even though there is a CF datacenter in Auckland, New Zealand (~10ms)
I'm in Wellington.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=56 time=37.9 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=36.9 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=56 time=36.7 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=56 time=35.9 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=35.4 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=35.2 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=35.2 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=35.7 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=55 time=19.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=55 time=19.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=55 time=19.8 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=55 time=19.7 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=55 time=19.8 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=55 time=19.7 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=55 time=19.8 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=55 time=19.7 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=55 time=19.8 ms
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=57 time=0.390 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=0.565 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=0.472 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=0.556 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=57 time=0.560 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=57 time=0.573 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=57 time=0.359 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=57 time=0.575 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=57 time=0.543 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=57 time=0.548 ms
From Zagreb, Croatia.
I guess that new cloudflare POP is paying off.
Using ping to compare the two may introduce a skew based on how the two networks prioritize ICMP.
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
However, if i do DNS lookups against a few major domains, google is actually slower by ~2ms
$ 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
You'd have to run a bunch of queries to see if there is an actual impact vs. just an outlier (e.g. the first ping response from cloudflare), just wanted to point it out.
$ ping -c 10 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=60 time=1789.957 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=19.620 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=9.372 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=11.585 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=20.660 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=60 time=11.808 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=60 time=12.784 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=60 time=11.908 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=60 time=11.373 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=60 time=11.992 ms
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.372/191.106/1789.957/532.962 ms
$ ping -c 10 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=60 time=1308.156 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=17.557 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=13.043 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=16.217 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=60 time=15.033 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=60 time=15.132 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=60 time=14.157 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=60 time=16.100 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=60 time=15.600 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=60 time=13.837 ms
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.043/144.483/1308.156/387.893 ms
$ 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=13.8 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=14.6 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=13.7 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=14.1 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=13.7 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=15.3 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=46 time=43.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=42.3 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=43.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=46 time=42.0 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=46 time=42.4 ms
Microsoft Windows [Version 10.0.16299.309]
(c) 2017 Microsoft Corporation. All rights reserved.
C:\Users\ram>tracert 1.1.1.1
Tracing route to 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
over a maximum of 30 hops:
1 6 ms 11 ms 5 ms 192.168.1.1
2 5 ms 5 ms 23 ms 10.4.224.1
3 * * * Request timed out.
4 15 ms 7 ms 10 ms 103.56.229.1
5 * * * Request timed out.
6 45 ms 56 ms 44 ms 115.255.252.225
7 86 ms 84 ms 87 ms 62.216.144.77
8 169 ms 173 ms 175 ms xe-2-0-4.0.cjr01.sin001.flagtel.com [62.216.129.161]
9 174 ms 174 ms 169 ms ge-2-0-0.0.pjr01.hkg005.flagtel.com [85.95.25.41]
10 173 ms 174 ms 170 ms xe-3-2-2.0.ejr04.seo002.flagtel.com [62.216.130.25]
11 171 ms 173 ms 170 ms 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1]
Trace complete.
C:\Users\ram>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:
1 88 ms 305 ms 98 ms 192.168.1.1
2 13 ms 98 ms 102 ms 10.4.224.1
3 * * * Request timed out.
4 * 16 ms * 10.200.200.1
5 9 ms 3 ms 8 ms 209.85.172.217
6 11 ms 5 ms 9 ms 108.170.251.103
7 40 ms 33 ms 37 ms 209.85.246.164
8 * 90 ms 89 ms 209.85.241.87
9 89 ms 86 ms 89 ms 216.239.51.57
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 87 ms 82 ms 87 ms google-public-dns-a.google.com [8.8.8.8]
Trace complete.
C:\Users\ram>tracert resolver2.opendns.com
Tracing route to resolver2.opendns.com [208.67.220.220]
over a maximum of 30 hops:
1 3 ms 7 ms 8 ms 192.168.1.1
2 12 ms 11 ms 41 ms 10.4.224.1
3 * * * Request timed out.
4 21 ms 21 ms 51 ms 103.56.229.1
5 * 62 ms 12 ms 115.248.235.150
6 * 408 ms 65 ms 115.255.252.229
7 43 ms 49 ms 40 ms 14.142.22.201.static-Mumbai.vsnl.net.in [14.142.22.201]
8 * 41 ms 57 ms 172.23.78.237
9 46 ms 32 ms 29 ms 172.19.138.86
10 73 ms 46 ms 42 ms 115.110.234.50.static.Mumbai.vsnl.net.in [115.110.234.50]
11 41 ms 64 ms 44 ms resolver2.opendns.com [208.67.220.220]
~ ping -c 10 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=64 time=1.15 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.15 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=1.06 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=1.04 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=1.03 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=1.01 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=64 time=1.02 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=64 time=1.07 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=64 time=1.00 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=64 time=0.848 ms
--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9009ms
rtt min/avg/max/mdev = 0.848/1.042/1.153/0.086 ms
~ ping -c 10 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=6.82 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=6.72 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=6.39 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=6.73 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=6.55 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=56 time=6.14 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=56 time=6.24 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=56 time=6.22 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=56 time=6.19 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=56 time=6.30 ms
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9011ms
rtt min/avg/max/mdev = 6.149/6.433/6.826/0.248 ms
These are only averages though, and by testing a bit more with uncached domains I found the first hit will take a lot longer with cloudflare than with google.
Apparently, you need to provide it as a Subject Alternative Name (SAN).
This is the entry for the cert used:
DNS Name=*.cloudflare-dns.com
IP Address=1.1.1.1
IP Address=1.0.0.1
DNS Name=cloudflare-dns.com
IP Address=2606:4700:4700:0000:0000:0000:0000:1111
IP Address=2606:4700:4700:0000:0000:0000:0000:1001
SAN is the only correct way to write any kind of name for servers on the Internet in a certificate. The "Common Name" was left as a compatibility feature like 20 years ago when SANs were invented and then it rusted into place, but is no longer examined by current Firefox or Chrome browsers for "real" certificates from the public Internet. Chrome shipped releases for a while with a bug where they'd complain the server's cert had the wrong "Common Name" when actually they never checked CN at all, and so it might even have the right Common Name, but they really meant "Your SANs don't match fool" and hadn't updated the error text.
Because crappy software (looking at you here OpenSSL) makes writing SANs into a Certificate Subject Request way harder than it needs to be, a lot of CAs (including Let's Encrypt) will take a CSR that says "My Common Name is foo.example" and sigh, and issue a cert which adds SAN dnsName foo.example, because they know that's what you want. Really somebody should fix the software, one of these days.
In older Windows versions, SChannel (Microsoft's implementation of SSL/TLS) doesn't understand ipAddress, and thinks the correct way to match an ipAddress against a certificate is to turn the address into ASCII text of dotted decimals and compare that to the dnsName entries. This, unsurprisingly, is not standards compliant.
It's good to see a CA not trying to fudge this, but the consequence is probably that if you have older Windows (XP? Maybe even something newer) these certs don't check out as valid for the site. Eh. Upgrade already.
>"4.2.1.6. Subject Alternative Name
The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier(URI). Other options exist, including completely local definitions."[1]
I'm guessing less "sophisticated reinvention" and usage of existing TLS connection technology. You can use both (even at the same time) with DNScrypt-proxy V2 https://github.com/jedisct1/dnscrypt-proxy ;)
;; ANSWER SECTION:
dailystormer.name. 86400 IN A 198.251.90.113
;; AUTHORITY SECTION:
dailystormer.name. 86400 IN NS f1g1ns1.dnspod.net.
dailystormer.name. 86400 IN NS f1g1ns2.dnspod.net.
;; ADDITIONAL SECTION:
f1g1ns1.dnspod.net. 70157 IN A 58.247.212.36
f1g1ns1.dnspod.net. 70157 IN A 61.151.180.44
f1g1ns1.dnspod.net. 70157 IN A 180.163.19.15
f1g1ns1.dnspod.net. 70157 IN A 182.140.167.166
f1g1ns1.dnspod.net. 70157 IN A 14.215.150.17
f1g1ns2.dnspod.net. 70157 IN A 61.129.8.159
f1g1ns2.dnspod.net. 70157 IN A 101.226.220.16
f1g1ns2.dnspod.net. 70157 IN A 121.51.128.164
f1g1ns2.dnspod.net. 70157 IN A 182.140.167.188
f1g1ns2.dnspod.net. 70157 IN A 52.220.136.67
Nope, certificates can be, and sometimes are, issued for plain IP addresses, yes including in the Web PKI ("proper" certificates that work in common web browsers).
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 am getting ERR_CERT_AUTHORITY_INVALID because my ISP-provided router is intercepting the connection and trying to show me a "helpful" configuration wizard. No Cloudflare DNS for me.
To be explicit: This is not Cloudflare's fault and we should blame the manufacturer of the router, or the ISP for deploying their custom "friendly" settings. But it is what it is.
Yup, these ranges are poisonous, which is why APNIC kept them, so this is effectively to be expected. It would actually be extraordinary if, since the range was determined to be poisonous and so mustn't be delegated this had magically fixed itself. So I was sort-of expecting to see some comments in the last thread about 1.1.1.1 like yours.
The "good" news is that this isn't being used for anything you really need - imagine if 1.1.1.1 had been delegated and now it was the resolution for www.facebook.com or indeed news.ycombinator.com ...
The bad news is that idiots do not learn from their mistakes, that's Dunning Kruger, the people who built your device don't understand why this was the Wrong Thing™ and won't now seek to do better in future. If we're lucky they'll go out of business, but that's the best we can hope for.
APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.
We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born
1.1.1.1 is a partnership between Cloudflare and APNIC.
Cloudflare runs one of the world’s largest, fastest networks. APNIC is a non-profit organization managing IP address allocation for the Asia Pacific and Oceania regions.
Cloudflare had the network. APNIC had the IP address (1.1.1.1). Both of us were motivated by a mission to help build a better Internet. You can read more about each organization’s motivations on our respective posts: Cloudflare Blog / APNIC Blog.
When I've seen DNS-over-HTTPS in the past I've always thought it odd that it's setup with a DNS name for the HTTPS address, requiring a plain DNS lookup before it starts using HTTPS. I assumed this was done because they didn't have a valid TLS cert for the IP address. But 1.1.1.1 actually has a valid TLS cert, yet their setup instructions say to use the DNS name cloudflare-dns.com instead of the IP.
I suppose I see your point, but since DNS-over-HTTPS only supports HTTPS (not HTTP) and therefore requires a valid certificate for the requested resolver, there's no risk of the protocol being downgraded to HTTP or easily spoofed.
That is a good point, though I wasn't thinking about it from a security perspective. I was more imagining an ISP or nation that is trying to control content by blocking/faking DNS queries. They could block the first DNS query if DNS-over-HTTPS doesn't use an IP for the resolver.
Of course an ISP or nation could block/reroute the IP 1.1.1.1 too, so maybe it doesn't matter. Neither way would allow MITM, I was just thinking about ways oppressive ISPs/nations could stop DNS-over-HTTPS from working.
This is bad, bad, bad advice. You don't set the DNS on your local machine. That breaks things. The DNS needs to be set at the gateway. If you change your PC/mac's DNS to an external service, you won't be able to resolve any addresses on the local network.
Come on, CloudFlare. You guys know better than that. Please stop breaking the (local) internet.
Ordinary users don't have anything that resolves to local IPs, so this is a non-issue for just about anybody. Plus, many if not most ISP-provided modem-router-AP-boxes don't let you configure the DNS server they use, making your recommendation impossible to follow for most users. Someone who runs services on their local network likely knows enough to do as you say, but for 99% of people, these instructions are exactly what they need.
Yes! People are smart enough to handle most things. But they don't have time or attention to handle all the things. When we're making technology for users, we should do our best to make sure they only have to learn about the things that are important to them.
This is bad. To run your own local DNS server is a part of good parenting. So, to break local services is very bad for us responsible parents, to say the least. I block all outbound DNS lookup except to my ISP. Sometime I redirect lookups to other resolvers (eg. 8.8.8.8) to my local DNS server. I don’t care if some app breaks because of this. Often it’s because of bad programming. So, don’t break local DNS!
This is useful for use cases for which that doesn't matter. Using your computer or devices at home, on your own wifi, where there is no need to resolve local addresses. Or on public wifi, such as in a café, where there is no need to resolve local addresses, and you don't control the gateway.
You're not typical of the average consumer, though. Don't forget that HN is a particularly technical crowd, so you can't use it to judge how technically competent Internet users are.
Perhaps you missed the sections near the top titled "DNS's Privacy Problem" and "DNS's Censorship Problem" which explain why not everybody can trust their network operator?
694 comments
[ 3.0 ms ] story [ 337 ms ] thread"Privacy First: Guaranteed. We will never sell your data or use it to target ads. Period. 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.
Frankly, we don’t want to know what you do on the Internet—it’s none of our business—and we’ve taken the technical steps to ensure we can’t."
In the DNS resolver space, what is their business?
What is intriguing to me is why Cloudflare are offering this. Perhaps it is to provide data on traffic that is 'invisible' to them, as in it doesn't currently touch their networks. Possibly as a sales-lead generator.
Or is the plan to become dominant and then use DNS blackholing to shutdown malware that is a threat to their systems?
* no logging
* DNS over HTTPS
BTW if you want to use DNS over HTTPS on Linux/Mac I strongly recommend dnscrypt proxy V2 (golang rewrite) https://github.com/jedisct1/dnscrypt-proxy and put e.g. cloudflare in their config toml file to make use of it.
I pay them to access the internet, every further information they gather about my internet activity does not mean any benefit for me.
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 can't achieve that, and here are some ugly, slow things that could work, now what?"
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).
You are correct that you can do this if you spend one round trip first to set up the channel, and both the proposals for how we might encrypt SNI in that Draft do pay a round trip. Which is why I said they're slow and ugly. And as you noticed, SSH2 and rdesktop do not, in fact, spend an extra round trip to buy this capability they just go without.
Aside it's strange https everywhere has been pushed aggressively by many here under the bogeyman of ISP adware and spying while completely ignoring the much larger adware and privacy threats posed by the stalking of Google, Facebook and others. It is disingenuous and insincere.
Only a handful of small specialist firms actually just move bits in the UK. Every single UK ISP big enough to advertise on television is signed up to filter traffic and block things for being "illegal" or maybe if Hollywood doesn't like them, or if they have "naughty" words mentioned, or just because somebody slipped. If you're thinking "Not mine" and it runs TV adverts then, oops, nope, you're wrong about that and have had your Internet censored without realising it. I wonder how ISPs got their bad reputation...
In the same breath, they insinuate that Google both sells and uses DNS usage from their 8.8.8.8 and 8.8.4.4 resolvers.
Cloudflare is somewhat right: Means, Motive and Opportunity - but for a conviction you have to prove someone acted on the Opportunity. The Motive of Google is tampered with severe risk for loosing trust.
Cloudflare can make an argument they are fundamentally better positioned and that is all they do. As with all US based operations the NSA may cook up some convincing counterarguments and we may never know.
https://en.wikipedia.org/wiki/Eggcorn
The OP did not say that cloudflare is "saying" that. The OP very clearly said they are "insinuating" it. And yes under the heading "DNS's Privacy Problem" the post mentions:
"With all the concern over the data that companies like Facebook and Google are collecting on you,..."
I think that juxtaposition of this statement under a bolded heading of "DNS's Privacy Problem" is very much insinuating that.
I don't think it's intended to say anything about Google specifically. Keep in mind that there are many other DNS services out there, and some of them are known for being pretty scummy, e.g. replacing NXDOMAIN results with "smart search" / ad pages.
Google is mentioned 13 times in this post and their resolvers 3. That's 16 total mentions of Google in their post.
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) they're about the best we have.
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 you don't redistribute the report or its contents.
Disclosure: I deal with security audits and technical aspects of compliance.
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.
If you've ever been audited for some other reason, you'll know they find lots of things, and then you fix them, and that's "fine". But well, is it fine? Or, should we acknowledge that they found lots of things and what those things were, even if you subsequently fixed them? The CA/B says you have several months to hand over your letter after the audit period. Guess what those months are spent doing...
Indeed, see the recent KPMG scandal:
https://www.marketwatch.com/story/kpmg-indictment-suggests-m...
http://www.cbc.ca/news/business/canada-revenue-kpmg-secret-a...
"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 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."
> "We committed to never writing the querying IP addresses to disk ..."
A DNS resolver does need to record the querying IP for at least a few moments because, you know, they have to respond to your query.
However, I don't know why they changed that sentence; it could be for other reasons too.
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.
[1] https://blog.cloudflare.com/announcing-1111/ [2] https://1.1.1.1
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.
"to audit our code and practices annually and publish a public report confirming we're doing what we said we would."
I run an investment fund (hedge fund) and we are completing our required annual audit (not by KPMG). It is quite thorough, they manually check balances in our bank accounts directly with the bank, they verify balances directly off blockchain (it's a crypto fund) and have us prove ownership of keys by signing messages, etc. And they do do a due diligence (lots of doodoo there) that we are not doing scammy things like the equivalent of having a raspberry pi attached to the network. Now this is extremely tough of course, and they are limited in what they can accomplish there, but the thought does cross their mind. All firms are different, but from what we've seen most auditors do decent good jobs most of the time. Their reputation can only be hit so many times before their name is no longer valuable to be an auditor.
* Actually only ~1% of internet users, the kind of people that install openwrt
The Baseline Requirements agreed between Web Browser vendors and root Certificate Authorities dictate how the CA can figure out if an applicant is allowed a certificate for a particular name, for dnsNames this is the Ten Blessed Methods, for ipAddress the rules are a bit... eh, rusty, but the idea is you can't get one for that dynamic IP you have from your cable provider for 24 hours, but somebody who really controls the IP address can get one. They're uncommon, but not rare, maybe a dozen a day are issued?
Your web browser requires that the name in the URL exactly matches the name in the certificate. So if you visit https://some-dns-server.example/ the certificate needs to be for some-dns-server.example (or *.example) and a certificate for 1.1.1.1 doesn't work, even if some-dns-server.example has IP address 1.1.1.1 - so this cert is only useful because they want people actually typing https://1.1.1.1/ into browsers...
[edited, I have "Servers" on the brain, it's _Subject_ Alternative Name, you can use them to name email recipients, and lots of things that aren't servers]
Yes, but...
This only works if they don't use SNI[1]. If they use SNI then you just get the default cert. They might have more certs for other hostnames served on that IP address.
1: https://en.wikipedia.org/wiki/Server_Name_Indication
[1] https://www.quad9.net/
[2] https://news.ycombinator.com/item?id=16716606
So the difference is how long the logs are kept, and possibly what the log data is used for.
https://twitter.com/webernetz/status/980055981282484225
To compare the two, together with Google's DNS as a reference, from a fast connection:
...and from a slower (home) connection: Note that I just used the speed of every fifth package instead of the average for five packets in order to keep the comment relatively short and more humanly readable than "rtt min/avg/max/mdev".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 meant that DNS requests are parallelized within the browser. Once it loads the initial resource (html), there might be 10 more dependencies it needs at various different URLs under different domain names. It's usually loading all these dependencies that make up the vast majority of the load time on a complex web page.
Those subsequent DNS requests can of course be made in parallel, so if your DNS latency is 20ms then you're adding ~20ms, not 10 x 20ms.
Even then, DNS is probably making up a small fraction of the overall load time. If a complex page is taking, say, 3000ms to load and render, then adding 20-40ms of DNS time is not going to make a perceptible difference.
They match your requests with IBM's X-Force threat intelligence database and give you filtered results.
https://www.theregister.co.uk/2017/11/20/quad9_secure_privat...
Is there a service that Quad9 offers that does not have the blocklist or other security?
The primary IP address for Quad9 is 9.9.9.9, which includes the blocklist, DNSSEC validation, and other security features. However, there are alternate IP addresses that the service operates which do not have these security features. These might be useful for testing validation, or to determine if there are false positives in the Quad9 system.
Secure IP: 9.9.9.9 Provides: Security blocklist, DNSSEC, No EDNS Client-Subnet sent. If your DNS software requires a Secondary IP address, please use the secure secondary address of 149.112.112.112
Unsecure IP: 9.9.9.10 Provides: No security blocklist, DNSSEC, sends EDNS Client-Subnet. If your DNS software requires a Secondary IP address, please use the unsecure secondary address of 149.112.112.10
Note: Use only one of these sets of addresses – secure or unsecure. Mixing secure and unsecure IP addresses in your configuration may lead to your system being exposed without the security enhancements, or your privacy data may not be fully protected
--------------------------
IPV6: https://quad9.net/faq/#Is_there_IPv6_support_for_Quad9
Is there IPv6 support for Quad9?
Yes. Quad9 operates identical services on a set of IPv6 addresses, which are on the same infrastructure as the 9.9.9.9 systems.
Secure IPv6: 2620:fe::fe Blocklist, DNSSEC, No EDNS Client-Subnet
Unsecure IPv6: 2620:fe::10 No blocklist, DNSSEC, send EDNS Client-Subnet
Queries are jumping anywhere from 10ms to 138ms compared to a flat 6ms on Google and OpenDNS in Australia. Maybe unexpected traffic?
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: icmp_seq=6 ttl=47 time=335.099 ms
(From Singapore)
Google's 8.8.8.8 has about <4ms
64 bytes from 1.1.1.1: icmp_seq=0 ttl=60 time=2.099 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=2.073 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=1.963 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=2.089 ms
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=60 time=1.908 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=1.888 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=1.993 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=1.891 ms
From SG too. Could it be... just you?
Might send CloudFlare a quick email as they'll probably want singtel to correct this.
From MyRepublic 8.8.8.8 is 2 hops shorter and about a millisecond faster.
Disclaimer: I probably don't know what I'm doing :D
Things are a bit quicker in the US:
64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=0.421 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=0.645 ms
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time<1ms TTL=57
Reply from 8.8.8.8: bytes=32 time=1ms TTL=57
Reply from 8.8.8.8: bytes=32 time<1ms TTL=57
Reply from 8.8.8.8: bytes=32 time<1ms TTL=57
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=6ms TTL=57
Reply from 1.1.1.1: bytes=32 time=6ms TTL=57
Reply from 1.1.1.1: bytes=32 time=6ms TTL=57
Reply from 1.1.1.1: bytes=32 time=6ms TTL=57
(Switzerland)
I'm in Wellington.
You guys are 100ms from anywhere cool.
I'm halfway up to newcastle getting ~10ms across the board, 1.1.1.1, 8.8.8.8, and 192.231.203.132.
Of course performance on each is a different matter.
1.1.1.1 is giving the best response times @ 8-11ms.
Internode's is giving decent @ 10-14ms
8.8.8.8 is a bit wonky, sometimes I hit a 10ms route once they cache it, but propagation is very slow and most responses are 140-180ms.
Edit: formatting
For example, from my network google is averaging a faster response by ~.5ms
However, if i do DNS lookups against a few major domains, google is actually slower by ~2ms You'd have to run a bunch of queries to see if there is an actual impact vs. just an outlier (e.g. the first ping response from cloudflare), just wanted to point it out.PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=56 time=19.145 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=18.927 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=19.258 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=20.000 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=20.428 ms
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=53 time=21.351 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=53 time=18.606 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=53 time=19.451 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=53 time=19.084 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=53 time=18.989 ms
1.1.1.1 round-trip min/avg/max/stddev = 10.984/12.221/14.909/1.239 ms
8.8.8.8 round-trip min/avg/max/stddev = 11.022/12.702/15.102/1.317 ms
Microsoft Windows [Version 10.0.16299.309] (c) 2017 Microsoft Corporation. All rights reserved.
C:\Users\ram>tracert 1.1.1.1
Tracing route to 1dot1dot1dot1.cloudflare-dns.com [1.1.1.1] over a maximum of 30 hops:
Trace complete.C:\Users\ram>tracert 8.8.8.8
Tracing route to google-public-dns-a.google.com [8.8.8.8] over a maximum of 30 hops:
Trace complete.C:\Users\ram>tracert resolver2.opendns.com
Tracing route to resolver2.opendns.com [208.67.220.220] over a maximum of 30 hops:
Trace complete.C:\Users\ram>
$ ping -c 5 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=60 time=1.606 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=60 time=1.562 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=60 time=1.540 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=60 time=1.574 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=60 time=1.564 ms
--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.540/1.569/1.606/0.022 ms
$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=57 time=9.068 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=8.923 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=8.974 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=8.916 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=8.931 ms
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 8.916/8.962/9.068/0.057 ms
https://stackoverflow.com/questions/1095780/are-ssl-certific...
This is the entry for the cert used:
Because crappy software (looking at you here OpenSSL) makes writing SANs into a Certificate Subject Request way harder than it needs to be, a lot of CAs (including Let's Encrypt) will take a CSR that says "My Common Name is foo.example" and sigh, and issue a cert which adds SAN dnsName foo.example, because they know that's what you want. Really somebody should fix the software, one of these days.
In older Windows versions, SChannel (Microsoft's implementation of SSL/TLS) doesn't understand ipAddress, and thinks the correct way to match an ipAddress against a certificate is to turn the address into ASCII text of dotted decimals and compare that to the dnsName entries. This, unsurprisingly, is not standards compliant.
It's good to see a CA not trying to fudge this, but the consequence is probably that if you have older Windows (XP? Maybe even something newer) these certs don't check out as valid for the site. Eh. Upgrade already.
>"4.2.1.6. Subject Alternative Name The subject alternative name extension allows identities to be bound to the subject of the certificate. These identities may be included in addition to or in place of the identity in the subject field of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier(URI). Other options exist, including completely local definitions."[1]
[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6
; <<>> DiG 9.8.3-P1 <<>> dailystormer.name @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: - ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 10
;; QUESTION SECTION: ;dailystormer.name. IN A
;; ANSWER SECTION: dailystormer.name. 86400 IN A 198.251.90.113
;; AUTHORITY SECTION: dailystormer.name. 86400 IN NS f1g1ns1.dnspod.net. dailystormer.name. 86400 IN NS f1g1ns2.dnspod.net.
;; ADDITIONAL SECTION: f1g1ns1.dnspod.net. 70157 IN A 58.247.212.36 f1g1ns1.dnspod.net. 70157 IN A 61.151.180.44 f1g1ns1.dnspod.net. 70157 IN A 180.163.19.15 f1g1ns1.dnspod.net. 70157 IN A 182.140.167.166 f1g1ns1.dnspod.net. 70157 IN A 14.215.150.17 f1g1ns2.dnspod.net. 70157 IN A 61.129.8.159 f1g1ns2.dnspod.net. 70157 IN A 101.226.220.16 f1g1ns2.dnspod.net. 70157 IN A 121.51.128.164 f1g1ns2.dnspod.net. 70157 IN A 182.140.167.188 f1g1ns2.dnspod.net. 70157 IN A 52.220.136.67
;; Query time: 550 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Sun Apr 1 -:-:- 2018 ;; MSG SIZE rcvd: 265
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:
https://crt.sh/?id=346170629
Thankfully I noticed quickly, so I knew what the problem would be.
To be explicit: This is not Cloudflare's fault and we should blame the manufacturer of the router, or the ISP for deploying their custom "friendly" settings. But it is what it is.
Edit: 1.0.0.1 also takes me to the router configuration screen. And there's no configuration setting for it. :(
The "good" news is that this isn't being used for anything you really need - imagine if 1.1.1.1 had been delegated and now it was the resolution for www.facebook.com or indeed news.ycombinator.com ...
The bad news is that idiots do not learn from their mistakes, that's Dunning Kruger, the people who built your device don't understand why this was the Wrong Thing™ and won't now seek to do better in future. If we're lucky they'll go out of business, but that's the best we can hope for.
We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born
https://blog.cloudflare.com/announcing-1111/
Who’s behind this?
1.1.1.1 is a partnership between Cloudflare and APNIC.
Cloudflare runs one of the world’s largest, fastest networks. APNIC is a non-profit organization managing IP address allocation for the Asia Pacific and Oceania regions.
Cloudflare had the network. APNIC had the IP address (1.1.1.1). Both of us were motivated by a mission to help build a better Internet. You can read more about each organization’s motivations on our respective posts: Cloudflare Blog / APNIC Blog.
https://developers.cloudflare.com/1.1.1.1/dns-over-https/
Is there a technical reason the DNS-over-HTTPS resolvers need their upstream resolvers to be looked up by name and not IP?
So what do you see as the threat profile?
Of course an ISP or nation could block/reroute the IP 1.1.1.1 too, so maybe it doesn't matter. Neither way would allow MITM, I was just thinking about ways oppressive ISPs/nations could stop DNS-over-HTTPS from working.
Come on, CloudFlare. You guys know better than that. Please stop breaking the (local) internet.
Don’t presume that joe public is a simpleton. Millions of people are not.
I’m not insinuating that “joe public” is dumb. He just doesn’t need to care about DNS on his local network, there’s software that handles it for him.
Besides, "In your router’s configuration page, locate the DNS server settings."
What does this mean? I have 8.8.8.8/8.8.4.4 set and they work fine for resolving things on my local network?
I can even connect to things with avahi like `xxyyzz.local`.
*.internal queries can be sent to the local nameserver, for example, while others can be forwarded to the public nameserver.
Minimal unbound.conf example:
Unbound also supports DNS-over-TLS, although stubby's implementation is much better. It's usually ideal to forward to a local stubby instance instead.