DNS, or the Domain Name System, is absolutely vital to the functioning of the internet. In fact, though you rarely interact directly with the DNS the internet as we know it could not exist without its constant presence. DNS associates, or binds, hostnames and domain names to IP addresses and thus allows you to type http://www.swelltech.com instead of the much less memorable IP 206.245.168.212. Further, it makes it possible for mail servers to easily locate the correct host to send mail to for a given domain, the correct administrative contact when strange things are originating from the domain, and more. But for our purposes, as ordinary system administrators, all we need to really keep in mind is that BIND is our method of providing DNS information for our network. It will provide information to our local users, when their client applications need to access various sites by name. And it will provide information to clients (primarily other DNS servers acting as DNS clients in order to fetch the correct information for their clients) on the internet at large in order to advertise to the world how hostnames on our network can be reached. Think of it as a fancy telephone book, or even better a telephone operator, for networked computers. The computer has a name, but needs the number. So it contacts the DNS server and asks for the number, and BIND is happy to do its best to return the correct number.
Every host on a TCP/IP network has an IP address. This address must be unique for the network on which the address is routable. So, every host that is accessible via the internet has a unique IP address that may, theoretically, be reached from anywhere else on the internet. Because these addresses are doled out, roughly, according to location on the network, and because routers keep up with which other routers have access to which subnets, this simple number is all that is needed for your computer to establish a connection with any other computer on the internet in seconds. Unfortunately the topic of routing on the internet falls quite outside of the scope of this document, as Webmin is not designed to manage routers or the more complex routing features of Linux, FreeBSD, and the other OS's that are supported.
We have established already that BIND can provide name service for your network, allowing you to enter a hostname 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 nameservers that serve a tiny fraction of the clients found on the internet, usually on a single subnet. These local nameservers then act as clients of somewhat larger name servers, which in turn act as clients for nameservers above even them. At some point in this hierarchy the server will be one of the ROOT, or top level domain, nameservers, which will know what other lower nameserver 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.
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 hostname 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.
So 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 nameserver the same question: "What is the IP for the host www.swelltech.com?" Eventually, assuming no lower level nameservers have information about this host, a Top Level Domain nameserver (in this case, the one for the com TLD will receive the query. The difference here is that the Top Level Domain nameserver knows the address of the nameserver that is responsible for that domain name, or at least the next level down, swelltech. Finally, the nameserver 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 nameserver in the query path so that next time, they won't have to work so hard to answer the request.