Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> TCP-IP

· The Domain Name System
· Configuring the Domain Name System DNS

Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
Copyright Info
Terms of Use
Privacy Info
Masthead / Impressum
Your Account

Private Messages
Recommend Us

News Archive
Submit News
User Articles
Web Links


The Web

Who's Online
There are currently, 188 guest(s) and 1 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

Linux Tutorial - Networking - TCP-IP - The Domain Name System - Configuring the Domain Name System DNS
  The Domain Name System ---- DHCP  

Configuring the Domain Name System DNS

In the first part of this section, I discussed DNS as being a means of centrally administering the file necessary for node name to IP-address translation. Although the relationship of the files is pretty straight-forward, they are rather intimidating to the uninitiated. (Myself included)

So, what do the DNS configuration files look like? Well, since the first file that named looks at is /etc/named.conf, that seems like a good place to start. Let's assume we wanted to set up a primary name server. We might have a file that looks like this:

; Boot file for Primary Master Name Server ; ; ; type domain source file or host ; directory /etc/named.d primary siemau.com siemau.forward primary 147.142.199.in-addr.arpa siemau.rev primary 0.0.127.in-addr.arpa named.local cache . root.cache

Lines beginning with a semi-colon are considered comments and blank lines are ignored. The first line with configuration information is:

directory /etc/named.d

This tells named that if no path is specified, it should look for the other configuration files in the specified directory. In this case, /etc/named.d. Since the named.boot file is read when named starts up, you could change it to anything you want.

The first primary line says that we are the primary name server for the domain siemau.com This says that the information to resolve forward requests are found in the file siemau.forward. Okay, so what are forward requests. Well, "forward requests" is my term. I use it for two reasons. First, the file containing the information, often ends with .forward. Second, I think the primary function of a name server is to translate names to IP addresses. Therefore, this is going forward. Translating IP addresses to names is going in reverse.

Note that you will often see that the forward mapping file is referred to as named.hosts or domain_name.host and the reverse mapping as named.rev or domain_name.rev. I like to call one .forward and one .rev so I know by looking at them what their function is. It doesn't matter what you call them as long as there are pointed to in named.boot.

In order to be the primary server we must say that we are the primary. This is accomplished through the Start of Authority (SOA) record, which says we are the start of authority for the given domain. That is, when trying to find the answer to a query, the buck stops here. We have all the right answers when it comes to this domain. The SOA record is required and might look like this:

siemau.com. IN SOA siemau.siemau.com. jimmo.siemau.com. ( 8675309 ; Serial 10800 ; Refresh 800 ; Retry 3600000 ; Expire 259200 ) ; Minimum

The fields in the first line are: domain, data class, type of record, primary name server, responsible individual. The data class will always be IN for Internet. Often you will see root or postmaster as the person responsible for this domain. Here, I picked myself. Note that the format is jimmo.siemau.com and not jimmo@siemau.com as one might expect.

The Serial number is a way for secondary servers to keep track of the validity of their information. If the secondary has a serial number that is lower than the serial number on the primary, it knows that the information is outdated. It will then pull over an updated copy.

The Refresh is how often (in seconds) the secondary servers should check the primary for updated information. In every implementation I have ever seen, this value is set to 10800 seconds, or three hours. You can change it if your site requires it.

The Retry is how often (in seconds) the secondary server should retry to contact the primary. This value of 3600 seconds (one hour) is also something I have seen in almost every case. Again, change it as you need it.

The Expire time is how long the secondary will try before it gives up and declares the data it has as invalid. This is based on the attitude that no data is better than old data. Here we have 1000 hours or almost 42 days.

The Minimum is the value that other resource records should use as their time-to-live, if no other value is defined for them. The time-to-live is how long a given piece of information is considered valid.

At the end of each of these records you see a semi-colon. This is used in DNS database files as the start of a comment. Any text from the semi-colon to the end of the line is considered part of the comment. You will also see that many lines have semi-colons as their first character. In these cases, the whole line is a comment.

