The most commonly used record types are: A, CNAME, MX, NS, PTR and
SOA.
The A-record is the most basic and the most important DNS record
type.
They are used to translate human friendly domain names such as "www.jhsoft.com" into IP-addresses such as 23.211.43.53 (machine friendly numbers).
A-records are the DNS server equivalent of the hosts file - a simple domain name to IP-address mapping.
A-records are not required for all computers, but is needed for any computer that shares resources on a network.
This record type is defined in RFC1035.
Often computers on the Internet have multiple functions such as web-server, ftp-server, chat-server etc.
To mask this, CNAME-records can be used to give a single computer multiple
names (aliases).
For example computer "xyz.com" may be both a web-server and an ftp-server,
so two CNAME-records are defined:
"www.xyz.com" = "xyz.com" and "ftp.xyz.com" = "xyz.com".
Sometimes a single server computer hosts many different domain names
(take ISPs), and so CNAME-records may be defined such as "www.abc.com"
=
"www.xyz.com".
The most popular use the CNAME-record type is to provide access to a
web-server using both the standard "www.domain.com" and "domain.com" (without
the
www).
This is usually done by creating an A-record for the short name (without
www), and a CNAME-record for the www name pointing to the short name.
CNAME-records can also be used when a computer or service needs to be renamed, to temporarily allow access through both the old and new name.
A CNAME-record should always point to an A-record to avoid circular references.
This record type is defined in RFC1035.
When sending an e-mail to "user@xyz.com", your mail server must first
look up the MX-record for "xyz.com" to see which mail server actually handles
mail for
"xyz.com" (this could be "mail.xyz.com" - or someone else's mail server
like "mail.isp.com").
Then it looks up the A-record for the mail server to connect to its
IP-address.
An MX-record has a "Preference" number indicating the order in which
the mail server should be used.
(Only relevant when multiple MX-records are defined for the same domain
name).
Mail servers will attempt to deliver mail to the server with the lowest
preference number first, and if unsuccessful continue with the next lowest
and so on.
An MX-record identifies the name of a mail server server - not the IP-address.
Because of this, it is important that an A-record for the referenced
mail server exists (not necessarily on your server, but wherever it belongs),
otherwise there may
not be any way to find that mail server and communicate with it.
Do not point an MX record to a CNAME-record. Many e-mail servers don't handle this. Add another A-record instead.
This record type is defined in RFC1035.
A zone should contain one NS-record for each of its own DNS servers
(primary and secondaries).
This mostly is used for zone transfer purposes (notify).
These NS-records have the same name as the zone in which they are located.
But the most important function of the NS-record is delegation.
Delegation means that part of a domain is delegated to other DNS servers.
For example all ".com" sub-names (such as "jhsoft.com") are delegated
from the "com" zone (hosted by the "InterNic").
The "com" zone contains NS-records for all ".com" sub-names (a lot!).
You can also delegate sub-names of your own domain name (such as "subname.yourname.com")
to other DNS servers.
You are in effect the "InterNic" for all sub-names of your own domain
name (if you have a really cool domain name, you might even be able to
sell sub-names for
profit).
To delegate "subname.yourname.com", create NS-records for "subname.yourname.com"
in the "yourname.com" zone.
These NS-records must point to the DNS server responsible for "subname.yourname.com"
for example "ns1.subname.yourname.com" - or a DNS server
somewhere else like "ns1.othername.net".
An NS-record identifies the name of a DNS server - not the IP-address.
Because of this, it is important that an A-record for the referenced
DNS server exists (not necessarily on your server, but wherever it belongs),
otherwise there may
not be any way to find that DNS server and communicate with it.
If an NS-record delegates a sub-name ("subname.yourname.com") to a DNS
server with a name in that sub-name ("ns1.subname.yourname.com"), an A-record
for
that server (""ns1.subname.yourname.com") must exist in the parent
zone ("yourname.com").
This A-record is referred to as a "glue" record, because it doesn't
really belong in the parent zone, but is necessary to locate the DNS server
for the delegated
sub-name.
This record type is defined in RFC1035.
A PTR-record's name is the IP address written in backward order with
"in-addr.arpa." appended to the end.
As an example, looking up the domain name for IP address "1.2.3.4"
is done through a query for the PTR-record for "4.3.2.1.in-addr.arpa."
This record type is defined in RFC1035.
The domain name of the primary DNS server for the zone.
The zone should contain a matching NS-record.
The email address (replace @ with a dot) of the person responsible for maintenance of the zone.
The standard for this is the "hostmaster" username - such as "hostmaster.jhsoft.com" (= hostmaster@jhsoft.com).
Used by secondary DNS servers to check if the zone has changed.
If the serial number is higher than what the secondary server has, a zone transfer will be initiated.
How often secondary DNS servers should check if changes are made to the zone.
How often secondary DNS server should retry checking if changes are made - if the first refresh fails.
How long the zone will be valid after a refresh.
Secondary servers will discard the zone if no refresh could be made within this interval.
Used as the default TTL for new records created within the zone.
Also used by other DNS server to cache negative responses (such as record does not exist etc.).
This record type is defined in RFC1035.
IPv6 is the future replacement for the current IP address system
(also known as IPv4).
The current IPv4 addresses are 32 bits long ( x . x . x . x = 4 bytes),
and therefore "only" support a total of 4,294,967,296 addresses - less
than the global
population.
With this limitation there is an increasing shortage of IPv4 addresses.
To solve the problem, the whole Internet will eventually be migrated
to IPv6.
IPv6 addresses are 128 bits long and and are written in hexadecimal
numbers separated by colons (:) at every four digits.
Zeros can be skipped - for example: 4C2F::1:2:3:4:567:89AB.
Few applications and network devices currently support IPv6 and IPv6 addresses are not yet generally available., but this is expected to change rapidly.
An A6-record is used to specify the IPv6 address (or part of the IPv6 address) for a host.
A6-records expands the functionality of A- and AAAA-records by adding
support for aggregation and renumbering.
A lookup for an IPv6 records could involve several A6-records which
each specify only part of the final address.
This is achieved through the additional prefix-length and prefix name
fields.
A6-records are supposed to replace AAAA-records (see below).
This record type is defined in RFC2874.
An AAAA-record specifies an absolute IPv6 address.
This record type is supposed to be replaced by the A6 record type (see above).
This record type is defined in RFC1886.
An AFSDB-record maps a domain name to an AFS (Andrew File System)
database server.
The server name points to an A-record for the database server, and the
sub-type indicates server type:
1 = AFS version 3.0 volume location server for the named AFS cell.
2 = DCE authenticated server.
This record type is defined in RFC1183.
An ATMA-record maps a domain name to an ATM address.
The ATM address can be specified in either E.164 format (decimal) or NSAP format (hexadecimal).
This record type is defined in "ATM Name System Specification Version
1.0" published by the ATM Forum.
A DNAME-record is used to map / rename an entire subtree of the
DNS name space to another domain.
It differs from the CNAME-record which maps only a single node of the
name space.
This record type is defined in RFC2672.
A HINFO-record specifies the host / server's type of CPU and operating
system.
This information can be used by application protocols such as FTP, which
use special procedures when communicating with computers of a known CPU
and
operating system type.
Standard CPU and operating system types are defined in RFC1700 (Page 206 / 214).
The standard for a Windows PC is "INTEL-386" / "WIN32".
This record type is defined in RFC1035.
The ISDN-record maps a domain name to an ISDN (Integrated Services
Digital Network) telephone number.
The ISDN phone numbers / DDI (Direct Dial In) used should follow ITU-T
E.163/E.164 international telephone numbering standards.
For example 12121234567 ( 1=USA, 212=New York area code, 1234567=number)
The ISDN sub-address is an optional hexadecimal number.
This record type is defined in RFC1183.
Most Internet mail servers only support MX-records.
Only use MB, MG, MINFO and MR records if you have specific requirements
for these.
To specify "mailbox" names, replace the email address @ sign with a
dot (.).
Maps a mailbox to a host (server).
The host must be the same as a valid A-record already defined in the
same zone.
Used to specify mail group members (one MG-record per member).
Each member mailbox must be identical to a valid mailbox (MB-record).
Specifies the mailbox of the responsible person and optionally a
mailbox for errors for this mailbox or list.
Each mailbox must be the same as a valid mailbox (MB-record) that already
exist in the zone.
Specifies a renamed mailbox.
An MR-record can be used as a forwarding entry for a user who has moved
to a different mailbox.
These record types are defined in RFC1035.
An NSAP-record maps a domain name to an NSAP address.
The NSAP address is entered using hexadecimal digits - any NSAP address format is allowed.
This record type is defined in RFC1706.
An RP-record specifies the mailbox of the person responsible for
the host (domain name).
A SOA-record defines the responsible person for an entire zone, but
a zone may contain a large number of individual hosts / domain names for
which different
people are assigned responsibility.
The RP-record type makes it possible to identify the responsible person
for individual domain names contained within the zone.
To specify the "mailbox", replace the email address @ sign with a dot (.).
Optionally specify the domain name for a TXT-record with additional information (such as phone and address).
This record type is defined in RFC1183.
An RT-record specifies an intermediate host that provides routing
to the domain name (host) of the record.
This can be used by computers which are not directly connected to the Internet, or wide area network (WAN).
A preference value is used to set priority if multiple intermediate
routing hosts are specified - lower values tried first.
For each intermediate host specified, a corresponding host (A) address
resource record is needed in the current zone.
This record type is defined in RFC1183.
SRV-records are used to specify the location of a service.
They are recently being used in connection with different directory
servers such as LDAP (Lightweight Directory Access Protocol), and
Windows 2000 directory
services.
They can also be used for advanced load balancing and to specify specific
ports for services - for example that a web-server is running on port 8080
instead of the
usual port 80.
This record type is however still considered experimental, and is NOT supported by most programs in use today, including web-browsers.
The name of a SRV-record is defined as "_service._protocol.domain" -
for example "_ftp._tcp.xyz.com".
Most internet services are defined in RFC1700 (page 15), and the protocol
is generally TCP or UDP.
The "service location" is specified through a target, priority, weight,
and port:
- Target is the domain name of the server (referencing an A-record).
- Priority is a preference number used when more servers are providing
the same service (lower numbers are tried first).
- Weight is used for advanced load balancing.
- Port is the TCP/UDP port number on the server that provides this
service.
This record type is defined in RFC2782.
TXT-records are used to hold descriptive text.
They are often used to hold general information about a domain name such as who is hosting it, contact person, phone numbers, etc.
TXT-records are informational for people only and are not required for any DNS functions.
This record type is defined in RFC1035.
An X25-records maps a domain name to a Public Switched Data Network
(PSDN) address number.
Numbers used with this record should follow the X.121 international numbering plan.
This record type is defined in RFC1183.
This record type is defined in RFC1035.