A Brief History of BIND

We have established already that BIND can provide name service for your network, allowing you to enter a host name rather than an IP when connecting to another computer on the network. However, we did not address how BIND, and DNS in general, works on the Internet at large. DNS on the Internet is really a multi-tiered system, wherein clients make queries of local name servers that serve a tiny fraction of the clients found on the Internet, usually on a single subnet. These local name servers then act as clients of somewhat larger name servers, which in turn act as clients for name servers above even them. At some point in this hierarchy the server will be one of the ROOT, or top-level domain, name servers, which will know what other lower-name server to query regarding the requested name. Each name server in the chain will likely save the results of the query, or cache the result, so will have no need to go all the way up the chain the next time the same query is made. Shockingly, perhaps, this system works quite well and has scaled as the Internet has grown from a few thousand hosts to hundreds of millions.

Walking Through an Example Query

When you open your favorite browser and enter a request for a web page - for example, http://www.swelltech.com - quite a lot goes on behind the scenes before the browser can even begin to load data from the server. First, the URL you entered must be parsed and interpreted by the browser. But we don't care about that step. Next, the domain and host name where the data is located must be found on the Internet. The name, www.swelltech.com, tells the browser very little about the physical or network location of the data, so it queries a tool that can make some sense out of that information: the DNS server.

The DNS server receives the request and checks its internal cache for the host named www, in the second level domain swelltech, in the top-level domain (aka TLD) com. If the DNS server does not have this information cached, it becomes a client and asks its parent name server the same question: 'What is the IP for the host www.swelltech.com?' Eventually, assuming no lower-level name servers have information about this host, a top-level domain name server (in this case, the one for the com TLD) will receive the query. The difference here is that the top-level domain name server knows the address of the name server that is responsible for that domain name, or at least the next level down, swelltech. Finally, the name server for the swelltech.com domain is queried, and the IP for the host www is returned. As mentioned earlier this data will then be cached by each name server in the query path so that next time, they won't have to work so hard to answer the request.