Note also there is a dot after each .com entry. This indicates the end of the name. Remember I mentioned that the trailing dot indicates the root domain? In these cases here, this dot is required. If you leave it off, the system will assume that it should tack on the domain name onto the end. Therefore, you might end up with the domain name twice. This behavior can actually come in handy and we'll get to it shortly.

The SOA record is just one resource record that you find in DNS database files. There are several others that we will get through during the course of this discussion. Resource records have general format:

name {ttl} data-class record-type record-specific-data

The name is simply something we are looking for. For example, we might have a machine name and we are looking for the IP address. We have the machine name, this is our value. On the far right is the record-specific-data or the IP address. The TTL value is the time-to-live. This is an optional value since we already defined a minimum in the SOA record. We could have also defined a ttl value for this SOA record, if we had wanted. The data-class can be one of several values. However, only the IN for Internet class is commonly used, therefore that is the only one we'll use here. The record-type tells us what kind of resource record we have. For example, SOA is one record type.

After the SOA record there is usually an entry saying which machines are name servers, such as:

siemau.com. IN NS siemau.siemau.com.

The value we have is siemau.com. For this record type, this value is the domain name. The domain is the same for the SOA record, as we are defining this machine to be the name server as well. The data-class, again, is IN for Internet. Since we are defining which machine is the name server, the record type is NS, for name server. Lastly, we get the FQDN of the machine (siemau.siemau.com.). Note that in both cases we had the dot at the end of each name.

One thing that I should point out here is that a good choice for which machine is the name server is one that is on multiple networks, that is one that serves as gateway. This is a good choice since it already has to know about multiple networks to be the gateway. It is said to be well connected. This saves managing one machine as the gateway and the other as the name server.

Next, we have the name to address mappings. Let's assume for simplicity's sake that I only have two other machines in my network. The entries for all my machines might look like this:

siemau.siemau.de. IN A vesta.siemau.de. IN A jmohr.siemau.de. IN A

The general format is:

machine-name data-type record-type IP-address

Note that despite the fact that siemau is our name server, we still need to include it here. Otherwise there would be no way to translate it's name to an address. The new piece of information here is the A record-type. This simply says that this specific record is making the translation from machine name to IP-address. Each entry is referred to as an address record, or address resource record. Note again the trailing dot (.).

We also need a mapping for the node "localhost". This is a special name for the local machine and is accessed using a special driver called the "loopback driver". Rather than accessing the card, the loopback driver knows that this is the local machine and does not need to go out to the network card. Certain function on the system take advantage of the capabilities of this driver.

localhost IN A

One thing I need to point out is the dot (.) at the end of each FQDN. This says that the name stops here. Remember that the dot is use to indicate the root domain. By putting the dot here, this says that we have reached the root domain, so we won't go any further.

Leaving the dot off can be a mistake or intention. In these examples it would be a mistake. In fact, in the time I was doing tech support, leaving off the dot was (perhaps) the most common mistake made when configuring the name server. However, we can leave it off intentionally in certain circumstance and have it be correct. We can use abbreviations (shorten forms) to indicate the machine name. For example, we could have written the first entry like this:

siemau IN A

Because we already defined what the domain name is in the named.boot file, the system knows what to append. Therefore, we can try to contact either siemau or siemau.siemau.de and the name server will translate that correctly to

We now need to make the translations from IP address to name. As I mentioned before, there are "reverse" translations. The data for these translations is in the file siemau.rev as indicated by the line from named.boot:

primary 42.168.192.in-addr.arpa siemau.rev

In general, the format of the entry is similar to that of the forward entries. For our three examples they would look like this: IN PTR siemau.siemau.de. IN PTR vesta.siemau.de. IN PTR jmohr.siemau.de.

There are a couple of new things here. First, is the record type. Here we have PTR for pointer records. These point to the machine name. The next is the "in-addr.arpa" after the IP address. To understand we need to take a step back.

