QuantumNet,
You make some good points, but I believe you miss a few relevant issues.
If you really want to use OpenDNS isntead of your upstream's nameservers, then you should use DNS the way it was designed, and use your local resolv.conf file to direct queries, and not forwarders.
Craig Hunt, author of
Linux DNS Server Administration published by Sybex, points out:
The purpose of creating a forwarders list is twofold. First, because the forwarders handle so many queries, they develop a rich cache of answers. Many queries are rapidly answered from the forwarders' cache once this rich cache develops.
Second, using forwarders can reduce traffic over the wide area network. The forwarders are generally located within the organization's private network or local area network.
Craig's point about the rich cache is well-taken, but if you don't mind the time spent in actually communicating with OpenDNS servers, you'd probably be better served by putting the code into your resolv.conf file; where no time would be wasted first querying your own server at all. His second point of course is simply untrue in your scenario of using forwarders to a distant server on the Internet.
I've made some tests. From my office it takes over twice as long to get a response from OpenDNS's nameserver than from my connectivity provider's nameserver:
Code:
[jlasman@of1 ~]$ ping 206.13.29.12 # my upstream nameserver
PING 206.13.29.12 (206.13.29.12) 56(84) bytes of data.
64 bytes from 206.13.29.12: icmp_seq=1 ttl=249 time=13.7 ms
64 bytes from 206.13.29.12: icmp_seq=2 ttl=249 time=13.2 ms
--- 206.13.29.12 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 13.211/13.467/13.723/0.256 ms
[B][jlasman@of1 ~]$ping 208.67.222.222 # OpenDNS nameserver
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
64 bytes from 208.67.222.222: icmp_seq=1 ttl=52 time=28.7 ms
64 bytes from 208.67.222.222: icmp_seq=2 ttl=52 time=28.5 ms
--- 208.67.222.222 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 28.525/28.623/28.721/0.098 ms
[jlasman@of1 ~]$
At my data center the difference is orders of magnitude:
Code:
[jlasman@da12 ~]$ ping 67.30.130.157 # my upstream nameserver
PING 67.30.130.157 (67.30.130.157) 56(84) bytes of data.
64 bytes from 67.30.130.157: icmp_seq=0 ttl=63 time=0.411 ms
64 bytes from 67.30.130.157: icmp_seq=1 ttl=63 time=0.434 ms
--- 67.30.130.157 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.411/0.422/0.434/0.023 ms, pipe 2
[jlasman@da12 ~]$ ping 208.67.222.222 # OpenDNS nameserver
PING 208.67.222.222 (208.67.222.222) 56(84) bytes of data.
64 bytes from 208.67.222.222: icmp_seq=0 ttl=57 time=31.7 ms
64 bytes from 208.67.222.222: icmp_seq=1 ttl=57 time=29.3 ms
--- 208.67.222.222 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 29.379/30.572/31.765/1.193 ms, pipe 2
[jlasman@da12 ~]$
You wrote:
1) Go sign up for an OpenDNS account, this is very important because you need to edit OpenDNS configuration and turn off all their features such as typo correction which can cause problems for your dns server. ( you can disable these features for your IP blocks ).
Yes the default feature set can easily break your DNS in ways most of us would never imagine, mostly because OpenDNS was designed to be used by local networks for decisions as to what traffic to allow in; not where to send traffic. Yes you can change the default settings now, but you cannot guard against future changes to OpenDNS. Since you're advocating it's use for purposes never thought of, there's probably going to be a point in the future when they add another
feature that completely breaks your system. For example, by default they automatically resolve all domains, whether they really resolve or not.
You also wrote:
2) Open up /etc/named.conf
and add these lines within the options block:
recursion no;
fetch-glue no;
forwarders { 208.67.222.222; 208.67.220.220; put.your.datacenter.dns.server.ip.here; };
Then restart named.
Because these are going to be public facing nameservers we want recursion turned off and since we are not going to be doing recursion there is no need to fetch the glue either
Why are you using forwarders here? Why not use the
resolv.conf file for the purpose it was designed for?
According to Hunt (citation above):
The purpose of creating a forwarders list is twofold. First, because the forwarders handle so many queries, they develop a rich cache of answers. Many queries are rapidly answered from the forwarders' cache once this rich cache develops.
Second, using forwarders can reduce traffic over the wide area network. The forwarders are generally located within the organization's private network or local area network.
Craig's point about the rich cache is well-taken, but if you don't mind the time spent in actually communicating with a distant server or servers, you'd be better served by putting the code into your resolv.conf file, where no time would be wasted first querying your own server at all. His second point of course is simply untrue in your scenario of using forwarders to a distant server on the Internet.
You also wrote:
1) Go sign up for an OpenDNS account, this is very important because you need to edit OpenDNS configuration and turn off all their features such as typo correction which can cause problems for your dns server. ( you can disable these features for your IP blocks ).
Yes the default feature set can easily break your DNS in ways most of us would never imagine, mostly because OpenDNS was designed to be used by local networks for decisions as to what traffic to allow in; not where to send traffic. Yes you can change the default settings now, but you cannot guard against future changes to OpenDNS. Since you're advocating it's use for purposes never thought of, there's probably going to be a point in the future when they add another
feature that completely breaks your system. For example, by default they automatically resolve all domains, whether they really resolve or not.
2) Open up /etc/named.conf
and add these lines within the options block:
recursion no;
fetch-glue no;
forwarders { 208.67.222.222; 208.67.220.220; put.your.datacenter.dns.server.ip.here; };
Then restart named.
Because these are going to be public facing nameservers we want recursion turned off and since we are not going to be doing recursion there is no need to fetch the glue either
Why are you using forwarders here? Why not use the
resolv.conf file for the purpose it was designed for?
According to Craig Hunt (
Linux DNS Server Administration, Sybex):
The purpose of creating a forwarders list is twofold. First, because the forwarders handle so many queries, they develop a rich cache of answers. Many queries are rapidly answered from the forwarders' cache once this rich cache develops.
Second, using forwarders can reduce traffic over the wide area network. The forwarders are generally located within the organization's private network or local area network.
Craig's point about the rich cache is well-taken, but if you don't mind the time spent in actually communicating with OpenDNS servers, you'd probably be better served by putting the code into your resolv.conf file; where no time would be wasted first querying your own server at all. His second point of course is simply untrue in your scenario of using forwarders to a distant server on the Internet.
Now some of you would say oh but we can add an acl to allow for local recursion only, I have seen your examples there is no need for acl's to accomplish that allow-recursion {ipaddresses}; within your options block would work. THIS IS HIGHLY RECOMMENDED AGAINST!
Mark Andrews of ISC, who's considered authoritative on BIND configuration, doesn't say to not use allow-recursion(look
here), and while he also points out that there is a way to avoid cache-viewing by those not allowed to use recursion directly. In
this post) he writes:
9.4.0 has allow-query cache. Prior to 9.4 you need to set allow-query on each zone if you don't want the cache visible and still leave the zones visible.
I agree with you that it's a bad idea for reasons you don't note:
The only reason you'd use allow-recursion would be if you were going to use your local nameserver for lookups for domains for which it lists itself as authoritative. This is NOT a good idea in a webhosting environment. Here's why:
You automatically set up authoritative DNS zones for every domain you host, but you really don't know, or control, whether or not your hosting client uses your nameserver(s). If your client is using his own, or some other nameserver, you really don't know if the one you've set up automatically actually reflects his domain or not. If you query your nameserver first, you have no idea if you're actually looking at his zone, or just looking at what your server is serving as his zone.
You also wrote:
The only reason we add the other 3 nameservers to this resolv.conf file is in case your local dns server is stopped or errors out, this way we know we always have a proper route to domain resolution.
For reasons explained above you'd be better off using your upstream's nameservers in your resolv.conf file, exactly as you do with your connection at home for your desktop system.
For those of us who don't have an on-network nameserver supplied by our upstream connectivity provider, I suppose OpenDNS is an option (after remembering to change the defaults). For the rest of us, it's probably not faster, and usually slower, than using our provider's recursive server for our lookups, using
recursiion no in our named.conf file, and leaving localhost completely out of our resolv.conf file.
Jeff
