D. J. Bernstein
Internet publication
djbdns

Costs and benefits of third-party DNS service

Most administrators keep all their DNS servers on their own networks, under their own control. If those networks go down, the underlying computers aren't accessible; the inaccessibility of the names is a relatively minor problem.

A few examples: AOL's DNS servers are dns-{01,02,06,07}.ns.aol.com, all of which are on AOL's networks. Harvard's DNS servers are ns{1,2}.harvard.edu, both of which are on the Harvard network. CERT's DNS servers are cert.org and tictac.cert.org, both of which are on the CERT network.

Some companies make money providing third-party DNS service. These companies claim that third-party DNS service provides huge benefits. The purpose of this web page is to analyze the actual costs and benefits of third-party DNS service.

The bottom line is that, for the vast majority of sites, third-party DNS service has serious costs and negligible benefits, just like third-party HTTP service and third-party SMTP service. The service companies' claims are wildly exaggerated, and should never be used as a substitute for common sense.

Costs of adding a third-party DNS server

The basic problem with third-party DNS service is that administrators need to go out of their way to set it up. They need to locate a suitable third party, to arrange zone transfers, and to track changes in the name or IP address of the third-party server. Third-party DNS service also makes it difficult to arrange for fast propagation of an urgent change.

Third-party DNS service occasionally creates small delays for users. If the original network is up while the third-party network is down, and a user's cache tries to reach the third-party server first, it won't contact the self-managed servers for a few seconds. These delays would not have happened without the third-party server.

Third-party DNS service occasionally creates large delays for users. When the original network is down, a user's browser will spend time on a useless connection attempt. Without the third-party server, the user has a chance of receiving an immediate response, because some DNS caches will remember that the self-managed servers are unreachable. Connection failures are much less likely to be cached than DNS failures. (RFC 2182 claims that DNS failures are not cached; that claim is false.)

Third-party DNS service creates a small amount of extra Internet traffic: first, the traffic required for third-party zone transfers and SOA requests; second, when the original network is down, several TCP SYN packets for each connection attempt that would have been skipped if DNS service had been unavailable.

Third-party DNS service adds reliability risks. For example, some servers are running DNS software that can corrupt zone files, producing incorrect data for a large fraction of users, if the power suddenly goes out. Extra servers mean extra chances for disaster.

Third-party DNS service adds security risks. For example, on 2000-02-14, www.rsa.com was misdirected by an attacker who, apparently, broke into a third-party server. Breaking into the rsa.com self-managed servers would have been considerably more difficult. Breaking the DNS protocol would have been somewhat more difficult and would have affected a relatively small number of clients.

Benefits of adding a third-party DNS server

If the self-managed servers are providing names for external computers on other networks, and if the networks for the self-managed servers are down, then a third-party server on another network gives external users another chance of reaching those external computers. For example, *.uk computers are on many different networks, but the .uk manager appears to have only one network, and that network occasionally goes down. Third-party .uk servers reduce the frequency of *.uk connection failures.

Third-party DNS service occasionally eliminates large delays for users. Without a third-party server, if a user attempts to connect to a misspelled name while the original network is down, the user will have to wait for a DNS timeout. With a third-party server, the user will receive an immediate error message.

Third-party DNS service eliminates a small amount of Internet traffic: specifically, when the original network is down, several DNS packets for each uncached DNS lookup attempt.

Erroneous arguments for third-party DNS service

Proponents of third-party DNS service use two tactics to make third-party DNS service sound better than it actually is.

The first tactic is to describe every increase in DNS availability as Good and every decrease as Bad, without regard to the actual costs and benefits. Examples:

``It is important that there be nameservers able to be queried, available always, for all forward zones.''
``Placing all DNS servers at the local site, while easy to arrange, and easy to manage, is not a good policy. Such a configuration can lead to all servers being disconnected from the Internet.''
``If you have an extended outage, SMTP clients will be persistently unable to reach your DNS servers, mail will start bouncing, and you'll lose customers.''

Third-party DNS service doesn't stop the mail from bouncing: during an extended outage, the SMTP servers aren't reachable either! Companies that need extremely high availability replicate all their services across several networks: they run multiple SMTP servers, multiple HTTP servers, multiple DNS servers, etc.

The second tactic is to claim that widespread DNS clients will do something Particularly Evil when they are unable to reach all DNS servers. The problem with this argument is that the claim is false. Any such client is clearly buggy, and will be unable to survive in the marketplace: consider what happens if the client's routers briefly go down, or if the client's network is temporarily flooded. Examples:

``Third-party DNS means the difference between email being requeued and email bouncing.'' No, it doesn't. Mail transfer agents defer delivery attempts when DNS servers are unreachable, just as they defer delivery attempts when SMTP servers are unreachable.
``My DNS-surveying software won't include your computers if your DNS servers are momentarily cut off from the Internet.'' That software will also produce incorrect results if its own network is momentarily cut off from the Internet. In contrast, a thorough survey will determine which failures are persistent by retrying its queries appropriately.
``Clients react differently to inability to resolve than inability to connect, and reactions to the former are not always as desirable.'' This vague claim appears without justification in RFC 2182.