Assume we wanted to make the translation from machine name to IP address and we had no idea where that machine was. As I mentioned there are name servers for all of the top-level domains that are aware of the name servers for all of the domains under it. For the .com domain, one such machine is kava.nisc.sri.com. So, if we had wanted to find the machine vesta.siemau.de, we could ask the name server that was responsible for the .com domain (kava.nisc.sri.com). Since kava knows about the siemau domain, and knows that siemau.siemau.de is the name server for that domain it tells you to go ask siemau yourself.

Now, let's go the other way. Question: is the domain with the first octet of the IP address 199 a .com, .edu or .gov domain? How can you tell? The answer is that there is no way to tell. IP addresses are not arrange by the type of organization. We can guess that the network 199 is probably a class C network (since it is over 192), but it can just as easily be .com a .edu or anything else. So rather than trying to find the name server for every single domain and asking "Are you the right one?", a quicker way had to be developed.

The solution was to create a portion of the Internet name space that used the addresses as a name. This portion is considered a separate domain and is referred to as the in-addr.arpa domain. The names of both machines and sub-domains within the in-addr.arpa domain are simply the IP addresses. There are 256 sub-domains of the in-addr.arpa domain, 256 sub-domains of each of those domains and so on.

If you look, the "names" listed in the in-addr.arpa domain have the IP address reversed from the way we are accustomed to seeing it. This is keeping with the idea that in the names, the more specific names are on the left and get more general as you move to the right. It also makes things easier to managed since we can say that the 42.168.192.in-addr.arpa domain is administered by one organization. (This is because 192.168.42 is a separate Class C network).

Note also that there is a dot at the end of the reverse address. Here, too, this tells the name server where the end is. Since we already said what the in-addr.arpa domain was in the named.boot file. We can make a short cut by listing only the host portion, just like we did with the FQDN. The entry for siemau would then look like this:

1 IN PTR siemau.siemau.de.

Note that here we have the dot a the end of the FQDN, but it wasn't at the end of the IP address in the address (A) record. This is because the dot comes at the end of a domain name. In in-addr.arpa notation, the IP address is part of a name, it just happens to look like an IP address, albeit a reversed one. Think of it this way, a period comes at the end of a sentence, which is a bunch of words. If you have a set of numbers, there is no period.

If we had a class B network, we could also make use of these abbreviations. For example, if siemau had an address of, it's pointer (PTR) record could have been written like this:

1.147 IN PTR siemau.siemau.de.

This reminds me of the second most common error I say in support and that is using the abbreviations for the reverse address, but not reversing them! That is, in this example above, writing it as:

147.1 IN PTR siemau.siemau.de.

Don't do that! A reverse domain has the IP address portion of the name reversed as well. No matter what part you include.

By writing the IP-Address reversed like this, we are essentially creating a new domain. The root domain, is still dot (.). However, this time there is just the single top-level domain in-addr.arpa. This notation is often referred to as the reverse domain. Because we are defining a new domain in the siemau.rev file, we need a new Start of Authority record. We could copy the SOA record from the siemau.forward file, however the domain is wrong. The domain is now 147.144.199.in-addr.arpa. So, all we need to do is replace the old domain name with the new one and the entry would be identical. The first line would then look like this:

147.144.199.in-addr.arpa. IN SOA siemau.siemau.de jimmo.siemau.de

We can now duplicate the remainder of the SOA record from the siemau.rev file. One thing I do to help keep things straight is to think of the NS record as part of the SOA record. In "reality", they separate records. However, if you think of them together, you won't forget and leave off the NS record. Since we are defining a new domain, we also need the NS record for this new domain. It's NS record would look like this:

147.144.199.in-addr.arpa. IN NS siemau.siemau.de.

However, I don't like the idea of two SOA records. There is the chance that I update the database files, but forget to update one of the SOA record with the new serial number. To eliminate that problem, there is a directive that you can give the name server to include another file while it's reading the information. This is the $INCLUDE directive. To include a single SOA record, we create a file, perhaps siemau.soa and use the $INCLUDE directive in both the siemau.forward and siemau.rev files. The line would look like this:

