Domain Name Service (DNS) servers most often provide name-to-IPaddress translation to other users for one's own computers. But this isn't the only possible use of DNS servers. DNS servers can also be used to remember the answers to queries, and short-circuit future requests for the same information by responding with the remembered information. This use is usually named "caching DNS".
If there's no other alternative, every name-to-IPaddress translation request will go out over the ISP drop to domain name servers on the Internet (probably some belonging to the ISP). Although each bit of DNS traffic is pretty small, all the bits can add up until a significant amount of the ISP drop bandwidth is being used for DNS request and response traffic. If internal computers send their queries to a caching DNS server, DNS traffic over the ISP drop can be very significantly reduced. There will be more bandwidth available for actual web data, so users will get the impression web browsing is better.
Typically web browsers search for websites by name (either because the name was typed in the address bar or because a hyperlink was clicked). Until its name-to-IPaddress translation request is answered, the web browser is "stuck". If a web filter is in place, it too will request name-to-IPaddress translation of the same computer name, and it too will be "stuck" until it gets a response. If the name-to-IPaddress translation requests can be responded to a little bit quicker, both the web browser and the web filter will become "un-stuck" sooner. Users will get the impression web browsing is snappier.
It's traditional to provide DNS servers in pairs. We followed this tradition. One server is designated as the "master" and the other as the "slave". Their configurations differ slightly because of this; refer to your DNS server software documentation.
We repurposed a couple fairly old systems, added RAM to them, installed Linux, and connected a single monitor and keyboard through a KVM A/B switch. We used the standard DNS server code, specifically the rather old Bind 9.2.4, sometimes called either "bind9" or "named". The differences that make it a caching DNS server rather than the more typical DNS server are all in the configuration; we made no code nor installation changes.
Usually the configuration of a DNS server is fairly complicated. If almost everything is omitted, the default action is to act as a caching DNS. Just specify "auth-nxdomain no". You should have almost no zone definitions, and no need to do a zone transfer with any other server.
Usually because DNS is a particular target for crackers, DNS servers are placed in a Demilitarized Zone network (a DMZ is a separate network which is half-inside and half-outside, not exactly in the local network but not exactly on the Internet either). For our purpose, it's a little better to have our caching DNS servers directly connected to the local network, as then DNS traffic will not have to go through any router or firewall at all. (Besides, our DNS servers were already connected to the local network and got left that way partly out of simple inertia.)
It seems reasonably safe to place a DNS server directly on a local network so long as it does no zone transfers either in or out with any DNS server that's not also on the local network. Individual queries are less risky than transfer of all information for an entire zone. This placement isn't totally safe and will probably horrify security experts. Nevertheless it seems to be a reasonable compromise for us.
Since we already have DNS servers on our local network, mainly for caching responses, we can use them for other purposes too. By keeping all our local name-to-IPaddress and IPaddress-to-name information in our DNS, it's available anywhere on our local network without us needing to maintain any /etc/hosts files.
So we have a couple very small zones which are entirely defined in local files for our own information. We define some commonly used computers. But we specifically do not define every computer. We do not include information for computers whose addresses may change, computers whose existence we prefer to not widely publicize, or computers nobody has a legitimate reason to contact.
Most computers have places for the addresses of a couple DNS servers in their configuration. If the configuration points at the caching DNS server, queries will go there first. (A caching DNS server may either answer the query itself, or may "forward" the question to other servers.) For statically configured computers, DNS server information is generally a fairly prominent part of that configuration. For computers that get configuration via DHCP, the extensive DHCP response usually includes pointers to the initial DNS servers.
So in our environment, simply setting the addresses of our own caching DNS servers into the configuration of our DHCP takes care of most computers. We explicitly enter pointers to our own caching DNS servers into the few computers that do not use DHCP (in other words they're statically configured). A remaining problem is our gateway/firewall which connects to our ISP drop and obtains configuration information from the ISP. Where DHCP is used, the problem is this system generally points at the ISP's DNS servers rather than at our own internal caching DNS servers. The DNS configuration (probably in /etc/resolv.conf) can be manually corrected, but the DHCP client will overwrite it the next time the computer is reset. The proper solution to this problem is probably to configure the DHCP client so there is no overwriting. (What we did instead because we didn't know any better was to actually modify the code of the DHCP client script.)
Because all DNS requests initially come to our caching DNS servers, we can change the handling of them very easily without impacting any computer other than our servers. For example we've enhanced the configuration of our caching DNS servers to forward requests to OpenDNS whenever possible, and contact the general DNS hierarchy (via the DNS root servers) only when absolutely necessary. By using OpenDNS in this way, if a user misspells or otherwise garbles a website name, they don't have to wait and then get an error message. Instead, the user is presented immediately with a list of sites they may have really meant and a directory of similarly named websites.
|
Location: N42 40.86' W070 50.35'
(North America> USA> Massachusetts> Boston> North Shore> Ipswich) Time: UTC-5 (USA Eastern Time Zone) (UTC-4 summertime --"daylight savings time") Email comments to Chuck Kollars |
|
All content on this Personal Website
(including text, photographs, audio files, and any other original works),
unless otherwise noted,
are available to anyone for re-use
(reproduction, modification, derivation, distribution, etc.)
for any non-commercial
purpose under a
Creative Commons License.
|