|
|
ActiveSocket Network Communication Toolkit by ActiveXperts Software - HTTP, HTTPs, FTP, ICMP, SNMP Get/GetNext/Set, SNMP Traps, NTP, RSH, Telnet and more
|
Visit ActiveSocket Web Site
Download ActiveSocket Network Communication Toolkit
DNS explained
DNS always seems to be popping its head up when you try to do something on the Internet. That's fine if you understand it, but if you don't, what are you supposed to do? The answer to that question is "read this article!" This little piece is here to provide you with a basic understanding of DNS, what it does and how it does it -- at least enough of how that you'll be able to use it for your needs.
If you were to write Jenny a letter, put it in an envelope marked "Jenny", stamp and mail it, the chances of Jenny getting it are virtually nil. This is because there is no address for the Post Office to know where it should be delivered. Associate an address with the name "Jenny" by writing it on the envelope, and they'll carry it right to her (probably! ) The purpose of DNS, the Domain Naming System, is to associate an address with a name.
Every computer or device connected to the computer has an address. They are usually written in the form of four numbers separated by dots, as in: 192.168.0.1 These addresses are used by the routers on the Internet to send information from one place to another. They provide the destination address for each little packet of information sent. How that works doesn't really matter to us for now; it only matters that it works!
You're already familiar with internet names like www.mydomain.com but may not have been aware that the construction of this name depends on DNS. The three components of this name, separated by dots, are called the Hostname (www), the Domain Name (mydomain) and the Top Level Domain (com). The actually are used from right to left in resolving (as the translation of a name to a number is called) the name.
The Top Level Domain points to a root database. When you register a domain name, you are actually adding a name to a root database (actually, your registrar adds it for you -- a registrar is an organization that has been authorized to make changes to the root databases). There is a root database for each Top Level Domain (TLD). New TLDs are introduced only when a new root database is created. This doesn't happen very often and its a pretty big deal when it does. When the name is added to the root database, it is associated with DNS servers that will hold the domain's detail information. The first DNS sever is the Primary DNS server for the domain, the others (there is always at least one more, but there can be several) are called secondary DNS servers.
The process of resolving a domain name into an address starts by making an inquiry into the root database to locate the domain's DNS servers. This enables an inquiry into these servers to find the address associated with the Hostname. The actual mechanism doesn't really matter for our purposes here either; it is more important to gain an understanding of the concept for now.
Taking a look at the records that are held in these DNS servers can reveal the concept of the resolving process clearly enough. The manner in which these records are held can vary from one DNS server to another, depending on the particular DNS software it is running, but the basic nature of the records is the same. To illustrate the function of the most common records, I'll provide a sample DNS record file. If you were to create an entry for a domain in a DNS server, you would need to create these records. Note, however, that many web based interfaces to domain record files automatically generate some of these records. If you are going to use such an interface, it may not provide mechanisms for you to create those records. That simply makes your life a little easier. Here is the sample domain file:
$ORIGIN mydomain.com.
@ IN SOA dns1.mydomain.com. hostmaster.mydomain.com.
( 20030915001 ; serial
172800 ; refresh
3600 ; retry
1728000 ; expire
172800 ; minimum )
IN NS dns1.mydomain.com.
IN NS dns2.mydomain.com.
IN A 192.168.251.10
IN MX 5 mail.mydomain.com
localhost IN A 127.0.0.1
mail IN A 192.168.251.5
imapmail IN CNAME imap.mydomain2.com.
offsite.mydomain.com. IN A 192.168.200.33
www.mydomain.com. IN A 192.168.251.10
www.mydomain.com. IN MX 10 webmail.mydomain2.com.
$ORIGIN subdomain.mydomain.com.
www IN A 192.168.251.100
The first few lines pertain to the domain itself, and may begin with a $ORIGIN record. The $ORIGIN simply provides a name to be appended to each name in the file that does not end with a period. For example, "mail", above, doesn't end with a period and so will be taken as "mail.mydomain.com"; "offsite.mydomain.com." does end in a period and so is taken as is (forget the period and it will be "mail.mydomain.com.mydomain.com" which is probably not what you wanted!)
Next we have a "Start Of Authority", SOA, record. There are several interesting items in this record, only a couple of which we're concerned with here. First there's the name of the machine on which this file was created, followed by the name of the responsible person in "dotted email address" form (replace the first dot with an @ sign). These are meant for documentation and don't affect the way DNS works. Next, enclosed in parentheses, are some parameters and their values. "Serial" is a serial number that is incremented each time a change is made to the file, and indicates the version level of this file to the DNS system. I like to use the date followed by a two-digit counter, like in this example, because it's easy to maintain and adds to my documentation. The rest of these parameters do some pretty interesting things, but are beyond our scope here. For now, you can use the above values - they're fairly standard.
Next we have some NS records. These state which Name Servers there are for this domain. Note that the "name" on each of these records (the first entry) is null, but since it does not end in a period it has the "mydomain.com" suffix added to it. Alternatively, we could specify "mydomain.com." (with the period).
Now we have an "A" address record for the name "localhost". "A" records specify the IP address for a host. This record specifies the loopback address 127.0.0.1, which is what you would expect for "localhost"! This is followed by an address record specifying that there is a machine called mail.mydomain.com at 192.168.251.5, which, for the sake of this example, is an address on our local network. To show that the address can be anywhere on the internet, the "A" record for "offsite" points to a machine in a different network. Assuming that 192.168.251 is our class C network address, "www" then points to host address 10 on our network. This is (presumably) the address to which all http transactions will be sent.
Going back to those skipped records, note that the null named address record points to host address 10. The effect of this is that if somebody uses "http://mydomain.com" omitting the "www" it will still go to the same machine.
The other record we skipped is the MX, or Mail exchanger (email server), record. This one has a null name and so pertains to mail sent to mydomain.com, as in [email protected]. There is a number right after the MX. This is the priority of this record. The lower the number, the higher the priority, so that if there are two or more records that would apply to a given name, the lowest number would be tried first. Usually, in smaller networks, there's only the one mail server anyway. A little further down in our file there's an MX record for the host "www". This one will send any mail to [email protected] to the machine webmail.mydomain2.com. As you can see, the email server can be on this or any other network. In these examples the mail server machines are specified by name but could be specified by number. Personally, I prefer to use the name so that if I move or renumber a server I only have to change the "A" record that specifies its address and all other references will resolve to the new number.
In the middle of our file we have a "CNAME" record. This is used to define an alias. CNAME actually stands for "Canonical Name" (yawn) but I like to think it stands for "See Name" since it defines an alias! Our CNAME defines the name "imapmail" within mydomain.com and points it at a host called "imap" in the domain "mydomain2.com". Again, the target machine could be anywhere on the Internet.
At the bottom of our sample file I have shown an example of using $ORIGIN to create a subdomain. Here there is only one host defined in the subdomain. Its full name is www.subdomain.mydomain.com and it has an address that is still within our class C network. Once again, however, the target address could be anywhere on the Internet.
"Subdomain" in this sense is an organization of names etc, as opposed to a subnet in IP addressing, which has physical implications.
To summarize the purpose of these records:
- To define a domain, use an SOA record with one or more NS records.
- To define a host (a machine or a name) use an A record.
- To send mail somewhere use an MX record.
- To define an alias use a CNAME record.
- Use $ORIGIN to define the suffix to be appended to names being defined or referenced, and to define subnets.
Remember that DNS is used to resolve a name to an address, and the address can be anywhere on the Internet.
|
|