$INCLUDE siemau.soa

Since we already defined the directory in the named.boot file, there is no need for a path here. However, we have a problem. The SOA record in siemau.forward is for a different domain (siemau.dom) than in siemau.rev 147.144.199.in-addr.arpa). We can take advantage of a magic character: @. This will be read as the domain name, provided the domain name is same as the origin (The origin is the machine that this data is on).

Let's create a single SOA file (i.e. siemau.soa) and make it identical to other others with the exception of the domain name. Instead we replace it with the "@." Next we remove the SOA records from the siemau.forward and siemau.rev file and replace it with the $INCLUDE directive above. When the name server reads the siemau.forward file, it gets to the $INCLUDE directive sees that it needs to include the siemau.soa file. When it gets to the "@", the system translates it as siemau.de. Next, when the system reads the siemau.rev file, it sees the same directive, includes the same file, however, this time the "@" is interpreted as "147.144.199.in-addr.arpa.

There are still two lines in the named.boot file that we haven't covered. The first sets up this servers as primary for the "local" domain. This is a special domain that refers to this host only. Remember from our discussion of IP address that the IP address for the local host is The "network" that this host is on is 127.0.0. We always need to be the primary name server for this domain, there we have the line in our named.boot:

primary 0.0.127.in-addr.arpa named.local

The named.local file could contain just two lines:

$INCLUDE named.soa 1 IN PTR localhost

Note that here, too, we are including the named.soa file. When the system reads named.local, it includes named.soa and the "@" is translated to 0.0.127.in-addr.arpa as it should.

The last line tells us to read the cache file:

cache . root.cache

The root.cache file is the list of the root domain name serves. You can obtained the most current list root name servers using anonymous ftp from the machine ftp.rs.internic.net. The file is domain/named.root.

Let's assume we want vesta to be the secondary name server for this domain. We would then create a named.boot file on vesta, that might look like this:

directory /etc/named.d secondary siemau.de siemau.forward secondary 42.168.192.in-addr.arpa siemau.rev primary 0.0.127.in-addr.arpa named.local cache . root.cache

If we look carefully, we see that the only difference is the that for the forward and reverse files, we change "primary" to secondary. Note that that vesta is still the primary for the domain 0.0.127.in-addr.arpa (the local domain). The contents of the files are theoretically the same. This is where the concept of the serial number comes in. When the secondary loads it's file it compares the serial number to what it reads from the primary. Note also that the IP address,, the address of the primary server. In our case this is the machine siemau.

If we want a caching only server, the named.boot file is a little simpler:

directory /etc/named.d primary 0.0.127.in-addr.arpa named.local cache . root.cache

We still specify the directory and the root.cache file. However, we are now the primary for just a single machine, ourselves.

In any of the example named.boot files we could have include a line that simply said:


That would be a name server, regardless of what of type, that forwards all requests that it cannot satisfy to a list of predetermined forwarders. If this sever does not have the answer, it will not interact with any other server, except for those listed as forwarders. Therefore, any time you have a slave server, you must also have a list of forwarders. The entry for the forwarders might look like this:


The last kind of server I called a client. It's configuration is the simplest. You need to create a file called /etc/resolv.conf and include a line defining the domain and then a list of the name servers or resolvers as they resolve your queries. If we had siemau as the primary for this domain and vest the secondary, our file might look like this:

domain siemau.de nameserver nameserver

Note that if this file doesn't exits, your system will expect to get it's information from the /etc/hosts file. Therefore, you can say that on the client side that if /etc/resolv.conf doesn't exist, you are not using DNS.

If you have a larger network with many different departments, you might have already decided to have multiple name servers. As I mentioned, it is a good idea to have your name servers also be the gateway as they are "well connected." This also applies to the gateway you have to the Internet. To make life simpler for both you trying to reach the outside world and the people trying to get in, it is a good idea to have the Internet gateway also the primary name server for your entire domain.

