DNS Resource Records

Records contained in the name server database files are called resource records. Each record contains information pertaining to a particular machine, such as its address, services running on the machine, and contact information. You can edit resource records to customize your configuration. Each line in a file is in resource record format. The general syntax of a resource record is:

[name] [ ttl] class type data

Resource records have the following fields:

Domain Name - This field specifies the domain name for which the resource record is defining information. Since the DNS is a distributed database, this record also defines the possible key values that may be used in DNS queries.
Time to live - This field specifies the time-to-live value that is passed out to remote DNS servers when they query the information specified by this record.
Class - This field specifies the type of network. DNS mainly uses only the "IN" or Internet class.
Record Type - This field specifies the type of information being defined with respect to the domain in field 1.

There are three main types of DNS records

A-Record. The A-Record, also called the "address record", is the most important part of the DNS record. It is used to link your domain to its corresponding IP Address.
NS Record. The NS-Record indicates the authoritative name server for that domain. If there is some question about the IP Address for a particular domain, other name servers know where to ask for a definitive answer.
MX Record. MX Records specify what servers on the Internet are responsible for handling e-mail sent to your domain. You can assign more than one server with priority rankings, so that you can still get mail if the primary server fails. Successful use of an MX Record requires cooperation with your ISP. They must properly configure the mail server to receive e-mail from your domain. If you do not have an ISP who can do this, try our e-mail forwarding service instead.

A record (address record)

The A record (address record) yields an IP address that corresponds to a host name. There can be multiple IP addresses corresponding to a single host name; there can also be multiple host names, each of which maps to the same IP address.

CNAME The CNAME (Canonical Name) record is used to define an alias host name.
MX MX records specify a list of hosts that are configured to receive mail sent to this domain name. (A host can perform MX functions for itself.)
NS Each subdomain that is a separate name server must have at least one corresponding name service (NS) record. Name servers use NS records to find each other.
PTR PTR allows special names to point to some other location in the domain. PTR records are used only in reverse (IN-ADDR . ARPA) domains. There must be exactly one PTR record for each Internet address.
SOA Start of Authority (SOA) record identifies who has authoritative responsibility for this domain.
Record Data - This field defines the appropriate data for this resource record and is dependent on the record type specified in field 4. Some record types specify a single argument in this field, other record types specify multiple arguments in this field.

Note - Depending on the record type and other shortcuts being taken, some fields are optional some of the time. Examples of such fields will be discussed in the following sections.

serial number refresh (3hrs) retry (1hr) expire (5days) ttl (1day)

Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: February 28, 2008