DNS Resolution Revealed

I know, I know. I can already hear some of you saying: “Why would I care about DNS resolution?” Well, the answer is quite simple: If your web browser can’t find a web site that you know is there, or have ever looked at your web reports where a users IP address was irresolvable then you will want to know a little about DNS.

And don’t think that this only applies to web reports! DNS applies in one-way or another to all Internet applications, including, but not limited to (I have always wanted to say that): browsers, FTP clients, email utilities, network utilities etcâÂ?¦ ad nauseum. Also, I am not kidding when I say you will want to know a little about DNS. If you ever have to refer to the RFC’s for DNS resolution, you will thank me for this little review, as sparse as this is.

“What the heck is an RFC,” you ask? An RFC stands for “Request For Comments.” This is a group of documents that define the protocols and policies of the Internet. If you are really want to learn more about DNS than you ever wanted to, you could look up the RFC’s recommended at the end of this article. Additionally you might want to get your hands on “DNS and BIND” from O’Reilly Bookstores.

WHAT IS DNS?

In a nutshell: The Internet’s infrastructure consists of a distributed system of name servers. Special machines, running special software all over the place on the web. Each Domain Name Server records some information about the domain names used on the Internet, and is capable of querying other name servers for information it does not have. When a web server needs to map a domain name to an IP address, it always asks its local name server first, which may in turn query other name servers until it finds the name that corresponds to the IP. This process is three layers process, which is to say that the server will contact up to three servers before giving up, and this is plenty to get a name for an IP address.

WHY CAN’T MY REPORTING SOFTWARE OR BROWSER RESOLVE THE DNS?

We’ll begin with the obvious, and move up to the more complex issues as we go:

1. Are you connected to the network? You have to be able to contact the DNS server defined in your Network Properties. If you are accessing the web from home, make sure you have your modem connection� which brings us the next item:

2. Is there a DNS server defined in your TCP/IP configuration? Most software that does DNS lookups utilize the DNS server defined in your Network Properties to make the queries.

3. Firewalls: This is usually a problem within a corporate environment or intranet. Port 53 UDP must be open on the firewall in order for most programs using NSLOOKUP to work.

4. It’s possible (but not likely) that the DNS server administrator did not set up delegation to the in-addr.arpa subdomain that corresponds to your network IP range. If your network is defined by the following class C: 255.255.255, you should have the NIC delegate 255.255.255.in-addr.arpa to your domain.

DNS CACHING

Domain Name Servers are caching information they get from other servers DNS queries. The records are stored in the name server memory. The cache is lost when the name server process is stopped or restarted.

Each Domain Name Server record contains a time to live (TTL) value that tells the server how long name servers may cache that particular name record. Usually, the value is something like 86400 seconds� if you are really sharp, or have no life, you will realize that this is 24 hours.

If a DNS server is particularly busy, the cache will expand beyond your wildest imagination: It is possible (even likely) that the server will be receiving more records than it expires. On UNIX systems, when the cache reaches a predefined limit, the kernel will kill the process (which is not particularly good). That is why most UNIX servers have a cron job running that restarts the server every so often.

MX RECORDS

A MX record is what tells the DNS server where you want your mail to go. It is a simple redirect. You can also use it to redirect mail from one domain to another. The DNS MUST resolve going both ways for email to work properly.

For example, let’s say that the people in your company are complaining that the email they are sending their customers are not being received. The first step in your troubleshooting process should be to send yourself an email. If that works, then taking a look at the MX record is one of the primary things you will want to check. For this example, we will use the domain name “mydomain.com”

Go to a command prompt. (Start- Programs-Command Prompt).

Type NSLOOKUP and click “enter.”

Type “set type=MX” – This tells the DNS servers that you want to look at the Mail Exchange record, which is used for sending and receiving email. Click “enter.”

Type “mydomain.com.”

If the DNS server replies with “can’t find mydomain.com: Non-existent domain,” congratulations – you just found the problem.

If there IS a record present, the DNS record will return something like this:

C:\>nslookup

Default Server: mycomputer.somedomain.com

Address: 255.255.255.255

> set type=MX

> mydomain.com

> server: [255.255.255.255]

> Address: 255.255.255.255

Non-authoritative answer:

Mydomain.com MX preference = 10, mail exchanger = mail.mydomain.com

Mail.mydomain.com internet address – 256.256.256.256

“Non-authoritative answer” is the DNS server’s way of saying that the information is correct as of the last time it was cached.

The second line shows the domain name you queried, “mydomain.com” followed by “MX preference = 10” – This sets up a priority in mail servers. If this domain has two or three mail servers as backups, there would be a line for each mail server, with a different priority level. Mail will be delivered to the server with the lowest priority first, and if that server is down, it will be delivered to the next mail serverâÂ?¦ but I digress.

The MX preference is followed by the machine name. So, the mail server for mydomain.com lives on a box called “MAIL.”

AHA! Now, you know you have to check the preferences in your software to make sure it is pointing to the right SMTP server! But this does not mean all your problems are over� oh, no� a domain name (especially for mail) must be able to resolve back to itself.

Note that the next line shows the mail server with the IP address after it. Now, type in the IP address. For our example, it is “256.256.256.256” – Click “enter.”

If NSLOOKUP states that “can’t find 256.256.256.256 – Non-existent domain” then guess what? You have just found your problem. Contact your system administrator and let him or her know that the mail server machine name does not resolve back to the IP.

HOW CAN I GET EVERY DOMAIN NAME THAT IS REGISTERED WITH INTERNIC?

Well, you can’t. You used to be able to, but no more. Network Solutions, who has gathered the data, wants to be able to sell the list of most US domains (“.net” “.com” etcâÂ?¦). You can still get the “.edu” and “.gov” domains by clicking on this link ftp://ftp.rs.internic.net/domain

You want more on DNS than what you see here? Check out this very informative site:

http://www.dns.net

Some General DNS RFCs

RFC 920 Domain Requirements by J. Postel and J. Reynolds

RFC 974 Mail Routing and the Domain

RFC 1032 Domain Administrator’s

RFC 1122 Requirements for Internet Hosts

RFC 1123 Requirements for Internet Hosts

RFC 1178 Choosing a Name for Your

RFC 1183 New DNS RR

RFC 1480 The US Domain

RFC 1536 Common DNS Implementation Errors and Suggested

RFC 821 Simple Mail Transfer Protocol

RFC 974 Mail routing and the domain system

RFC 1090 SMTP on X.25

RFC 1711 Classifications in E-mail Routing

RFC 1664 Using the Internet DNS to Distribute RFC1327 Mail Address Mapping Tables