If your organization is large, then having the Internet gateway a name server for your entire organization would be difficult to manage. Since you already decided to break your network down by department, then each department should have its own name server. One thing you could do is set up the domain name server as a secondary for the sub-domains. This is easy to set up (as we described above) and saves you from having to maintain a list of every machine within your organization.

There are still several record types that I haven't mentioned. One of them is machine aliasing. For example, you might have a machine that acts as your ftp server, your mail server and your World Wide Web server. Rather that requiring everyone accessing this machine to know that vesta.siemau.de is the server for all three of these functions, you can create an alias to make things easier. This is done by the CNAME (canonical name) record. Example entries would look like this:

ftp IN CNAME vesta mailserv IN CNAME vesta www IN CNAME vesta

Any reference to these three machines is translated to mean the machine vesta. Keep in mind that if you use such an alias, this should be the only reference in you name server database. You should not have PTR record that point from an IP address to one of these aliases, instead use it's canonical (real) name, vesta.

We can also use the name server database to store information about the machine itself. This is done through the HINFO (host information) resource record. We could have the entry for our machine, siemau, that looks like this:

siemau IN A IN HINFO Pentium Linux

The record specific data on the right is composed of two strings. The first is the Hardware and the second is the Operating System. The strings may contain spaces or tabs, but you need to include them within quotes or the system will seem them as separate strings. "Technically" these two strings should be "machine name" and "system name" and match one of the strings in RFC 1340, but this requirement is not enforced. There is also the problem that man newer machines won't be on the list.

One thing that seems to be missing is the machine name from the HINFO record. Well, this is another short cut. By leaving the name field out of any record, it defaults to the same value as the previous entry. Here, the previous entry is the A record for siemau. Therefore, the name field of the HINFO record is also siemau.

We can also use the name server to manage certain aspects of our users. For example, you can have mail systems (such as MMDF) read the name server information to determine what machine a particular user gets his or her mail on. This is done with the MB (mailbox) resource record. An example, might look like this:

jimmo IN MB siemau.siemau.de.

In this domain, mail for the user jimmo should be sent to the machine siemau.siemau.de. Note that this only works if you have unique users within the domain. In addition, there must only be one MB record for each user.

You can make things easier by specifying a single machine as the mail server. This is done with a MX (mail exchanger) resource record. The MX record can also be expanded to include sub-domains. For example, the name server for the siemau.de domain has MX records for all the sub-domains under it. The resource specific information contains the presence, which is a numerical value used to determined the order in which mail is sent to different machines. The preference should be 0 unless you have multiple mail servers within the domain.

Lets assume that this is a large company and we have given each department its own domain (regardless if they have different IP sub-nets). We then decide that mail sent to any one in a subdomain goes to the mail-server for that sub-domain, but any mail to the parent domain, goes to a different server. Some entries might look like this:

siemau.de. IN MX 0 siemau.siemau.de. finance.siemau.de. IN MX 0 cash.finance.siemau.de. sales.siemau.de. IN MX 0 buyer.sales.siemau.de. IN MX 1 cash.finance.siemau.de. market.siemau.de. IN MX 0 editdmon.market.siemau.de. images.market.siemau.de. IN MX 0 images.market.siemau.de.

In this example, mail sent just to a user in the domain siemau.de will go to siemau.siemau.de. Mail sent to either of the other three domains(finance, sales, and market) will be send to a machine in that respective domain. Note that there are two MX records listed for the sales.siemau.de domain. One has a preference of 0 and the other a preference of 1. Since the preference for buyer.sales.siemau.de (0) is lower than for cash.finance.siemau.de (1), the mail program will first try buyer. If buyer can't be reached it will try cash. Keep in mind that the numbers have only mean what order to check. We could have given one a preference of 45 and the other a preference of 66 and they would still have been checked in the same order.

Let's assume that we feel mail to the sales department is so important that we want it to try still another machine before it gives up. We could have a third MX record for sales.siemau.de that looks like this:

