Install a DNS resolver on your laptop(carlos.bueno.org)
carlos.bueno.org
Install a DNS resolver on your laptop
http://carlos.bueno.org/2009/02/protip-install-dns-resolver-on-your.html
10 comments
My DSL provider is pretty good in some ways, but the DNS service has some drawbacks:
(i) It used to be ~slow~, slow enough that my broadband connection felt worse than dialup, (ii) Failed DNS queries get pointed to a server that serves up contextual ads.
The second is obnoxious when you're browsing the web, but it's completely unacceptable when you're doing projects where you expect certain DNS queries to fail.
djb's dnscache is a sweet answer to the problem.
(i) It used to be ~slow~, slow enough that my broadband connection felt worse than dialup, (ii) Failed DNS queries get pointed to a server that serves up contextual ads.
The second is obnoxious when you're browsing the web, but it's completely unacceptable when you're doing projects where you expect certain DNS queries to fail.
djb's dnscache is a sweet answer to the problem.
What's the advantage of running your own resolver over just setting your DNS servers to something like OpenDNS?
Comparable performance over time, slightly greater reliability, no reliance on a third party or exposure to whatever they do to monetize their service, and slightly less courtesy to the root server maintainers who would otherwise be shielded from your traffic.
Generally, I just use my own (co-located) DNS server from my laptop. However, I sometimes run into problems with wireless providers away from home, especially at airports: sometimes they have it set up such that you have to log in or pay at a URL that they expect the local DNS resolver (which their DHCP will have handed you) to resolve to the local server.
So, for example, foo.someprovider.net when resolved at City Airport using the local DNS server will point to an IP handling payment/login for City Airport, but the very same hostname foo.someprovider.net at OtherCity Airport will resolve to a different IP that happens to be the payment/login server on the local net at OtherCity Airport.
I've run into other instances of this. Basically, not taking the DNS server that DHCP hands you, sometimes causes problems. Usually you can figure out what's happening and change your settings, so it's an annoyance rather than a real failure.
So, for example, foo.someprovider.net when resolved at City Airport using the local DNS server will point to an IP handling payment/login for City Airport, but the very same hostname foo.someprovider.net at OtherCity Airport will resolve to a different IP that happens to be the payment/login server on the local net at OtherCity Airport.
I've run into other instances of this. Basically, not taking the DNS server that DHCP hands you, sometimes causes problems. Usually you can figure out what's happening and change your settings, so it's an annoyance rather than a real failure.
My reasons:
- Centralize DNS settings to one place for my mini-itx (that I take to coffeeshops with me and pipe through my laptop) and any VMs running on that machine or my laptop.
- Centralize ad-hoc and "rigged" hostname settings for all these things, my local /etc/hosts names are all propagated to anything using the server.
- Non multi-machine consideration: caching. There's almost zero overhead to setting up dnsmasq, may as well take advantage of a local dns cache (browser cache is only good for web browsing). I can tell the difference, especially on some networks.
- Centralize DNS settings to one place for my mini-itx (that I take to coffeeshops with me and pipe through my laptop) and any VMs running on that machine or my laptop.
- Centralize ad-hoc and "rigged" hostname settings for all these things, my local /etc/hosts names are all propagated to anything using the server.
- Non multi-machine consideration: caching. There's almost zero overhead to setting up dnsmasq, may as well take advantage of a local dns cache (browser cache is only good for web browsing). I can tell the difference, especially on some networks.
I just realized people are hung up on the resolving part of that link and not the "on laptop cache" part.
I don't think there's any compelling reason to run an actual resolver (as opposed to a local cache that recurses to a reliable, non-monetizing public cache).
I don't think there's any compelling reason to run an actual resolver (as opposed to a local cache that recurses to a reliable, non-monetizing public cache).
You get unpoisoned DNS, that's actually 'Open' and 'faster than your ISP'.
OpenDNS is neither. What's so funny about it is that it's the shit that Slashdotters rail against, successfuly marketed back to them.
OpenDNS is neither. What's so funny about it is that it's the shit that Slashdotters rail against, successfuly marketed back to them.
Well if you are an Internet user out side US and you are visiting CDN powered sites via OpenDNS, you will be redirected to US servers, which is much more slower if you use your ISP's DNS
4.2.2.1 and 4.2.2.2 have always worked great as DNS servers for me.
I've used this set of servers for years, they're the fastest I know of, period. I'll back that up with some data:
DNS Server | Comcast in Seattle | The Planet Colo in Dallas
Level3 4.2.2.X | 11ms ± 1.5ms 5hops | 1ms ± 0.2ms
OpenDNS 208.67.222.222 | 35ms - 150ms 11hops | 24.9ms ± 0.1ms
Comcast 68.87.68.162 | 90ms - 250ms 12hops | 23.4ms ± 0.1ms
There's more, 4.2.2.[1-6], these are level3's
I have no idea how they're actually load balanced but everyone always says 1 and 2 so I use the other ones.
I have no idea how they're actually load balanced but everyone always says 1 and 2 so I use the other ones.
1-3 are always golden for me, but 4-6 are hosted differently and are variable in their decency.
Holy crap. I just changed mine to 4.2.2.2 and 4.2.2.3 - my page load times seem like they have doubles. Not even joking.
Thanks for the tip.
Thanks for the tip.
This is really important, alas, you only know it when your ISP has really sucky DNS, and keeps timing out.
The other reason which you might or might not be aware of is that many CDN's use dns to map you to one of their servers, and using a resolver instead of open dns directly is the best way to go.
The other reason which you might or might not be aware of is that many CDN's use dns to map you to one of their servers, and using a resolver instead of open dns directly is the best way to go.
Ever since I switched my pfSense router machine to using OpenDNS as it's authority, rather than Time Warner's servers, I've noticed a much faster response time, especially when hitting a domain that the router has in its cache. I've never looked back, and even went as far as to set my laptop to use OpenDNS whenever I'm not at home. Couldn't be happier. :)
Yup, running your own local DNS cache is almost always better than the ISP-supplied resolvers.
Note: I used to run DJB's software a lot, back in the '90s especially, when there was no secure alternative. But nowadays there's no point in doing that. Bind has cleaned up their act, it's secure and usable enough nowadays.
Note: I used to run DJB's software a lot, back in the '90s especially, when there was no secure alternative. But nowadays there's no point in doing that. Bind has cleaned up their act, it's secure and usable enough nowadays.
And the evidence you have for this is what? 2008 was not a great year in the history of BIND security.
Another good reason: While traveling recently, several times I got to places with intentionally free wifi that failed to advertise a DNS server. If you use your own DNS server then these access points are usable.
You could also remember the IP of a usable DNS server elsewhere on the internet.
You could also remember the IP of a usable DNS server elsewhere on the internet.
4.2.2.1, 4.2.2.2
I use OpenDNS and it works well for me most of the time. I may give this a shot though in the future.
Protip: Skip configuring BIND and use UUNet's original name servers (which are blazingly fast and still maintained) because you've been staring at DNS settings for so god damn long they've been burning into your brain for the past 15 years.
Protip #2: Also learn to configure your DHCP client so this is possible.
Protip #2: Also learn to configure your DHCP client so this is possible.
That will work too. But I think it's more polite to do it the hard way. Same reason you used to set up your own time server and package server for your farm.
> More polite
No, this intuition is incorrect.
By using one of UUNet's (or someone else's) public caching name servers, you're increasing the cache diversity in a very widely used public cache and reducing the overall load on the global root name servers AND domain-level authority servers by reducing cache misses and reducing query traffic in a cumulative manner.
Think about it in terms of extremes/limits. If everyone on the internet ran their own server, would the root infrastructure slow down or speed up?
Personally I think it's somewhat insane and counterproductive to setup a DNS server on your laptop - not only are you wasting your own CPU cycles, you're wasting the CPU cycles of the root name servers and CPU cycles of the domain-level authority servers. Why do that when there are numerous public cache servers setup specifically for this very purpose?!
There's a reason those massive cache servers are accessible by the public internet. They help it work.
No, this intuition is incorrect.
By using one of UUNet's (or someone else's) public caching name servers, you're increasing the cache diversity in a very widely used public cache and reducing the overall load on the global root name servers AND domain-level authority servers by reducing cache misses and reducing query traffic in a cumulative manner.
Think about it in terms of extremes/limits. If everyone on the internet ran their own server, would the root infrastructure slow down or speed up?
Personally I think it's somewhat insane and counterproductive to setup a DNS server on your laptop - not only are you wasting your own CPU cycles, you're wasting the CPU cycles of the root name servers and CPU cycles of the domain-level authority servers. Why do that when there are numerous public cache servers setup specifically for this very purpose?!
There's a reason those massive cache servers are accessible by the public internet. They help it work.
I have some issues with this. First off, there are 13 root servers across a wide variety of networks, whereas (I checked) there are only two UUNet DNS servers, both of which are on the same network. You've just exchanged the load from 13 servers across the Inernet to two servers on a single network.
Also, there do exist DNS attacks to poison DNS resolvers, and if I suspect poisoned results, I can restart my own local DNS resolver, but I can't restart UUNet's.
There's also the issue of connectivity. There may be an issue with connectivity between your ISP and UUNet, but otherwise the rest of the Internet is accessible. If I can't get to sites, I now have to take the time to determine if it's a problem locally (ISP is down), or if there's a networking issue between me and UUNet. A locally run DNS server means I can troubleshoot that particular issue quicker.
Also, there do exist DNS attacks to poison DNS resolvers, and if I suspect poisoned results, I can restart my own local DNS resolver, but I can't restart UUNet's.
There's also the issue of connectivity. There may be an issue with connectivity between your ISP and UUNet, but otherwise the rest of the Internet is accessible. If I can't get to sites, I now have to take the time to determine if it's a problem locally (ISP is down), or if there's a networking issue between me and UUNet. A locally run DNS server means I can troubleshoot that particular issue quicker.
> only two UUNet DNS servers
I'm talking about their publicly accessible caching DNS servers, of which are there are far more than two. I'm not talking about the ones they register with the domain registrar to host their authoritative zone files. That's completely different.
> both of which are on the same network. You've just exchanged the load from 13 servers across the Inernet to two servers on a single network.
That's not how DNS works. Furthermore, that's the entire role of a cache server.
I'm talking about their publicly accessible caching DNS servers, of which are there are far more than two. I'm not talking about the ones they register with the domain registrar to host their authoritative zone files. That's completely different.
> both of which are on the same network. You've just exchanged the load from 13 servers across the Inernet to two servers on a single network.
That's not how DNS works. Furthermore, that's the entire role of a cache server.
Having a quick DHCP solution is handy because I often find myself piping my wireless net to another computer via ethernet cable. Also good for virtual machines.