> 220.127.116.11 abbreviates to 1.1, so you can literally test by typing "ping 1.1"
I recently switched my home network DNS forwarder from Bind to DNS Crypt Proxy (https://github.com/jedisct1/dnscrypt-proxy). You can get ad/content filtering lists along with some little privacy enhancements like DNS Crypt and DNS over HTTPS support for encrypted DNS queries to supported services, like CloudFlare.
Having traffic analysis in your threat model is an extreme choice, typically it means your adversaries include law enforcement agencies or state-level actors. Sending DNS over VPN might just mean that you don’t trust your ISP and think they might intercept the request and forge a response—something which does happen, and I’ve personally observed it at two different ISPs.
My ISP probably forges responses because they have no problem injecting html/js and hijacking ad space on unencrypted connections.
As far as timing attacks, an example would be such: Even though you are at a coffee shop in an undisclosed location miles away from home, if LE has a reason to profile the IP you're broadcasting from at home they could do look at request times and try to link a request from the coffee shop to your home DNS server.
If you use a public DNS server, you have the same benefit of using a public VPN vs a private VPN, in that your traffic gets bundled with everyone else's and obfuscated. It's harder to establish a link between you and the DNS server using network analysis because potentially thousands of connections are being made to that same DNS server from the same VPN node at the same time.
This is wrong, you should not expect political dissidents, whistleblowers, and other people in the same category to use similar techniques to protect themselves.
If you are protecting yourself from different threats, then it is not unreasonable to use different methods to protect yourself. There is an inherent tradeoff between security and usability. If law enforcement or state-level actors are in your threat model, you're going to have to make some extreme usability sacrifices just to keep yourself safe. That means using different systems than other people use.
> Even though you are at a coffee shop in an undisclosed location miles away from home, if LE has a reason to profile the IP you're broadcasting from at home they could do look at request times and try to link a request from the coffee shop to your home DNS server.
You're describing a different system. The system described by kingo555 is just for home.
> As far as timing attacks, an example would be such: Even though you are at a coffee shop in an undisclosed location miles away from home, if LE has a reason to profile the IP you're broadcasting from at home they could do look at request times and try to link a request from the coffee shop to your home DNS server.
That's just traffic analysis. The term "timing attack" refers to something else.
If you're a political dissident, whistleblower, or someone else with law enforcement / state-level actors in your threat model, everything changes. Presumably if you are worried about law enforcement, you put the VPN endpoint outside their jurisdiction. This can make it extremely difficult to do traffic analysis, depending on who your adversary is.
I think it makes sense that not everyone has law enforcement and state-level actors in their threat model.
I don't know how you can say I'm wrong when I was making the general conjecture that people in these categories use privacy-enhancing systems. I don't think you understood me well. I was not specifically referring to any particular set of techniques or systems.
> You're describing a different system. The system described by kingo555 is just for home.
This system is not meant to be used when roaming? Or is this a use case?
> The term "timing attack" refers to something else.
Which is why I specifically listed both timing attacks and traffic analysis separately. They can be interrelated at times but that's not something I feel like discussing.
> If you're a political dissident, whistleblower, or someone else with law enforcement / state-level actors in your threat model, everything changes. Presumably if you are worried about law enforcement, you put the VPN endpoint outside their jurisdiction. This can make it extremely difficult to do traffic analysis, depending on who your adversary is.
I appreciate the lesson in OPSEC but I only asked a simple question and you've devolved into trying to tear apart my comment for errors and lecturing me about things I already know about instead of simply answering the question. In this case, the answer is apparently "Well, your question isn't really relevant because this system is just meant for home use." One helpful sentence, no assumptions and no negativity.
> I think it makes sense that not everyone has law enforcement and state-level actors in their threat model.
Cool. No one was saying anything to the contrary.
kingo555 described a home network, but I don't think it matters. kingo555's threat model doesn't appear to consider traffic analysis, excluding it from the threat model, and that's a very reasonable choice. The system doesn't make any timing attacks easier.
> In this case, the answer is apparently "Well, your question isn't really relevant because this system is just meant for home use." One helpful sentence, no assumptions and no negativity.
I thought that was what I did here: https://news.ycombinator.com/item?id=19095304 But I was wrong, and sometimes it takes an entire conversation to discover the differences in assumptions and definitions.
For a full local resolver, you can configure it to use and serve expired records, with a 0 TTL. In the background it will then lookup all records used, so that it's refreshed for next time. Cloudflare does this. Likewise, you can configure it to prefetch frequently requested records before they expire.
I find it's still best to defer to an upstream forward server vs. root resolution. Most of the providers mentioned have multiple points of presence and will likely be closer and resolve MUCH faster for most cases. DNS resolution time can be a huge factor in web responsiveness.
Also, as counterintuitive as it might seem, when I use namebench ( https://code.google.com/archive/p/namebench/ ) it still says cloudflare and google are faster than my local resolver. (not by a lot though)
In my experience, Google's DNS has so many servers that even on subsequent requests, you hit a different server and it has to do the full lookup again (likely querying a root unless it's a popular domain). It's not really decreasing the load on the root servers that much, if at all. It might actually increase the load.
One trick you can do to speed up your local recursive resolver is allowing it to serve expired records. Unbound in pfsense allows for this. If the record has been previously retrieved but is expired, it returns the record with a 0 TTL (to force the client to look it up again next time). This includes internally using expired NS records, for example to lookup a different subdomain. Meanwhile, in the background, it looks up all the records used to refresh the TTL, and serves/uses this next time. Generally speaking, expired records still work fine. I noticed that Cloudflare DNS does this as well, and regularly serves 0 TTL records.
I've found that this consistently makes my local resolver faster than any public DNS server, except sometimes the very first time it looks up a domain. The slowest DNS queries are records which use lots of nested CNAMES on different domains with short TTLs, such as www.microsoft.com / most sites using akamai, which takes 500ms for the first lookup. There was a domain I saw the other day which had 4 or 5 layers of CNAMES which took 1-1.5 seconds to resolve initially.
But this isn't a problem... DNS caching works very well. I've been running my own nameservers for over two decades.
No, you don't, that's the whole point of a recursive resolver. I've been running against the root servers and neither query statistics nor observed performance match frequent issues due to short TTLs, or excessive number of external queries.
* Pi-hole®: A black hole for Internet advertisements – curl -sSL https://install.pi-hole.net | bash || https://pi-hole.net/
"On November 15, 2018, Norton ConnectSafe service is being retired or discontinued meaning the service will no longer be available or supported. You may continue to use ConnectSafe until November 15, 2018. However, we do recommend that you take a moment to review important details related to this announcement below."
I am actually surprised he didn't mention CleanBrowsing in their list, which I would recommend as good alternative to Norton and OpenDNS.
I configured DNScrypt on Tomato and I also use Tomato to redirect all DNS requests so it can't be bypassed by simply re-pointing DNS. VPN obviously bypasses it.
Legalese is very hard to learn language. Do they keep aggregate data, derived from those raw logs? It is not said. Trusting Cloudflare? It is a profit driven company, to start with ...
When we talk about aggregate data it's things like total number of queries made to 18.104.22.168, number made by AS, and geographic region. Its purpose is only to show us if people are using 22.214.171.124 and how that changes over time.
Pinging DNS servers is a shitty inconclusive test for internet connectivity, or SLA measurements etc etc.
So it is not smart to make a lot of decisions based on “ping 1.1” timing out, it is so quick it’s a good first step in trying to debug a network issue.
I've never observed this in any version of Windows nor Linux.
I believe this is because you need root privileges/special capabilities to send ICMP packets.
>They are not maintained as ICMP test servers, and that is not their purpose.
>While many do not block ICMP packets, there are typically rate limiting systems in place, and other reasons why they would not respond to ping requests.
126.96.36.199 and 188.8.131.52 and all the major ones don't care.
Pinging DNS servers is highly productive and easy. There is nothing bad with using them as internet connectivity tests or SLA measurements.
At a minimum, any node on the internet routing or serving traffic needs to keep ICMP open. If you're running a DNS server, ICMP should be working.
TL;DR: At the risk of repeating myself: Google Public DNS is a Domain Name System service, not an ICMP network testing service.
Public DNS resolvers: https://www.dnsperf.com/#!dns-resolvers
DNS services for your own domain: https://www.dnsperf.com/
I disagree with the speed part, because cloudflare doesn't support EDNS. This is great for privacy but not for speed.
Here is proof: https://pastebin.com/raw/QnbWXU1a
If he meant speed in the DNS resolution context, I somewhat agree with him.
I haven't done local benchmarking using a tool like namebench for a long time, and it looks like that tool has not been updated for several years. Any alternatives for it that are cross platform?
In fairness, the DNS protocol that it's testing hasn't really changed in that time either. namebench is still sufficient for general testing.
Hotels and ISPs sometimes set up captive portals that intercept and redirect port 53 to their own choice of DNS servers.
As such, users might want memorise the addresses of some resolvers that listen on non-standard ports (not port 53).
A user behind one of these captive portals who pings any of the resolvers in this blog post will not be pinging those servers; she will be pinging the hotel/ISP's chosen DNS servers and she may be none the wiser.
Actually, no. Even if one does accept the premise that one should use these third-party non-contracted services, challenged elsewhere in this very discussion, there's no reason that one need have these things memorized. Written in a handy pocketbook, perhaps. But not necessarily memorized.
What’s nice about pi-hole is that you get one request to sites like google.com until the record expires in the cache. If you use 184.108.40.206 as your dns you might end up requesting the same domain name a bunch of times depending on how your client caches and the caching is at 220.127.116.11. So dns will see lots of requests to the same domain.
Although this doesn’t count on-client caching, it still seems to back up your guess and my original comment.
Yeah, this sounds totally legit...
Can you elaborate? Neither Google nor CloudFlare seem to collect information for profiling.
Cloudflare does not store any information, but they are pretty frank about passing it on to APNIC for "research" as part of the deal where APNIC lend the 18.104.22.168 and 22.214.171.124 address to them. This is pretty well established and actually openly communicated by both entities, so should be easy to DDG.
You are of course free to believe that this data is totally anonymized and not used for profiling / targeting at all, but imo that is pretty naive.
For the record, we don't build any sort of profile of DNS queryiers, map them back to any existing profile we have, or even keep the data you would need to have to do that.
If the data sent to APNIC is so safe and non-personal, why not make it transparent?
Instead, when contacting APNIC about it, you get a typical one liner stating that
> ... the access to the primary data feed will be strictly limited to the researchers in APNIC Labs, and we will naturally abide by APNIC's non-disclosure policies.
Clearly, someone thinks there is something to hide. Maybe not Cloudflare, but then it's someone else.
I'm not with CF or APNIC, but it's likely due to issues with sensitive data.
Say a web service is hitting `http://internal.example.com:5220` with basic authentication, or there's a misconfigured jira trying to access `internal.example.com:3306`, but the DNS admins have retired `internal.example.com` and decided to make it return `126.96.36.199` for some reason. Showing all traffic that hits the service would expose a little too much sensitive information.
In addition, if "internal.example.com" is not already resolvable publicly (which would mean that it's known) CF could not guarantee the privacy of that query anyways because their DNS is not part of the root zone, which means they need to forward it to someplace beyond their control, meaning they leak it no matter what.