IN MX 2 siemau.siemau.de.

In this case, buyer will be checked and if the mail message cannot be delivered, cash is checked. If cash cannot be reached, siemau is checked. If we changed the preference of siemau to 1, like the preference for cash, one of them will be chosen at random. This can be used if you want to spread the load across multiple machines.

There are a few other resource records types that we haven't discussed. There are not a commonly used as the others, so we will have to forgo talking about them. If you would like to learn more, check the book DNS and BIND by Paul Albitz and Cricket Liu from O'Reilly and Associates.

As I mentioned earlier, you can use the $INCLUDE directive to include a file containing the SOA record. However, you can use the $INCLUDE directive to include any file. This is very useful if you files have grown to unmanageable sizes and you need to break them apart. Assume your network contains 200 machines. There are A, PTR and possibly MX records for each machine. You could created three separate files for each of these. ( Normally, A and PTR are in separate files already.) You could then use the $INCLUDE directive to include the MX records in one of the other files.

The Name Server

Sorry, you're going to have to do it. Unless you are a flawless typist and have every step written down exactly, one day you are going to forget something. As a result, the name server won't function the way you expect. Hopefully, it's something simple (like forgetting a dot) and you can quickly make the change.

The problem is what to do after you've made the change. Remember, named reads the configuration information when it starts. To get named to re-read the configuration file, you could stop and restart TCP. However, this would not be taken too kindly by the users who have their connection suddenly drop. The solution is to poke named in the ribs and tell it go re-read the files. This is done by sending the named process a hang-up signal with "kill -1 <pid>", where <pid> is the PID of named. To find the PID, either grep through ps -e or look in /etc/named.pid. This also has the side effect of having secondary name servers check the serial numbers, which can be used to force updates.

If you want to have named dump its current database and cache you can send named a interrupt signal (SIGINT, kill -2). This dumps the database into /usr/tmp/named_dump.db. Sending named SIGUSR1 (kill -16) you can turn on debugging, the output which is sent to /usr/tmp/named.run. Subsequent SIGUSR1 signals sent to named will increase the debugging a level. Sending it SIGUSR2 (kill -17) turns off debugging completely.

You can also get named to trace all incoming queries, which is sent to /usr/adm/syslog. This is done by sending SIGWINCH (kill -20). Be careful with this, however. Even on smaller networks, the amount of information logged in syslog can be fairly substantial. If you forget to turn it of, you can fill up your root file system. To turn of tracing, send SIGWINCH again. Note that all of theses options can be enabled from the start-up script in /etc/rc2.d.

Perhaps the most useful debugging tools is nslookup (name server lookup). The nslookup command can be used either interactively or non-interactively, to obtain information from different servers. Depending on how it's set, you can input an IP address and get a name back or input the name and get the IP address back. If you are using the name server, either as a server or a client, nslookup can be used to gather information.

To start it interactively, simply type nslookup at the command line. You are then brought into the nslookup "shell," where you can issue commands and set the options needed to get the information you need. By using 'set all' you can view the current options. By default, nslookup will return the IP address of the input machine name (A forward query). For example, if we ran nslookup on vesta, nslookup would respond with something like this:

Default Server: siemau.siemau.de Address: >

This tells us what the default server is and shows that it is ready for the first command by displaying the > prompt.

Let's say we wanted to see what information the name server when we run nslookup on siemau. We type in jmohr and press return. This gives us:

> siemau Server: localhost Address: Name: siemau.siemau.de Address:
As we can see this is what we expect. Note that in the first case, the default server was siemau. However, when we run it on the name server itself, the server is "localhost."

One question that comes to my mind is does it translate the IP address back to the host name correctly? Let's see. When we type in the IP address, we get:

> Server: localhost Address: Name: vesta.siemau.de Address:

We can list all the available information for a domain with the 'ls' command. The general syntax is:

ls [ option ] domain

