Web Security, Privacy and Commerce, 2nd Edition

18.2 Protecting Your DNS

All of the redundancy in the world won't keep your web site accessible on the Internet if potential users type in your domain name and it isn't properly translated to the IP address of your servers. Having a Domain Name Server (DNS) that is reliable and accurate is a prerequisite for a reliable web site. Nevertheless, DNS issues are commonly overlooked by many organizations.

There are many reasons DNS does not get the attention it deserves:

• Managers and executives do not understand what DNS does, how it works, and why it is important.

• Because DNS normally functions rapidly and reliably, DNS breakdowns are all the more confusing, unfamiliar, and difficult to diagnose.

• As most ISPs do not explicitly charge for providing DNS service, many users conclude that it must either be simple to provide or not be worth very much.

As we discussed in Chapter 2, DNS is a large distributed database that translates hostnames (e.g., www.vineyard.net) into IP addresses (e.g., 204.17.195.100.) When DNS is functioning properly, incoming queries to your nameserver are rapidly replied to with the IP address of your service. Responses contain an assortment of information and an expiration time, better known as a time to live (TTL). DNS answers are designed to be cached: if a thousand customers of Earthlink in San Jose all try to access your web site one afternoon, chances are good that your DNS server will see only a single query from Earthlink; the remaining 999 users get their answer from Earthlink's DNS server, which holds onto the information until the TTL expires.

There are many ways DNS can fail. Some of them are catastrophic for example, your DNS server may have crashed, preventing anybody on the Internet from looking up your IP address. But some DNS failure modes are not so obvious: your DNS server may report that it is nonauthoritative, preventing your secondary DNS servers from properly updating their databases and causing them to distribute obsolete or false information.

There are several reasons DNS issues can be exceedingly difficult to diagnose:

• Many of the Internet's diagnostic tools (ping, traceroute, nslookup, whois, etc.) depend on DNS.

• Even if your DNS server is down, your secondary DNS servers may continue to answer DNS queries for a time. Thus, your DNS outage may begin hours, days, or even weeks after the primary DNS server fails.

• Different DNS implementations deal with errors in different ways. For example, some DNS implementations attempt to make the best of zone files that contain errors, while other DNS implementations reject them outright.

DNS is also becoming dramatically more complicated. As this book went to press, the Internet Software Consortium's BIND DNS server consisted of more than 100,000 lines of C source code that compiled to more than 500,000 bytes of object code. DNS now has provisions for dynamic updating and cryptographic security. Because the DNS protocol runs on port 53, the DNS server must be started by the superuser on Unix systems.

Most implementations of DNS now allow for remote updates. You should be certain that remote updates on your server are explicitly turned off unless you specifically wish to use this feature. If you do wish to use remote updates or dynamic DNS, be sure that update requests are authenticated using the appropriate cryptographic protocol. Do not depend upon IP addresses for authentication, as IP addresses can be spoofed.

Perhaps because of its complexity, BIND has also been the source of several remote exploits. Although the problems in BIND have been rapidly fixed, the widespread use of this software combined with the fact that many system operators do not even know that it is running on their systems have allowed the vulnerabilities to persist for a long time. If you run DNS, you should be certain that you are either running the most recent version of the program or running a version so old that nobody knows about its security vulnerabilities anymore (not a gamble that most people want to take). Running a version of BIND that is a year or two out of date is not sound practice.

If possible, you should dedicate a separate computer to DNS service. If this is not possible, you should see if your DNS server can be installed in a "chrooted" environment, or run as a user other than root.