I think we'll start seeing the standard configuration of 1.1.1.1,8.8.8.8 everywhere.
Google/Cloudflare tackled the UX of free DNS spectacularly with these gold IP addresses. It's the primary reason I use them instead of OpenDNS, which was an earlier player in this space.
Read the announcement: https://blog.cloudflare.com/announcing-1111/
"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."
No cash outlay. Read the blog, but tl;dr is that it's quid pro quo as the owners can't afford to stand it up due to the volume of junk traffic (but want to, to study the junk) -- cloudflare can and will let the owner study the junk.
What cloudflare don't say in any of their materials that I've seen is the agreement is for an initial 5 years, so YMMV after that.
Be careful with that, Google DNS (as an example) will start ignoring your DNS requests if you go over the rate-limit. Not an issue for home users, but an issue for any sizeable business.
Hmm, it seems like they may have fixed it, I can't seem to reproduce the problem I had (it would randomly fail to resolve CAA records for DNSSEC enabled domains).
Doesn't this just mean that you should be running your own caching resolver so that requests for common things don't constantly hit the upstream server? For those same common sites it should also be better performance anyway.
Probably the same way they use Lets Encrypt instead of purchasing certificates. Lots of free things actually are free, despite the negative training otherwise we get from some companies.
OpenDNS still has a lot of value beyond just free DNS service though. When I was very active in dealing with phishing, we found that OpenDNS flagged phishing sites about 4 times faster than any other DNS provider, which I assume is because of PhishTank. It's the primary reason I recommend it to my parents.
Between that and some of the content filtering options you can get with the paid plan, I find that it's a very full-featured option for homes with young kids. I'm pretty sure you get to control the logs on the paid plan too. Need to double check.
Interesting question: would I rather protect my elderly Mum from known malicious domains potentially trying to scam/phish, or from potential tracking and ad targeting?
(Actually, it's not really a difficult choice at all, is it?)
Quad9 is a consortium of 3 founding companies, none of which is the London Police Department. Additionally nowhere in your link is either Quad9, IBM, PCH or GCA mentioned. Please stop spreading and disinformation and FUD. See:
Whether its the City of London's Police Department or the Greater London Police is splitting hairs. Your comment suggests that the Quad9 was funded by a municipal police force. And that's patently untrue.
If you dug a little deeper on one of your own links you would find that the NYC DA and City of London Police Department donated money to establish a 501(c)3 non-profit to combat cyber crime. That 5013C is but one member of a consortium of 3 companies behind Quad9.
"Knowing the potential that an organisation like GCA could have, the DA committed $25 million in criminal asset forfeiture proceeds to fund this critical work over a five-year period. The Center for Internet Security and City of London Police also made significant contributions in providing space, funding, staff, and assistance with building strategic partnerships."[1]
Well, the article says so, but they actually measured icmp response. All major domains are in DNS cache anyway. If you look at Yandex result you see it performed very poorly. Why does it resolve popular domains so slow? The reason is it has one server and it is located in Moscow.
So i would say icmp is good proxy to actual performance.
It would be a measure of ping + cache latency. That's still different than just ping.
And is your point that the tested sites aren't popular in Russia?
>for different popular domains (google, facebook, twitter, gmail, etc)
google.com facebook.com and twitter.com are all in the top 50 sites in Russia[1]. And gmail.com is number 6000 globally[2], so it's unpopular everywhere, not just Russia. Popular sites in Russia tend to be popular elsewhere, and vice versa.
It would be more interesting to see how are they doing for some websites in the long tail, try the 900th, 9000th, and 90000th most popular sites instead of the top. And try some locations which are not actual datacenters?
And I wanted to add a similar comment, why on earth would any privacy-oriented person would use Google's 8.8.8.8 when there are other options out there?
Oh, and I definitely don't buy this for Google: "The Privacy option above is based on the providers promise to do not log or share your DNS requests."
- One for up to 48 hours which contains IP addresses, which is used for handling abuse.
- One is permanent which doesn't contain any personal identifying information (eg IP addresses), which is used for things like internal performance monitoring, load testing, and tracking frequency of longer term abuse etc.
Google provides Google public DNS because if you see the internet as being slow because of poor DNS performance, then you don't use websearch as much. Google doesn't need to use Google Public DNS to track users, and would rather not have the information (as it makes it available for government requests etc which are a major pain to deal with). But running a large scale recursive DNS server tends to attract a _lot_ of abuse, both intentional, and unintentional as I'm sure 9.9.9.9 and 1.1.1.1 are discovering.
Google provides Google Public DNS because a lot of ISPs provide extremely poor default recursive nameservers (having tiny caches, dropping queries due to overload, not implementing IPv6, DNSSEC validation, EDNS0 payload size, or other important modern DNS features. Some ISPs also hijack domains for their own purposes, or "stretching" DNS TTLs etc) so providing a better alternative to improve overall Internet use is clearly in Google's best interest.
Having other public resolvers, with different trade offs is clearly better for everyone, including Google as long as they are reliable, trustworthy, and provide low latency responses.
Good luck to everyone who's joining in the fun of running a planet scale recursive DNS server.
(Disclaimer: I have previously worked on Google Public DNS, but no longer do)
Do you know if Chrome uses Google Public DNS by default? I've heard it does for performance and avoiding problems with ISPs' crappy DNS. I imagine it would still need to fall back to local DNS to resolve names on enterprise intranets.
My uninformed assumption is that chrome generally uses whatever is configured in the system resolver, otherwise things like captive portals, and split horizon DNS wouldn't work properly, but I don't specifically know.
You've got any proof, indication or even slight hint for this? Aggregate data is indeed used for all kinds of analytics, but individual IP addresses aren't tracked nor kept for more than 48 hours - to combat abuse.
There is 2 main different ways, one which does what you say - the other i'd say is pretty much OK.
If your local DNS server is merely querying an upstream resolver (like 1.1.1.1 / 8.8.8.8) on your behalf, then yes - it is no different.
If however, you query the root nameservers for the glue record for a domain and query the domain's own nameservers directly, then it is pretty good... As you are neither querying your ISP or TheMan.. which means that logically only the domain nameserver owner knows what queries you made (and you are probably hitting that domain in a moment anyway!). (The caveat is that some ISP's do transparent DNS proxying.. in which case, you have much larger trust issues with your ISP and need to take greater measures!)
> (The caveat is that some ISP's do transparent DNS proxying.. in which case, you have much larger trust issues with your ISP and need to take greater measures!)
I once had an ISP which did transparent http proxying. You could theoretically query an external DNS server and get back the correct result, but it would intercept your http connection, discard the ip address you were trying to connect to then do a new DNS lookup to the ISP's DNS server on the HOST header.
Took me ages to work out what was going on with the various issues it was causing.
I dumped that ISP like a rock after they refused to disable that caching proxy, which they claimed was only there to improve customer experience.
Virgin Media in the UK appear to do this for sites they are ordered to block. Even if you get the right DNS response, you get forwarded to http://assets.virginmedia.com/site-blocked.html (HTTPS requests get a connection reset).
> only the domain nameserver owner knows what queries you made (and you are probably hitting that domain in a moment anyway!)
But these are different people, with different incentives. The NS owner may be logging everything, without the domain owner's knowledge, and the NS owner won't even be in the wrong, because they likely made no promise to not log.
With a single resolver, I can verify that they're trustworthy enough [for me], just once, and direct all my traffic to it. Cloudflare's "We committed to never writing the querying IP addresses to disk and wiping all logs within 24 hours" is something, I imagine, they very much wouldn't want to be caught violating or changing their mind about later.
In the meanwhile, with the root NS method, I can only hope that my queries will get lost in the "noise". And I'm putting noise in quotation marks because there isn't much diversity in the name server ownership: 75% of Alexa top 1M domains are hosted at Cloudflare, GoDaddy and Amazon. [0]
With QNAME minimalisation, RFC7129 (Authenticated denial of existence) and RFC8020 (NXDOMAIN: There really is nothing underneath), you should be sending almost nothing to the root servers of use.
QNAME minimalisation will only send <randomstring>.com to the root for them to give you the referral.
and RFC7129/RFC8020 mean that when you get a NXDOMAIN back from the root, you'll cache it and never try again for a large swath of possible names.
QNAME minimization just minimizes the name to one label under a delegation, there's no randomization. So root zone would only get 'com.' (and type NS). It's unfortunately easy for authoritative servers (below TLD level) to bypass it by returning NXDOMAIN. Resolver has to fall back on using a full name. The main reason is that a lot of authoritative DNS servers (notably Akamai) return NXDOMAIN when there's nothing under the minimized name, but there is something below it (aka empty non-terminal). So without workarounds the resolver would return NXDOMAIN early instead of retrying with the full name.
Okay, say, 1 year from now, somehow, 95% of internet users are sending their DNS queries to Cloudflare. What can go wrong? Malicious or not. Not rhetorical, actually curious.
They don't need to be doing DNS proxying, they can just inspect port 53 traffic -- unless the site you're visiting supports DNS over TLS, then you're not hiding anything from your ISP, since they'll see the DNS query packet hitting the www.porn-site.com nameserver.
However, if have a local TLS nameserver, you can set it up to query 1.1.1.1 over TLS, then your ISP can't see any of your DNS queries.
So you need to decide who you trust more -- your ISP or a DNS provider (or a VPN provider).
Other than some small edge cases, this is pretty much the most secure and fastest DNS performance you will have, in most instances getting about 1 or <1ms speed. Depending on DNS server you can even have both root servers and resolver configured.
I have been using unbound for at least 4 years. Simple and fast.
BIND is the industry standard - but insanely overkill for your use case. Unbound is very easy and lightweight. Dnsmasq is another option, but I don't think you can setup root server with it.
It is also very easy to do this with dnsmasq or powerdns, djbdns, etc.
I'm increasingly beginning to think that every node should be it's own dns so it's cache blacklist can be verified (checksums?) per node instead of per request to the dns provider.
Besides response time, the next level of comparison is how well geo-DNS-based services (global load balancing, etc.) support these resolvers. AFAIK 8.8.8.8 gives decent results in most places, though I've seen suboptimal US-centric results from Quad9 in Asia. Support for RFC 7871 (Client Subnet in DNS Queries) comes into play here too.
Ever since The Great Comcast DNS Outage of 2010, I've had the OpenDNS IPs burned into my memory from telling so many people.
I like the fact that you can sign up for OpenDNS and customize some of the filtering (ads, spam/malware, etc.) They used to have crappy handling of nxdomains (by default) redirecting you to a website with ads, but I believe that's no longer the case?
9.9.9.9 does not seem to be geographically-aware. Here are the resolutions for the same domain name (CNAME referring to the hopefully closest edge server), from France.
% dig [domain] @8.8.8.8 +short
[id].kxcdn.com.
p-frpa00.kxcdn.com. # France
% dig [domain] @9.9.9.9 +short
[id].kxcdn.com.
s-us-ca00.kvcdn.com. # America
p-ussj00.kxcdn.com.
% dig [domain] @1.1.1.1 +short
[id].kxcdn.com.
p-frpa00.kxcdn.com. # France
% dig [domain] @ns0.fdn.fr +short # My ISP resolver
[id].kxcdn.com.
p-frpa00.kxcdn.com. # France
A more comprehensive benchmark would also measure a ping or HTTP request to each resolved IP take to this into account. Actual browser performance is very skewed now without it.
Fair enough, but most users won't care enough look it up and use 9.9.9.10 instead of 9.9.9.9 if they want better performance in exchange for allegedly lower privacy.
It appears 1.1.1.1 also does not pass client-subnet, atleast not by default. Queries to my authoritative from Google always includes client subnet, OpenDNS required request for whitelist. For Cloudflare its unclear.
>It appears 1.1.1.1 also does not pass client-subnet, atleast not by default.
Wow, this is actually a huge issue. Just as a simple test, I tried nslookup google.com for both 1.1.1.1 and 8.8.8.8, and Cloudflare's responses ping at about 200ms, whereas Google's responses ping at ~10ms.
That also explains the abnormally low response time of CloudFlare's solution compared to the 2nd and 3rd place solutions; the geo-location lookups require more time to reach and resolve a decision and thus represent an increase in response time from the resolver (in exchange for improved latency in all future communications to the target server).
If you have a CF PoP close to you, the absent of it shouldn't really matter. Will only have an effect for those with a Google peering much closer than CF peering.
You can run a benchmark of your own using namebench. I recommend you uncheck the options for the included nameservers or it will take a very long time to run and enter only the DNS servers you want to test manually. It can use your Firefox browsing history as a source for domains to resolve.
Ignore the "incorrect" and "hijacked" warnings, I think the program has hardcoded, outdated IP ranges for popular services which causes those.
This is the most alarming thing about this trend that has been happening for the last few years
The Internet should be DECENTRALIZED yet it seems we are attempting to do everything in our power to ensure only a handful of companies control access to all information. For what to save 3 ms off a ping time?
Facebook is in hot water over privacy issues, but that is just the tip of the ice berg
Google, AWS, Cloudflare are IMO are larger threat then facebook ever could be.
You're barking up the wrong tree here. DNS is already an inherently centralized service -- using one company's resolvers instead of another doesn't change that.
the problem with Cloudflare is not simply the fact that DNS is centralized, it is a combination of all their services that is concerning for Cloudflare,
between the DDOS Proxy, the CDN, the Other Services, and now DNS that is a lot of services in a single basket, so while it is true that dns is some what centralized, having all traffic and all services dependent upon a single company seems to be a bad idea to me
But clearly everyone sees not issue with it provided they "claim" to providing a "privacy first" service for free (ya riiiiiggghhhhttttt and Facebook cares about their users privacy as well) and they have better performance, who cares what the long term effects are...
We should be working to make DNS less centralized, or replace it with something less centralized, not moving to DNS over HTTP to a few "cloud" providers who also control all of the content...
If you want to do it on your local linux system, it's pretty easy: you just need to install bind9 and use `nameserver 127.0.0.1` in your /etc/resolv.conf
Bind9 has a poor reputation because of how difficult it is to use it to define zones (manage a domain name), but if you want to use it as a resolver, it's basically plug'n'play.
Huge bonus included : if you want to flush the cache, you just need to run `sudo rndc flush`, so you don't have to wait for TTL timeout to test your newly configured domain name when you setup a website (you still have to restart your browser, because most of them do their own dns caching).
I prefer Unbound as it lets me set a min-ttl. This of course is taboo and comes with caveats, so you have to know what you are doing and the implications. Unbound has better support for DNSSEC as well.
I ran a full recursor on my laptop for about two years. It's not a great choice, especially if you're not stationary. A lot as a lot of environments intercept DNS and poison your cache, the answers for lb'd names also change depending on your geolocation (so you have to flush it every time you move). Your queries are also not really private as you the resolver has to talk to multiple authoritatives to get you your name in a plain text. The performance is also not as great even with prefetching, as you don't benefit from a shared cache.
Probably the best thing you can do is to run something like https://github.com/jedisct1/dnscrypt-proxy which at least retains privacy between you and the resolver, and use public resolvers you trust.
If you don't trust any of them, you could start a resolver on a VM somewhere, but then again that can be traced back to you, so it depends on your threat model.
Both of these options are better than running a full resolver on localhost (unless you expect the recursive DNS infrastructure to fail, while authoritative remains operational).
This is some pretty sage advice. I think it's great that Cloudflare is offering the service, but it's relatively simple (and fun!) to setup up our own. There's guide in the link below for using unbound server to do this. Example#1 fits many people. And, if we choose to censor any domains we can always do so on our own service... take a look at Example#2!
Since a discussion about this topic has been present in every thread about Cloudflare's DNS service, I can quite confidently say "people" didn't forget.
They also allow for websites to look HTTPs-enabled, but the transfer happens in clear text, e.g.:
Client -(HTTPS)> CloudFlare -(HTTP)> Server.
For a company that allegedly is privacy first, this is a huge violation of trust.
I also know about some people that run websites that can't get Stripe because they can't figure out how to configure SSL for their website, they just plug in CloudFlare in front, and now they can communicate with Stripe, and everything is received in cleartext following the diagram i posted.
The threat model of MiTM attacks leans heavily towards the client side than the Cloudflare -> origin connection. It's not perfect and it would be fantastic if everyone could setup SSL on their origin servers, but in the end there's are more script kiddies in coffeeshops than there are tier1 isps trying to steal your data
Flexiable SSL by Cloudflare should itself be considered a MiTM Attack and should be opposed by all security standards, organizations, and anyone that values privacy or security, this highlights the inherent problem with SSL in the first place.
Then again, a few ms of difference is unlikely to make any noticeable effect in real-world use cases where clients already have local DNS caching and the bulk of the time is data transfer, not DNS lookups.
Which ISPs are so bad that you want to use external services, which are further in distance than your ISP, for speed? When I test with my ISP, they beat all of these services (both IPv4 and IPv6). They're simply closer to me in terms of hops.
My router is another story though. The Fritzbox (>200eur router) adds 6ms of latency, and that's what is advertised over DHCP. (Might still be fine, since cached queries are faster than the ping time to the ISP.) Note that my tests were all with uncached queries (random subdomains of a domain), so it always had to go out and ask an external server (though it could cache the NS record for the domain).
I've had several ISPs in different countries that do horrible things. Not using NXDomain is one, but I've had some that return NXdomain when they shouldn't, then cache that result!
8.8.8.8 is consistent and easy to remember, and now so is 1.1.1.1
My isp got the brilliant idea of rolling their own YouTube cache servers. It's great in theory but in or active they're under powered and so at peak hours I can't even stream 240p on my 500mbits connection. I've had to block their cache servers in my firewall for YouTube to be butter smooth at 1080p consistently.
Another example is bell Canada who used to mine your DNS queries to profile you for ads, or ISPs that high jack the nxdomain result to send you sponsored results of vaguely similar sounding websites.
It is common for ISP to host instances of the Google Global Cache (GGC, see https://peering.google.com/) which are used for many Google services, most importantly YouTube.
In fact, in many cases Google itself "suggests" to ISP that they host a few GGC servers.
They are directly monitored by Google, and the ISP has basically no say in how they are run. Capacity is managed by Google directly.
Yep, Virgin Media did this in the UK and messed it up badly. Every day at 6pm YouTube would stop working until the following morning.
It appeared to work by inspecting DNS packets and replying with overrides if necessary. I didn’t like it but I could understand that.
What I did not agree with was the fact that this also happened for other DNS services. Google DNS and OpenDNS both experienced the same issue, as did a few other “famous” DNS providers. Random little ones wouldn’t return the caching servers, and also enabling encrypted DNS for Google/OpenDNS would stop it happening too. I’m fairly sure it was some badly thought out deep packet inspection.
Again, it's probably _not_ Virgin's fault or responsibility. Capacity planning is handled by Google directly.
Also, I think that virtually every ISP with more than a few tens of thousands users is hosting a GGC instance nowadays (and a Netflix OpenCache, etc. etc.).
Nowadays, the vast majority of the transit&peering of ISPs is not going to the Internet, but to a few racks of local caching servers managed by OTT operators.
Bandwidth-wise, at least in prime time, the Internet is much less connected/realtime than people think :)
I would suggest that the deep packet inspection is Virgin's fault. Perhaps it was Google under provisioning the CDN inside VM's network, but I would suggest that's also probably Virgin's fault in part, as they will likely have more network information available to them that may have suggested network congestion, but that was not acted upon.
The YouTube cache is probably there not to increase performance for you, but to reduce ISP cost (ISP pays for all data received from outside of their network)
When there's a competition this often equates with making customers happy so they will stick with the ISP and perhaps more will switch from competitors.
When there's no competition and customers have no choice who to use it's purely all about squeezing as much money as they can. This means raising prices for the service and reducing cost by paying less to others services even if it would reduce quality of service.
The goal is to have service that's good enough to keep people still use them (I mean there is price point and/or quality that people would just not to have service at all).
If a specific action that ISP with monopoly does and it improves quality for customer that's just a coincidence.
Even for data not delivered via their cache they'll get free peering with Google. But having cache servers at several locations reduces the capacity they need to peering points. E.g. in the UK, most traffic gets peered in London so having cache servers in Northern England reduces the bandwidth they need for their internal network within the country.
I don't think ISPs pay much for peering in Europe.
As someone else suggested, this is likely part of our GGC program. If you can give me info on which ISP + Geographic region you're in, I can take a look and see if there's anything in our logs to indicate a problems; you can email me details at myusernamehere at google dot com with details, since I don't routinely check Hacker News.
If you can reproduce a bad experience, and right click on the player, click "Get Debug Info", and share that result, it's the most helpful thing for us to dig into problems.
Time Warner/Spectrum, the largest provider in NYC (and the only one that services my apt building) does this. They let you turn it off in your account settings, but it doesn't actually turn it off.
CenturyLink, major telecom in 37 US states. DNS requests for all nonexistent domains go to a server that delivers a dumb "search" page to web requests. They're currently the sole fiber-to-the-home provider in my neighborhood, and Comcast is the only broadband alternative.
I live near Toronto Canada and Rogers my ISP hijack's DNS requests for non existent domains. The data to back up my bold statement is a simple Google search which reveals that they have been doing this at the very least from my Google search was from 2008.
It is possible to turn off this feature, But it is set by a cookie and once that cookie is deleted you have to do it all over again.
Brighthouse did it before they became Spectrum. They did allow me to turn it off though. I've heard that this is still the case with Spectrum, but I haven't tested.
There was a story in acient China something like below:
One official:People are starving to death, my king.
The King: Really, why don't they eat some meat pasty?
--------------
You don't have any problems, so would the others right?
Queries to my local Spectrum DNS service are 4 times slower than 1.1.1.1, and they redirect you to stupid search pages instead of `NXDOMAIN`. I switched the whole network over this morning.
I know you're asking in jest, but here's an honest answer: Google Fiber. Google's DNS servers are ~15ms further away than a local ISP who runs public DNS servers as well (xmission). Part of this is because google fiber has a peering connection at SLIX (slix.net), and so does xmission, whereas Google's DNS servers appear to be in the bay area.
Whether or not it's noticeably faster, I'm not sure, but I've always used xmission's dns servers without fault for the past 10 years.
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.763/18.264/18.803/0.425 ms
--- 198.60.22.2 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.906/3.457/3.871/0.408 ms
My own tiny neighborhood ISP thinks they are smart and have their own CDN for caching everything under the sun. Of course it doesn't work well, not only it caches DNS and HTTP requests like kids collecting candy in Halloween but it also breaks HTTPS sometimes.
As an anecdote of how bad ISP caching can hurt you, I am a web developer and I was debugging an issue in a legacy system. I had fixed the stuff and deployed a new version. Erased all the caches in my machine, refreshed the page, broken. I thought that maybe I fixed the wrong thing and started fixing more... now rinse and repeat over five hours before you realize that the cache is happening at ISP level and that things are fine in the live version on the real internet. This ISP is called PredialNet, web developers from the city call it PredialCache...
I know this is about DNS and not HTTP but their cache servers will also cache DNS requests, so moving some domain to a new machine and IP is also a quest under their network. For a while I paid PIA so that I could side-step their cache servers.
Sometimes it's not even at the ISP level. I experienced a similar adventure a few months ago. I turns out that my cellular hotspot caches PDFs. It's not even at the ISP level, it's in the little box in my pocket.
The ones that cooperate with state-sanctioned censorship? Malaysia blocks anti-government news sites via ISP DNS entries; using a 3rd party DNS bypasses the block easily.
Accusing government officials of mismanagement or outright theft of public funds is an easy way to get your domain black holed over here. That, piracy, and porn. Though I wouldn't be surprised if the latter two were thrown in solely to make the program look more legit.
Perhaps most ridiculously, Medium.com is blocked for simply hosting an article posted by a censored website. Yes, you read that right; they banned an entire domain, the vast majority of which covers nothing even remotely related to Malaysia, over a single article.
I try to be grateful they are as inept at censorship as they are oversensitive to criticism.
It’s best to just pretend those DNS things are a good way for bureaucrats to achieve whatever it is because they’re so easy to circumvent and the alternative is far worse.
> Which ISPs are so bad that you want to use external services, which are further in distance than your ISP, for speed?
When I upgraded my WiFi equipment at home a month ago I thought it was defective. Multiple times every day I'd seem to lose connectivity to the internet. After two weeks it occurred to me that my previous router was configured to do a couple things for me, one of which was overriding what DNS servers were assigned with DHCP. I reconfigured my new equipment to use those DNS servers and suddenly everything works normally.
Not really :( I'm looking to replace my router entirely soon anyhow, and hoping this does the trick. My hardwired devices don't seem to have this problem.
VirginMedia UK nameservers are notoriously poor, they just stop responding or disappear for hours. At least with Google I’m more or less guaranteed a response, as slow as it might be. I’m in an area where VM is the only cable operator, so I couldn’t switch without either losing on speed or spending a ton of money for someone else to cable me up.
I do try to use VM dns, but I periodically have to reverse to Google and often forget to switch back post-outage.
In the U.S., many of them are mining and selling our data. Getting off of their DNS service is one step in mitigating this.
Also, as others mention, they can and do monkey with the results.
In other words, here, your ISP is in part a hostile entity. At least, in my perception -- and I'm not alone.
P.S. Of course, there's the argument against giving Google all your DNS usage, as well... I use a different DNS service from a company with a good reputation that says it's not collecting usage data. Even then, and with the state of our State, who knows...
Mine's over a VPN. And if you use a VPN, make sure your DNS traffic is using it (along with some other types of traffic that can bypass it, if you're not careful).
I run a local caching server on my network 192.168.1.22, from there I now forward to cloudflare, then to opendns on misses. This makes DNS resolution blazing fast for things we frequent.
I use my ASUS router's DHCP to teach all my dynamically configured network devices how to find the bind9 DNS caching server.
All the statically configured ones just have 192.168.1.22 hard coded with 1.1.1.1 as backup.
All ISPs in Denmark are required to implement a filtering list of somewhat arbitrarily chosen websites, including a number of torrent sites, illegal pornography and probably others. There is a very reasonably fear that this could be used for political purposes.
This filter list is implemented through DNS, making third-party DNS services the most practical workaround.
Indonesian ISPs are required to filter certain domains, but go further than the Denmark case - they also block access to third-party DNS servers. Using DNScrypt or a VPN (or hosting your own DNS on a port they're not blocking like 80) is the only workaround.
Prior to third-party DNS servers being blocked a lot of tech-savvy people were using either Google's DNS or OpenDNS anyway since they tend to be more reliable than the local ISP's (even before they started filtering).
I'm no longer in Indonesia, but I could imagine the results people are posting here would be useful to folks back home so they can adjust their DNScrypt config.
Comcast... before changing DNS on my network, I tested a variety of DNS providers including Comcast. While Comcast had the best individual test minimum and average times, Comcast repeated testing showed lost packets and the occasional worst max times.
I don't know why they faired as poorly as they did, but once I realized some network issues could be pinned against DNS packet loss / terrible performance spikes, I changed over to 9.9.9.9 and 8.8.8.8 as the fall back. Home network has been a bit more stable since the change over.
One of the issues is that many ISPs don't actually run their own recursive DNS servers... They outsource to companies which provide a "monetized solution," operating the recursive resolvers and paying the ISP in exchange for the customers' data, which they sell. This will become an illicit activity shortly in Europe, as the GDPR comes into effect, but there are many ISPs that have become very used to receiving those payments. And most of them already don't admit to selling their customers' privacy.
So privacy is why many of the people who use a different recursive nameserver are doing so... In order for that to work, you need to use one of the ones which support link-level encryption, like Quad9 (DNS-over-TLS) or OpenDNS (DNScrypt). Other reasons are performance (which at least in Quad9's case should be no worse than your ISP for real-world queries, since it's back-to-back with many of the authoritative servers already, and all of them will give you a large pool of other users sharing the same cache, which helps performance immensely), and security... Going back-to-back with the authoritative servers also collapses the attack surface between them, minimizing the possibility for MITM attacks between the recursive and authoritative servers.
My ISP is Comcast, a company I can trust about as much as I can throw it, so I use DNSCrypt when I'm not otherwise on a VPN, and have a number of fallback DNS providers for when DNSCrypt doesn't work.
Reasonably speaking I don't need very much from a DNS provider: <15ms latency, basic DNS security features and the ability to display an error rather than redirect me to a sponsored results page. I can do without the extra filters, but as long as I can get those three things, then I would rather use a different service than my ISP.
Does no one bother to run their own DNS server? It's not hard---in fact, it's easier than running an authoritative DNS server, since you are only using it for local resolving.
I ran the provided script, added my own local resolver, and after the first run, got incredibly fast results.
test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 Average
cloudflare 35 ms 38 ms 39 ms 33 ms 34 ms 39 ms 28 ms 33 ms 28 ms 39 ms 34.60
cloudflare2nd 34 ms 27 ms 34 ms 34 ms 34 ms 27 ms 34 ms 28 ms 28 ms 28 ms 30.80
google 42 ms 27 ms 27 ms 40 ms 28 ms 40 ms 28 ms 40 ms 40 ms 28 ms 34.00
google2nd 42 ms 27 ms 28 ms 43 ms 41 ms 39 ms 28 ms 41 ms 41 ms 28 ms 35.80
quad9 65 ms 64 ms 54 ms 65 ms 63 ms 53 ms 59 ms 52 ms 60 ms 53 ms 58.80
opendns 45 ms 32 ms 56 ms 51 ms 29 ms 74 ms 32 ms 48 ms 45 ms 32 ms 44.40
norton 92 ms 73 ms 56 ms 152 ms 48 ms 144 ms 68 ms 40 ms 77 ms 83 ms 83.30
cleanbrowsing 33 ms 28 ms 33 ms 28 ms 33 ms 35 ms 28 ms 32 ms 33 ms 29 ms 31.20
yandex 174 ms 174 ms 185 ms 178 ms 184 ms 179 ms 179 ms 199 ms 176 ms 186 ms 181.40
adguard 143 ms 147 ms 146 ms 142 ms 148 ms 143 ms 130 ms 130 ms 138 ms 137 ms 140.40
neustar 62 ms 63 ms 70 ms 80 ms 40 ms 74 ms 73 ms 151 ms 58 ms 65 ms 73.60
comodo 60 ms 137 ms 59 ms 60 ms 59 ms 59 ms 64 ms 62 ms 60 ms 59 ms 67.90
localhost 0 ms 0 ms 0 ms 0 ms 0 ms 0 ms 0 ms 0 ms 0 ms 0 ms 0
Most people are not very interested in testing how fast their local machine can talk to itself; regardless of how fast your local cache is, it will have to talk outside pretty often (for expiring TTL if nothing else).
People are praising CloudFlare for not bothering to log requests. Yes, well ... you get the same results by using your own DNS resolver, and you don't have to be shocked when five years later a different governing team running CloudFlare decide to reverse their stance and log everything ...
But what do I know? Apparently I'm in the minority for running my own infrastructure (DNS, web, mail).
If you talk to an upstream resolver through an encrypted link (both CloudFlare and Google support DNSoverTLS and DNSoverHTTPS, at least) then you at least limit the potential privacy threats.
Do you ever wonder if such activity (basically trying to be invisible) will put you under far more scrutiny than if you were to just 'be normal'? Thinking from the other side of it you would be a high value target to monitor as closely as possible if I were law enforcement. I know it sounds ridiculous but you may actually have more privacy (unless you're actually breaking the law) by hiding in plain sight with the rest of us.
Where do you think your DNS resolver gets the answers it gives you? You're just introducing a caching layer between you and whatever external resolver you're using. The first time a machine requests a domain (and every time a TTL expires; look at CDN TTLs sometime) you are effectively talking to the internet just like everyone else.
If you live close to a peering point, both CF and Google will have mean ping times <10ms, often even <5ms. I doubt there's any real world difference between using localhost and either of them. As they cache results, using them could actually be faster than your own server.
"Which ISPs are so bad that you want to use external services"
Any ISP that tries to redirect me to an ad-filled half-baked web search whenever I run into an inactive domain would definitely fall into my "so bad that I want to use external services" bucket.
Verizon's DNS seems to have improved, but a few years ago I ran into consistent problems resolving even the biggest / most common domains. My brief never-to-be-repeated dalliance with Comcast in 2016 was even worse.
Is there a tutorial on setting up your own? I've got a huge hosts file and would like it to affect all the devices at my home but setting up a DNS server always seemed high-level black magic to me.
Things to look for in comparing recursive DNS servers performance:
The 95%ile DNS response time for cached/uncached names. The 95%ile DNS response when one/some of the authoritative nameservers is "lame" or not responding. (better yet, 99%ile, but that requires even more queries...)
The average packet loss to the nameserver. (As many resolvers use the default of a 5s timeout, better resolvers use a 1s timeout, the best stub resolvers would use a dynamic timeout, but afaik, none do...).
Do they implement RFC7129 (authenticated denial of existence)? This can be used to prevent your service being used to attack an authoritative nameserver, prevents leaks of useless domains (eg machines looking up untitled.pdf as a domain), and allows you to return NXDOMAIN with much lower latency, making DNS search paths faster. RFC8020 (NXDOMAIN: There is really nothing underneath) would be another example where you can prevent leaking names, and return faster responses from a smaller cache (although I admit I've never seen anyone implement RFC8020 yet).
Will they accept (signed) responses into their cache in the additional section? Again, this can significantly reduce the time for uncached responses.
[hint: These are good reasons you should sign your domain, it can make things faster and reduce load on your authoritative nameserver!]
What is their story for domains that need a cache flush?
Do they (correctly) implement IPv6 from the recursive to the authoritative nameservers? Do they (correctly) implement IPv6 from the stub to the recursive nameserver?
How big is their cache? How long do things stay in their cache? There's no point being close to a nameserver with an empty cache. Querying www.google.com isn't really going to tell you much about their cache depth, nor is the Alexa 1M. You need a very very wide variety of names.
Do they provide good GeoIP responses? There's no point in getting an answer for the middle of the US in <1ms if you happen to be 300ms away in Asia somewhere. The DNS response was fast, but the webserver it sent you to is going to give you abysmal performance. This is often done with EDNS0-Client-Subnet, but it can also be fudged by making the outbound IPs for the iterative requests being diverse enough for different localities.
Do they "lie" about names? In what circumstances do they lie? Do they NXDOMAIN malicious domains? adult websites? ad domains? random websites? Do they redirect ad websites to their own ad farm? How do their lies handle DNSSEC?
Do they perform QNAME minimalisation to help protect your queries from servers that don't need it?
What other features do they implement to make sure their cache is never poisoned?
What is their abuse plan? If I send them a vast number of queries what happens? Do they send back TrunCated responses and force me over TCP? Will they respond with SERVFAIL? Or will they drop the queries? Or will they pass them all through to the authoritative nameservers? Do I need to do anything (other than stop sending abusive amounts of load) to be unblocked? What if the reason I'm sending a large number of queries is because I'm a carrier grade NAT IP pool and I have one broken/bad user?
What is their reliability story? Is it expected that they will go down for 10 minutes every now and again?
What do they do about general Internet Hygiene? Do they have protects against being used for reflection attacks?
Do they do preemptive lookups to keep their cache warm or is someone always guaranteed to have to wait for the full resolution? How do they make sure they don't accidentally DoS authoritative nameservers wit...
This is a great comment. The ping time is so much less meaningful for recursive service than for authoritative. The latency difference between cached answer and uncached answer is in several orders of magnitude. The cache hit ratio also plummets without some sort of cache sharing, which many recursive services don't implement. So you may end up with great ping time, but something like:
Mentally you need to add a big asterisk to tests of CDNs, and by extension "dns done like a cdn" from VPS provider networks (content networks). That's not where users come from (eyeball networks), and therefore not where they focus their efforts in peering and route-optimizing.
This tests the performance / distance between vps data centers and the dns server's data centers. imho it's better to have a test web page that consumers visit and establishes a tcp connection to those dns services and estimate the rtt of a single packet from the time it took to establish the connection, or test via the https interface for services that support it.
While I whole-heartedly agree with your objection, I question the solution. How do you get high accuracy timing of DNS resolution in JavaScript inside the browser?
The challenge in providing a good dns service is more about having nodes closer to the user than the dns resolution step itself because that in theory is almost constant for cached responses (it's usually in the microseconds) and when it's not cached the response time is really dependent on recursive querying of other dns servers. So the dns resolution can me estimated by measuring it from a data center manually and subtracting the rtt and use that as a constant.
To estimate the rtt, you can do an xhr request and grab the connectStart and connectEnd using window.performance API keeping in mind it takes 3 rtt to do the handshake. Note that the request will fail for services that don't provide https support but that's ok because we just want to measure connect.
The reason cloudflare has a better performance is most likely because they have better coverage and not because their servers are faster. Faster servers are a small factor in the final response time.
For services that provide https support you can accurately measure the connect and response time of the XHR request using window.performance interface and subtract the dns resolution of the request. Also if you do the request twice, the second time is likely to have a dns and connect time = 0.
Not a JavaScript developer, but if they can do timings fine enough to run Meltdown attacks in JS, I think they can safely and accurately measure network timings.
Timing in general isn’t the issue here, there isn’t a way to my knowledge to get just the DNS portion (specifically across an arbitrary set of DNS providers) of the network timing in JS. Just like there isn’t a way to test the timing of a single packet really either.
See original context, it is clearly about evaluating DNS providers with real end users via a web app. Considering a majority of providers don’t support it, seems it’ll be a very limited evaluation if it followed your proposal.
You'd have to change your nameserver manually unfortunately.
But you could build a good webpage that actually measures how well your current nameserver performs over a wide variety of different types of lookups, both warm and cold caches etc.
363 comments
[ 3.5 ms ] story [ 300 ms ] threadGoogle/Cloudflare tackled the UX of free DNS spectacularly with these gold IP addresses. It's the primary reason I use them instead of OpenDNS, which was an earlier player in this space.
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."
There is a lot of documentation, Cisco being one of the primary at-fault companies, that uses 1.1.1.1 for all kinds of various internal configuration.
Given hundreds of thousands of devices configured with 1.1.1.1, even a simple misconfiguration on just 10% of those is a lot of garbage traffic.
What cloudflare don't say in any of their materials that I've seen is the agreement is for an initial 5 years, so YMMV after that.
Presented as a weird, intermittent, "hey the internet is out" at the office around the same time each afternoon.
Between that and some of the content filtering options you can get with the paid plan, I find that it's a very full-featured option for homes with young kids. I'm pretty sure you get to control the logs on the paid plan too. Need to double check.
Keep away from this.
The simple fact that it's supported by the CoLP doesn't seem sufficient to point out that Quad9 should be avoided since it will track people online.
(Actually, it's not really a difficult choice at all, is it?)
https://www.quad9.net/about/
https://www.youtube.com/watch?v=LrObZ_HZZUc
http://news.cityoflondon.police.uk/r/945/ibm__packet_clearin...
https://www.cityoflondon.police.uk/advice-and-support/cyberc...
If you dug a little deeper on one of your own links you would find that the NYC DA and City of London Police Department donated money to establish a 501(c)3 non-profit to combat cyber crime. That 5013C is but one member of a consortium of 3 companies behind Quad9.
"Knowing the potential that an organisation like GCA could have, the DA committed $25 million in criminal asset forfeiture proceeds to fund this critical work over a five-year period. The Center for Internet Security and City of London Police also made significant contributions in providing space, funding, staff, and assistance with building strategic partnerships."[1]
[1] https://www.globalcyberalliance.org/about.html#history
Fixed? =P
I removed some of the records form the article after reading some of the comments here. Cloudflare, Google, and OpenDNS only.
Kind of cool, I switched it up and ran it against 10 sites I frequent... was pretty impressed to see how well OpenDNS was doing.
>Our test was very simple and we performed 70 DNS lookups
That's not ICMP.
So i would say icmp is good proxy to actual performance.
And is your point that the tested sites aren't popular in Russia?
>for different popular domains (google, facebook, twitter, gmail, etc)
google.com facebook.com and twitter.com are all in the top 50 sites in Russia[1]. And gmail.com is number 6000 globally[2], so it's unpopular everywhere, not just Russia. Popular sites in Russia tend to be popular elsewhere, and vice versa.
[1] https://www.similarweb.com/top-websites/russian-federation
[2] https://www.alexa.com/siteinfo/gmail.com
You're looking for "dig @1.1.1.1 news.ycombinator.com" which will resolve "news.ycombinator.com" using "1.1.1.1".
EDIT: fixed, so I've undowned
It would be better to just delete this whole subtree.
Cloudflare consistently times out from these networks.
Netherlands - AS13127 Philippines - AS135132 Thailand - AS17552 (One of the largest consumer internet providers) US - AS7018 (AT&T)
1.1.1.1 does not resolve.
Oh, and I definitely don't buy this for Google: "The Privacy option above is based on the providers promise to do not log or share your DNS requests."
Basically there are two log files kept:
- One for up to 48 hours which contains IP addresses, which is used for handling abuse.
- One is permanent which doesn't contain any personal identifying information (eg IP addresses), which is used for things like internal performance monitoring, load testing, and tracking frequency of longer term abuse etc.
Google provides Google public DNS because if you see the internet as being slow because of poor DNS performance, then you don't use websearch as much. Google doesn't need to use Google Public DNS to track users, and would rather not have the information (as it makes it available for government requests etc which are a major pain to deal with). But running a large scale recursive DNS server tends to attract a _lot_ of abuse, both intentional, and unintentional as I'm sure 9.9.9.9 and 1.1.1.1 are discovering.
Google provides Google Public DNS because a lot of ISPs provide extremely poor default recursive nameservers (having tiny caches, dropping queries due to overload, not implementing IPv6, DNSSEC validation, EDNS0 payload size, or other important modern DNS features. Some ISPs also hijack domains for their own purposes, or "stretching" DNS TTLs etc) so providing a better alternative to improve overall Internet use is clearly in Google's best interest.
Having other public resolvers, with different trade offs is clearly better for everyone, including Google as long as they are reliable, trustworthy, and provide low latency responses.
Good luck to everyone who's joining in the fun of running a planet scale recursive DNS server.
(Disclaimer: I have previously worked on Google Public DNS, but no longer do)
My uninformed assumption is that chrome generally uses whatever is configured in the system resolver, otherwise things like captive portals, and split horizon DNS wouldn't work properly, but I don't specifically know.
(Disclaimer: I'm a Google corporate shill)
If your local DNS server is merely querying an upstream resolver (like 1.1.1.1 / 8.8.8.8) on your behalf, then yes - it is no different.
If however, you query the root nameservers for the glue record for a domain and query the domain's own nameservers directly, then it is pretty good... As you are neither querying your ISP or TheMan.. which means that logically only the domain nameserver owner knows what queries you made (and you are probably hitting that domain in a moment anyway!). (The caveat is that some ISP's do transparent DNS proxying.. in which case, you have much larger trust issues with your ISP and need to take greater measures!)
That said.. I cba with that.
I once had an ISP which did transparent http proxying. You could theoretically query an external DNS server and get back the correct result, but it would intercept your http connection, discard the ip address you were trying to connect to then do a new DNS lookup to the ISP's DNS server on the HOST header.
Took me ages to work out what was going on with the various issues it was causing.
I dumped that ISP like a rock after they refused to disable that caching proxy, which they claimed was only there to improve customer experience.
But these are different people, with different incentives. The NS owner may be logging everything, without the domain owner's knowledge, and the NS owner won't even be in the wrong, because they likely made no promise to not log.
With a single resolver, I can verify that they're trustworthy enough [for me], just once, and direct all my traffic to it. Cloudflare's "We committed to never writing the querying IP addresses to disk and wiping all logs within 24 hours" is something, I imagine, they very much wouldn't want to be caught violating or changing their mind about later.
In the meanwhile, with the root NS method, I can only hope that my queries will get lost in the "noise". And I'm putting noise in quotation marks because there isn't much diversity in the name server ownership: 75% of Alexa top 1M domains are hosted at Cloudflare, GoDaddy and Amazon. [0]
[0] https://www.datanyze.com/market-share/dns/Alexa%20top%201M/
QNAME minimalisation will only send <randomstring>.com to the root for them to give you the referral.
and RFC7129/RFC8020 mean that when you get a NXDOMAIN back from the root, you'll cache it and never try again for a large swath of possible names.
Apply this deceptively simple principle to every need you have on our wonderfully decentralized Internet and see where that gets us.
Oh snap. Not so decentralized anymore.
Okay, say, 1 year from now, somehow, 95% of internet users are sending their DNS queries to Cloudflare. What can go wrong? Malicious or not. Not rhetorical, actually curious.
Centralizing things, makes it easy for law-makers to enforce bad policy which technology otherwise would have side-stepped.
However, if have a local TLS nameserver, you can set it up to query 1.1.1.1 over TLS, then your ISP can't see any of your DNS queries.
So you need to decide who you trust more -- your ISP or a DNS provider (or a VPN provider).
And use long TTL time with large cache size.
Other than some small edge cases, this is pretty much the most secure and fastest DNS performance you will have, in most instances getting about 1 or <1ms speed. Depending on DNS server you can even have both root servers and resolver configured.
I have been using unbound for at least 4 years. Simple and fast.
Is there a different DNS server you would recommend? I don't think my usage requires anything special.
I'm increasingly beginning to think that every node should be it's own dns so it's cache blacklist can be verified (checksums?) per node instead of per request to the dns provider.
But just found out today that, from Sydney, OpenDNS and Cloudflare are kicking Google's ass for speed. 8.8.8.8 is on par with my ISP-default DNS.
I like the fact that you can sign up for OpenDNS and customize some of the filtering (ads, spam/malware, etc.) They used to have crappy handling of nxdomains (by default) redirecting you to a website with ads, but I believe that's no longer the case?
Pihole is also a great alternative if you have a spare raspi lying around.
Really, if you have a spare computer of any type. I run it on a VM and it works just fine. It was made for Raspberry Pis but it'll work on any system.
[1] https://www.quad9.net/faq
It appears 1.1.1.1 also does not pass client-subnet, atleast not by default. Queries to my authoritative from Google always includes client subnet, OpenDNS required request for whitelist. For Cloudflare its unclear.
Wow, this is actually a huge issue. Just as a simple test, I tried nslookup google.com for both 1.1.1.1 and 8.8.8.8, and Cloudflare's responses ping at about 200ms, whereas Google's responses ping at ~10ms.
Ignore the "incorrect" and "hijacked" warnings, I think the program has hardcoded, outdated IP ranges for popular services which causes those.
https://code.google.com/archive/p/namebench/
ps: namebench is quite extensive. thousands of queries and a nice and long report. enjoy it
Seems they've sunset .11 and .12, but .10 is still up.
Or you can even use a CLI https://perfops.net/cli to run custom tests from any location
https://fightthefuture.org/article/the-new-era-of-corporate-...
..and even though CloudFlare back pedaled on that particular decision somewhat, it still happened.
If you really want something fast and secure, run your own caching DNS that uses root DNS servers.
The Internet should be DECENTRALIZED yet it seems we are attempting to do everything in our power to ensure only a handful of companies control access to all information. For what to save 3 ms off a ping time?
Facebook is in hot water over privacy issues, but that is just the tip of the ice berg
Google, AWS, Cloudflare are IMO are larger threat then facebook ever could be.
the problem with Cloudflare is not simply the fact that DNS is centralized, it is a combination of all their services that is concerning for Cloudflare,
between the DDOS Proxy, the CDN, the Other Services, and now DNS that is a lot of services in a single basket, so while it is true that dns is some what centralized, having all traffic and all services dependent upon a single company seems to be a bad idea to me
But clearly everyone sees not issue with it provided they "claim" to providing a "privacy first" service for free (ya riiiiiggghhhhttttt and Facebook cares about their users privacy as well) and they have better performance, who cares what the long term effects are...
We should be working to make DNS less centralized, or replace it with something less centralized, not moving to DNS over HTTP to a few "cloud" providers who also control all of the content...
is there a good tutorial for this somewhere?
Bind9 has a poor reputation because of how difficult it is to use it to define zones (manage a domain name), but if you want to use it as a resolver, it's basically plug'n'play.
Huge bonus included : if you want to flush the cache, you just need to run `sudo rndc flush`, so you don't have to wait for TTL timeout to test your newly configured domain name when you setup a website (you still have to restart your browser, because most of them do their own dns caching).
There are other options too, I don't know what makes Unbound better than PowerDNS Recursor or Knot Resolver.
YMMV, but bind’s poor reputation in my circles has completely to do with this:
https://www.cvedetails.com/product/144/ISC-Bind.html?vendor_...
Probably the best thing you can do is to run something like https://github.com/jedisct1/dnscrypt-proxy which at least retains privacy between you and the resolver, and use public resolvers you trust.
If you don't trust any of them, you could start a resolver on a VM somewhere, but then again that can be traced back to you, so it depends on your threat model.
Both of these options are better than running a full resolver on localhost (unless you expect the recursive DNS infrastructure to fail, while authoritative remains operational).
https://calomel.org/unbound_dns.html
I also know about some people that run websites that can't get Stripe because they can't figure out how to configure SSL for their website, they just plug in CloudFlare in front, and now they can communicate with Stripe, and everything is received in cleartext following the diagram i posted.
Cloudflare calls this "Flexible SSL", and it is described here: https://support.cloudflare.com/hc/en-us/articles/200170416-W...
I have flagged this for both Cloudflare and Stripe, but none seems to care.
Then again, a few ms of difference is unlikely to make any noticeable effect in real-world use cases where clients already have local DNS caching and the bulk of the time is data transfer, not DNS lookups.
You’d be surprised.
My router is another story though. The Fritzbox (>200eur router) adds 6ms of latency, and that's what is advertised over DHCP. (Might still be fine, since cached queries are faster than the ping time to the ISP.) Note that my tests were all with uncached queries (random subdomains of a domain), so it always had to go out and ask an external server (though it could cache the NS record for the domain).
8.8.8.8 is consistent and easy to remember, and now so is 1.1.1.1
Another example is bell Canada who used to mine your DNS queries to profile you for ads, or ISPs that high jack the nxdomain result to send you sponsored results of vaguely similar sounding websites.
Are YouTube videos not served using https? Sounds like it's google/YouTube servers but they're underprovsioned
In fact, in many cases Google itself "suggests" to ISP that they host a few GGC servers.
They are directly monitored by Google, and the ISP has basically no say in how they are run. Capacity is managed by Google directly.
It appeared to work by inspecting DNS packets and replying with overrides if necessary. I didn’t like it but I could understand that.
What I did not agree with was the fact that this also happened for other DNS services. Google DNS and OpenDNS both experienced the same issue, as did a few other “famous” DNS providers. Random little ones wouldn’t return the caching servers, and also enabling encrypted DNS for Google/OpenDNS would stop it happening too. I’m fairly sure it was some badly thought out deep packet inspection.
Also, I think that virtually every ISP with more than a few tens of thousands users is hosting a GGC instance nowadays (and a Netflix OpenCache, etc. etc.).
Nowadays, the vast majority of the transit&peering of ISPs is not going to the Internet, but to a few racks of local caching servers managed by OTT operators.
Bandwidth-wise, at least in prime time, the Internet is much less connected/realtime than people think :)
A competent ISP operating in good faith will execute and expand peering agreements when it makes economic sense to do so.
That's probably the funniest thing I've read all year
When there's a competition this often equates with making customers happy so they will stick with the ISP and perhaps more will switch from competitors.
When there's no competition and customers have no choice who to use it's purely all about squeezing as much money as they can. This means raising prices for the service and reducing cost by paying less to others services even if it would reduce quality of service. The goal is to have service that's good enough to keep people still use them (I mean there is price point and/or quality that people would just not to have service at all).
If a specific action that ISP with monopoly does and it improves quality for customer that's just a coincidence.
I don't think ISPs pay much for peering in Europe.
If you can reproduce a bad experience, and right click on the player, click "Get Debug Info", and share that result, it's the most helpful thing for us to dig into problems.
Get your own at http://hnreplies.com/ - built by Dan Grossman
Source: I've yet to see this on any ISP I've used anywhere, sans free airport wifis. Travelled pretty much every continent on earth.
I'm pretty sure I had a previous ISP that did it too, but I can't remember which one now.
http://www.dslreports.com/forum/r31369156-AT-T-DNS-Intercept...
Your anecdote means nothing, you stupid piece of shit.
That’s hardly evidence if any.
> "That's hardly evidence if any"
I'm sorry what?
> I've yet to see this on any ISP I've used anywhere, sans free airport wifis. Travelled pretty much every continent on earth.
I guess you've never been to Turkey.
Hardly “most” ISPs as claimed in the post I replied to. Not even a fraction.
https://en.m.wikipedia.org/wiki/DNS_hijacking#Manipulation_b...
It is possible to turn off this feature, But it is set by a cookie and once that cookie is deleted you have to do it all over again.
I don't have Comcast anymore (not even available in my area), I can't tell you if it's current practice.
EDIT: lots of ISPs do it, in fact: https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...
Whether or not it's noticeably faster, I'm not sure, but I've always used xmission's dns servers without fault for the past 10 years.
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 17.763/18.264/18.803/0.425 ms
--- 198.60.22.2 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.906/3.457/3.871/0.408 ms
As an anecdote of how bad ISP caching can hurt you, I am a web developer and I was debugging an issue in a legacy system. I had fixed the stuff and deployed a new version. Erased all the caches in my machine, refreshed the page, broken. I thought that maybe I fixed the wrong thing and started fixing more... now rinse and repeat over five hours before you realize that the cache is happening at ISP level and that things are fine in the live version on the real internet. This ISP is called PredialNet, web developers from the city call it PredialCache...
I know this is about DNS and not HTTP but their cache servers will also cache DNS requests, so moving some domain to a new machine and IP is also a quest under their network. For a while I paid PIA so that I could side-step their cache servers.
Naturally, it can't be disabled.
great example of how the Real World works vs what consumers think
Accusing government officials of mismanagement or outright theft of public funds is an easy way to get your domain black holed over here. That, piracy, and porn. Though I wouldn't be surprised if the latter two were thrown in solely to make the program look more legit.
https://cilisos.my/8-sites-the-malaysian-gomen-blocked-in-20...
Perhaps most ridiculously, Medium.com is blocked for simply hosting an article posted by a censored website. Yes, you read that right; they banned an entire domain, the vast majority of which covers nothing even remotely related to Malaysia, over a single article.
I try to be grateful they are as inept at censorship as they are oversensitive to criticism.
When I upgraded my WiFi equipment at home a month ago I thought it was defective. Multiple times every day I'd seem to lose connectivity to the internet. After two weeks it occurred to me that my previous router was configured to do a couple things for me, one of which was overriding what DNS servers were assigned with DHCP. I reconfigured my new equipment to use those DNS servers and suddenly everything works normally.
To answer the question asked: Spectrum.
I have Spectrum and have been fighting this exact problem for months. Trying out your steps now and hoping for success.
I do try to use VM dns, but I periodically have to reverse to Google and often forget to switch back post-outage.
Also, as others mention, they can and do monkey with the results.
In other words, here, your ISP is in part a hostile entity. At least, in my perception -- and I'm not alone.
P.S. Of course, there's the argument against giving Google all your DNS usage, as well... I use a different DNS service from a company with a good reputation that says it's not collecting usage data. Even then, and with the state of our State, who knows...
I use my ASUS router's DHCP to teach all my dynamically configured network devices how to find the bind9 DNS caching server.
All the statically configured ones just have 192.168.1.22 hard coded with 1.1.1.1 as backup.
This filter list is implemented through DNS, making third-party DNS services the most practical workaround.
Prior to third-party DNS servers being blocked a lot of tech-savvy people were using either Google's DNS or OpenDNS anyway since they tend to be more reliable than the local ISP's (even before they started filtering).
I'm no longer in Indonesia, but I could imagine the results people are posting here would be useful to folks back home so they can adjust their DNScrypt config.
I don't know why they faired as poorly as they did, but once I realized some network issues could be pinned against DNS packet loss / terrible performance spikes, I changed over to 9.9.9.9 and 8.8.8.8 as the fall back. Home network has been a bit more stable since the change over.
So privacy is why many of the people who use a different recursive nameserver are doing so... In order for that to work, you need to use one of the ones which support link-level encryption, like Quad9 (DNS-over-TLS) or OpenDNS (DNScrypt). Other reasons are performance (which at least in Quad9's case should be no worse than your ISP for real-world queries, since it's back-to-back with many of the authoritative servers already, and all of them will give you a large pool of other users sharing the same cache, which helps performance immensely), and security... Going back-to-back with the authoritative servers also collapses the attack surface between them, minimizing the possibility for MITM attacks between the recursive and authoritative servers.
Reasonably speaking I don't need very much from a DNS provider: <15ms latency, basic DNS security features and the ability to display an error rather than redirect me to a sponsored results page. I can do without the extra filters, but as long as I can get those three things, then I would rather use a different service than my ISP.
I ran the provided script, added my own local resolver, and after the first run, got incredibly fast results.
But what do I know? Apparently I'm in the minority for running my own infrastructure (DNS, web, mail).
Any ISP that tries to redirect me to an ad-filled half-baked web search whenever I run into an inactive domain would definitely fall into my "so bad that I want to use external services" bucket.
https://www.opennic.org/
The 95%ile DNS response time for cached/uncached names. The 95%ile DNS response when one/some of the authoritative nameservers is "lame" or not responding. (better yet, 99%ile, but that requires even more queries...)
The average packet loss to the nameserver. (As many resolvers use the default of a 5s timeout, better resolvers use a 1s timeout, the best stub resolvers would use a dynamic timeout, but afaik, none do...).
Do they implement DNSSEC validation? What is their story for domains that break DNSSEC (eg: https://www.internetsociety.org/resources/deploy360/2014/cas...)?
Do they implement RFC7129 (authenticated denial of existence)? This can be used to prevent your service being used to attack an authoritative nameserver, prevents leaks of useless domains (eg machines looking up untitled.pdf as a domain), and allows you to return NXDOMAIN with much lower latency, making DNS search paths faster. RFC8020 (NXDOMAIN: There is really nothing underneath) would be another example where you can prevent leaking names, and return faster responses from a smaller cache (although I admit I've never seen anyone implement RFC8020 yet).
Will they accept (signed) responses into their cache in the additional section? Again, this can significantly reduce the time for uncached responses.
[hint: These are good reasons you should sign your domain, it can make things faster and reduce load on your authoritative nameserver!]
What is their story for domains that need a cache flush?
Do they (correctly) implement IPv6 from the recursive to the authoritative nameservers? Do they (correctly) implement IPv6 from the stub to the recursive nameserver?
How big is their cache? How long do things stay in their cache? There's no point being close to a nameserver with an empty cache. Querying www.google.com isn't really going to tell you much about their cache depth, nor is the Alexa 1M. You need a very very wide variety of names.
Do they provide good GeoIP responses? There's no point in getting an answer for the middle of the US in <1ms if you happen to be 300ms away in Asia somewhere. The DNS response was fast, but the webserver it sent you to is going to give you abysmal performance. This is often done with EDNS0-Client-Subnet, but it can also be fudged by making the outbound IPs for the iterative requests being diverse enough for different localities.
Do they "lie" about names? In what circumstances do they lie? Do they NXDOMAIN malicious domains? adult websites? ad domains? random websites? Do they redirect ad websites to their own ad farm? How do their lies handle DNSSEC?
Do they perform QNAME minimalisation to help protect your queries from servers that don't need it?
What other features do they implement to make sure their cache is never poisoned?
What is their abuse plan? If I send them a vast number of queries what happens? Do they send back TrunCated responses and force me over TCP? Will they respond with SERVFAIL? Or will they drop the queries? Or will they pass them all through to the authoritative nameservers? Do I need to do anything (other than stop sending abusive amounts of load) to be unblocked? What if the reason I'm sending a large number of queries is because I'm a carrier grade NAT IP pool and I have one broken/bad user?
What is their reliability story? Is it expected that they will go down for 10 minutes every now and again?
What do they do about general Internet Hygiene? Do they have protects against being used for reflection attacks?
Do they do preemptive lookups to keep their cache warm or is someone always guaranteed to have to wait for the full resolution? How do they make sure they don't accidentally DoS authoritative nameservers wit...
``` ;; Query time: 12 msec ;; Query time: 149 msec ;; Query time: 14 msec ;; Query time: 238 msec ;; Query time: 112 msec ;; Query time: 27 msec ```
For less popular names.
The challenge in providing a good dns service is more about having nodes closer to the user than the dns resolution step itself because that in theory is almost constant for cached responses (it's usually in the microseconds) and when it's not cached the response time is really dependent on recursive querying of other dns servers. So the dns resolution can me estimated by measuring it from a data center manually and subtracting the rtt and use that as a constant.
To estimate the rtt, you can do an xhr request and grab the connectStart and connectEnd using window.performance API keeping in mind it takes 3 rtt to do the handshake. Note that the request will fail for services that don't provide https support but that's ok because we just want to measure connect.
The reason cloudflare has a better performance is most likely because they have better coverage and not because their servers are faster. Faster servers are a small factor in the final response time.
For services that provide https support you can accurately measure the connect and response time of the XHR request using window.performance interface and subtract the dns resolution of the request. Also if you do the request twice, the second time is likely to have a dns and connect time = 0.
This allows you to get accurate timings for every resource the page loaded, including the timeline of DNS request/response for that resource.
(Please read the thread for context)
But you could build a good webpage that actually measures how well your current nameserver performs over a wide variety of different types of lookups, both warm and cold caches etc.
Which negates the purpose intended in this thread.
I get it you could sorta hack together a one-off test, but please refer to the context of this thread as mentioned previously.
https://www.opennic.org/