Where domain is the name of the domain we would like the information about. If we want we can redirect the output to a file, we can use either type of output redirection (> or >>). If we want to see it on the screen, we get:

> set all Default Server: localhost Address: Set options: nodebug defname search recurse nod2 novc noignoretc port=53 querytype=A class=IN timeout=5 retry=2 root=f.root-servers.net. domain=siemau.de srchlist=siemau.de

If I want to see everything there is about a domain. I use the ls command. Keep in mind that by itself, the system will think it is a machine name and try to resolve it. However, followed by the domain name we get:

> ls siemau.de [localhost] siemau.de. server = siemau.siemau.de siemau jmohr localhost vesta

However, this does not tells us anything about the mail exchanger or canonical names that we may have defined. To get everything, we us the -d option like this:

> ls -d siemau.de [localhost] siemau.de. SOA siemau.siemau.de jimmo.siemau.de. (60001 1080 0 1800 3600000 86400) siemau.de. NS siemau.siemau.de siemau.de. MX 0 vesta.siemau.de jimmo MB siemau.siemau.de siemau A jmohr A siemau HINFO Pentium Linux localhost A www CNAME vesta.siemau.de mailserv CNAME vesta.siemau.de ftp CNAME vesta.siemau.de vesta A

As we can see, this gives us everything we can thing about including mail boxes, HINFO lines, canonical names, the SOA records and all of the address records. Note that there is only one MB record here. In reality, I probably would have had MB records for all the users on this system. If this network had been even a little larger, then this output would probably be too much to view. Therefore you can use other options to limit what you see. For example, the -t option is used to specify a type of query. If we wanted to look for all the mail exchangers, we could use the command "ls -t MX siemau.de," which gives us:

siemau.de. 0 vesta.siemau.de

Which give us the domain, the preference of the mail-exchanger and the name of the mail exchanger. Which is all the information in the MX record.

We can also tell nslookup that we want to look for particular kind of records. Say I want to look for the MX record for a particular machine. I could set the query type to MX and look for that machine, like this:

> set type=MX > siemau.siemau.de Server: localhost Address: siemau.siemau.de preference = 0, mail exchanger = vesta.siemau.de siemau.siemau.de internet address =

Okay. This says that the mail exchanger for siemau is vesta. Are you sure? What nslookup is actually telling us is that vesta.siemau.de is the mail-exchanger for siemau.siemau.de. Why? Because we didn't put the dot at the end of the domain name. Like other aspects of the name server, nslookup tacked the domain name onto the end of siemau.siemau.de to give us siemau.siemau.de. If I just use a machine name, the domain name is tacked on as well, but it comes out differently:

> siemau Server: localhost Address: siemau.siemau.de preference = 0, mail exchanger = siemau.siemau.de siemau.siemau.de internet address =

The nslookup program also has a configuration file that can come in handy. This is the .nslookuprc file in your home directory. Like the .exrc file for vi, the .nslookuprc is read every time you start nslookup. The format is also like .exrc, with one entry per line. Assuming I wanted to set the query time to PTR records and set the time out to 5 seconds, I could have these two lines in my .nslookuprc file, like this:

This would be the same as starting nslookup from the command line like this:

Setting parameters is not the only thing that you can do from the command line. In fact, most anything you can do from inside of nslookup, you can do from the command. I could expand the above command to give me:

nslookup -query=ptr -timeout=5 Server: localhost Address: Name: vesta.siemau.de Address:

So what is this all good for? The most important thing is tracking down problems you might be experiencing. For example, if a particular machine cannot reached, nslookup might show you that there is no A record for that machine. Perhaps mail to a particular machine never ends up where it should. Checking the MX record for that machine indicates it ends up going to a completely different machine than you though.

Unfortunately, I cannot list every problem that could arise and what nslookup would show. However, with the understanding of how DNS and nslookup work that you've gained in the last couple of sections, the best way to proceed is to look at what nslookup is telling you. Based on the way you think DNS is configured, is what nslookup records correct? This may sound like an over simplification. However, isn't that what problem solving really is? Knowing what should happen and what would cause it to happen differently?

