81–90 of 95 posts
Earlier quoted context omitted.
Even with DNS/HTTPS and such, wouldn't using a home DNS resolver with a VPN on both ends of the connection still make you a little more vulnerable to network analysis and timing attacks since your DNS requests are guaranteed to go through a specific IP which only serves you?
I have to go around my VPN provider for DNS because they intercept and alter DNS requests.
DNS servers should not be used as "internet connectivity tests" by pinging them. 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. Pinging DNS servers is a shitty inconclusive test for internet connectivity, or SLA measurements etc etc.
Not true.
>They are not maintained as ICMP test servers, and that is not their purpose.
Irrelevant.
>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.
8.8.8.8 and 1.1.1.1 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.
Earlier quoted context omitted.
Only non-cached requests go to a third party. And I don’t think there’s an easy way to prevent this unless you get a hold of all the zone files and copy in bulk. 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 8.8.8.8 as your dns you might end up requesting the same domain name a bunch of times depending on how your client caches and the…
In a network of just a few computers, are there really that many cached requests? Local DNS caches will already cache short term and TTL of most domains is probably too short to get much caching beyond that.
Although this doesn’t count on-client caching, it still seems to back up your guess and my original comment.
His blog post pays no mention of users whose DNS queries are being redirected. Isn't that a privacy concern? 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 a hotel I always first thing direct everything through a VPN server (work or home, depending on what I want to do). Some hotels block UDP, in that case I switch the VPN to go via TCP port 443. But some hotels (really!) block port 443.. fortunately not that many anymore.
Earlier quoted context omitted.
That's great and all, but you still need to pick an upstream DNS server. The conventional advice is to use one of these public services, or your ISP's resolvers, to avoid hitting the root servers constantly. A lot of services these days have very short TTLs, so running your own recursive resolver still causes a lot of requests to get forwarded. Also, as counterintuitive as it might seem, when I use namebench ( https:…
> That's great and all, but you still need to pick an upstream DNS server. 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.
Earlier quoted context omitted.
That's great and all, but you still need to pick an upstream DNS server. The conventional advice is to use one of these public services, or your ISP's resolvers, to avoid hitting the root servers constantly. A lot of services these days have very short TTLs, so running your own recursive resolver still causes a lot of requests to get forwarded. Also, as counterintuitive as it might seem, when I use namebench ( https:…
You actually don't have to. The TTLs on NS records are generally pretty long, especially the root servers (6 days for root, 2 days for both .com and my domain's NS). You will hit the .com for example the first time you go to a domain, but so does Google. 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 queryi…
Earlier quoted context omitted.
That's great and all, but you still need to pick an upstream DNS server. The conventional advice is to use one of these public services, or your ISP's resolvers, to avoid hitting the root servers constantly. A lot of services these days have very short TTLs, so running your own recursive resolver still causes a lot of requests to get forwarded. Also, as counterintuitive as it might seem, when I use namebench ( https:…
> That's great and all, but you still need to pick an upstream DNS server. 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.
Earlier quoted context omitted.
You actually don't have to. The TTLs on NS records are generally pretty long, especially the root servers (6 days for root, 2 days for both .com and my domain's NS). You will hit the .com for example the first time you go to a domain, but so does Google. 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 queryi…
I know all that. IMHO in that configuration the root servers are your upstream servers. That’s what I was trying to convey. And serving expired records does generally work, but is not suggested practice.
But this isn't a problem... DNS caching works very well. I've been running my own nameservers for over two decades.
Earlier quoted context omitted.
In a hotel I always first thing direct everything through a VPN server (work or home, depending on what I want to do). Some hotels block UDP, in that case I switch the VPN to go via TCP port 443. But some hotels (really!) block port 443.. fortunately not that many anymore.
When you use a home VPN server, is the VPN server running on a computer located at your home and reachable on the open internet? If yes, do you have fixed address or do you use dynamic DNS?
DNS servers should not be used as "internet connectivity tests" by pinging them. 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. Pinging DNS servers is a shitty inconclusive test for internet connectivity, or SLA measurements etc etc.
I've used the thing [0] from grc.com, is there other ways that are reliable as well? https://www.grc.com/dns/benchmark.htm