Your Own IP Address

If you have a network that is completely disconnected from the rest of the world, then there is no need for you to adhere to any of these conventions. You might be a commercial organization, but still want to use the EDU domain. Nothing prevents you. There is also nothing preventing you from using IP addresses that are used by some other organization. However, once you decide to connect to another organization or the Internet at large, you need to ensure that both your names and IP address are unique.

If you would like to have one machine that connects to the internet, but have other machines that cannot. One solution is to use one of the IP address defined in RFC 1918. This RFC describes the need for "private" address and lists a range of class A, B and C addresses that can be used internally within a company.

Some routers will filter out this addresses automatically, other require that they be so configured. This allows you to not only limit access to and from the internet, but also limits the need for unique addresses. If you only have a handful of machines that need Internet access, some internet providers will sub-net a Class C address and assign you a small block of addresses. See the RFC for more details.

In many cases, you Internet Service Provider (ISP) can apply for an IP address for you. Also, the ISP could provide you with a single IP address that is actually part of their network. Internally, you then use a private network as defined in RFC 1918. In other cases, when you have a dial-up connection to your ISP you may have a dynamically assigned address, so it isn't always the same.

File Function
/bin/netstat Show network status.
/bin/hostname Delivers name of current host.
/bin/ping Sends ICMP ECHO_REQUEST packets to network hosts.
/etc/dig Send domain name query packets to name servers.
/etc/ftpaccess FTP access configuration file
/etc/ftphosts FTP individual host access file
/etc/ftpusers List of users automatically denied FTP access
/etc/gated gateway routing daemon.
/etc/hosts list of hosts on network.
/etc/hosts.equiv list of trusted hosts.
/etc/http/conf/* HTTP configuration files
/etc/inetd.conf Inetd configuration file.
/etc/named.boot Name server configuration file
/etc/netconfig Configure networking products.
/etc/networks List of known networks.
/etc/protocols List of Internet protocols.
/etc/services List of network services provided.
/etc/tcpd Access control daemon for Internet services.
/sbin/bin/arp Delivers ARP information.
/sbin/ifconfig configure network interface parameters.
/usr/bin/finger Find information about users.
/usr/bin/ftp Network file transfer program.
/usr/bin/logger Make entries in the system log.
/usr/bin/nslookup Query name servers interactively.
/usr/bin/rdate Notify time server that date has changed.
/usr/bin/rdist Remote file distribution program.
/usr/bin/rlogin Remote login program.
/usr/bin/route Manually manipulate routing tables.
/usr/bin/rwho Who is logged in on local network.
/usr/bin/talk Talk to another user.
/usr/bin/telnet Telnet remote login program
/usr/sbin/ftpshut Shutdown ftp services
/usr/sbin/httpd HTTP Daemon
/usr/sbin/inetd Internet 'super-server'
/usr/sbin/routed Network routing daemon.
/usr/sbin/in.ftpd FTP daemon
/usr/sbin/in.rlogind Remote login (rlogin) daemon
/usr/sbin/in.rshd Remote shell (rsh) daemon
/usr/sbin/in.telnetq Telnet Daemon
/usr/sbin/in.tftpd Trivial FTP (TFTP) Daemon
/usr/sbin/in.fingerd finger daemon
/usr/sbin/traceroute Trace packet routeis to remote machines.

Table - Network commands

 Previous Page
The Domain Name System
  Back to Top
Table of Contents
Next Page 


Test Your Knowledge

User Comments:

You can only add comments if you are logged in.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.
Show your Support for the Linux Tutorial

Purchase one of the products from our new online shop. For each product you purchase, the Linux Tutorial gets a portion of the proceeds to help keep us going.



Security Code
Security Code
Type Security Code

Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!

Amazon Wish List

Did You Know?
You can choose larger fonts by selecting a different themes.


Tell a Friend About Us

Bookmark and Share

Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 1.07 Seconds