DNS Records Explained with Examples
DNS (Domain Name
System), is the service which translates between Internet names
and Internet addresses.
Internet names are the names which we use to refer to hosts on
the Internet, such as www.debianhelp.co.uk.
Internet addresses are the numbers which routers use to move
traffic across the Internet, such as 211.1.13.115 and
What are DNS Records ?
DNS records or Zone files are used for mapping URLs to an IPs.
Located on servers called the DNS servers, these records are
typically the connection of your website with the outside world.
Requests for your website are forwarded to your DNS servers and
then get pointed to the WebServers that serve the website or to
Email servers that handle the incoming email.
Different Types of DNS Records With
Syntax and Examples
Types of DNS Records
A
AAAA
CNAME
MX
PTR
NS
SOA
SRV
TXT
NAPTR
The above DNS records are mostly used in all
DNS Configurations. Now we will see each one with examples.
A Record
An A record or address record.
Address Record, assigns an IP address to a domain or subdomain
name. When the domain name system was designed it was
recommended that no two A records refer to the same IP address.
Suppose you have the somedomain.tld domain and
want to assign 10.10.0.1 IP address to your web server, then you
should create an A record with "www.somedomain.tld" as Fully
Qualified Domain Name and "10.10.0.1" in the value field.
From now on, all the requests for www.somedomain.tld will be
sent to a server with that IP.
Basically is useful to use an A record when you have subdomains
residing on various systems.
Usefultip: you might use a "*.somedomain.tld" A record to allow
WHATEVER.somedomain.tld to be resolved to your IP, though a
wildcard CNAME record is often better than a wildcard A record.
Example of A Record with Syntax
example.com. IN A 69.9.64.11
Where
IN indicates Internet
A indicates the Address record.
The above example indicate that the IP Address for the domain
example.com is 69.9.64.11
AAAA Record
An AAAA record or IPv6 address record maps a hostname to a
128-bit IPv6 address.
The regular DNS Address resource record is defined for a 32-bit
IPv4 address, so a new one was created to allow a domain name to
be associated with a 128-bit IPv6 address. The four “A”s (“AAAA”)
are a mnemonic to indicate that the IPv6 address is four times
the size of the IPv4 address. The AAAA record is structured in
very much the same way as the A record in both binary and master
file formats; it is just much larger. The DNS resource record
Type value for AAAA is 28.
Example of AAAA Record with Syntax
The AAAA record is to help transition and coexistence between
IPv4 and IPv6 networks.An IPv4 nameserver can provide IPv6
addresses:
linux aaaa 3ffe:1900:4545:2:02d0:09ff:fef7:6d2c
CNAME Record
A CNAME record or canonical name record makes one domain name an
alias of another. The aliased domain gets all the subdomains and
DNS records of the original.
You should use a CNAME record whenever you want associate a new
subdomain to an already existing A record; i.e. you can make "www.somedomain.tld"
to "somedomain.tld", which should already have been assigned an
IP with an A record.
This allows you to have as many subdomains as you wish without
having to specify the IP for every record. Use a CNAME if you
have more services pointing to the same IP. This way you will
have to update only one record in the convenience of a change of
IP address.
Example of a CNAME record: "stuff.everybox.com CNAME
www.everybox.com" where 'www.everybox.com' is an A record
listing an IP address, and 'stuff.everybox.com' points to 'www.everybox.com'.
It will NOT allow you to foward a domain to a specific web page.
Use a webhop for that. Port numbers can be changed with webhops,
as well; CNAMEs cannot change the HTTP default of 80 to any
other port number.
Do not use CNAME defined hostnames in MX records. For example,
this is not recommended
Example Of CNAME With syntax
mail.example.com IN CNAME mail.example.net
where
IN indicates Internet
CNAME indicates CNAME record.
MX Record
An MX record or mail exchange record maps a domain name to a
list of mail exchange servers for that domain.
Example with
MX Record Syntax - Single mail servers
mydomain.com. 14400 IN MX 0 mydomain.com.
The MX record shows that all emails @ mydomain.com should be
routed to the mail server at mydomain.com. The DNS record shows
that mydomain.com is located at 26.34.9.14. This means that
email meant for test@mydomain.com will be routed to the email
server at 26.34.9.14. This finishes the task of the MX record.
The email server on that server then takes over, collects the
email and then proceeds to distribute it to the user ``test''.
It is important that there be a dot(``.'') after the domain name
in the MX record. If the dot is absent, it routes to ``mydomain.com.mydomain.com''.
The number 0, indicates Preferance number. Mail is always routed
to the server which has the lowest Preferance number. If there
is only one mail server, it is safe to mark it 0.
Using Multiple mail servers
If you want to use multiple mail servers you have to use MX
record preferences.The MX record preference values indicate
which mail server to use and in which order to try them when
they fail or don't respond. A larger preference number is less
preferred. Thus, a mail exchanger with a preference of zero (0)
is always preferred over all other mail exchangers. Setting
preference values to equal numbers makes mail servers equally
preferred.
Example with MX Record Syntax -
Multiple mail servers
mydomain.com. 14400 IN MX 0 mydomain.com.
mydomain.com. 14400 IN MX 30 server2.mydomain.com
You can have unlimited MX entries for Fallback or backup
purpose.If all the MX records are equal Preference numbers, the
client simply attempts all equal Preference servers in random
order, and then goes to MX record with the next highest
Preference number.
PTR Record
A PTR record or pointer record maps an IPv4 address to the
canonical name for that host. Setting up a PTR record for a
hostname in the in-addr.arpa domain that corresponds to an IP
address implements reverse DNS lookup for that address. For
example www.name.net has the IP address 122.0.3.16, but a PTR
record maps 16.3.0.122.in-addr.arpa.
Example of PTR Record with syntax
16.3.0.122.in-addr.arpa. IN PTR name.net
Here as you see the IP Address is reversed and added with in-addr.arpa
and this has come to the left side while the actual domain name
has gone to right side of IN PTR.
This is mostly used as a security and an anti-spam measure
wherein most of the webservers or the email servers do a reverse
DNS lookup to check if the host is actually coming from where it
claims to come from. It is always advisable to have a proper
reverse DNS record (PTR) is been setup for your servers
especially when you are running a mail / smtp server.
NS Record
An NS record or name server record maps a domain name to a list
of DNS servers authoritative for that domain. Delegations depend
on NS records.
NS Record Name Server Record which indicates the Authoritative
Name Servers for a particular Domain. The NS records of the
Authoritative Name Server for any given Domain will be listed on
the Parent Server. These are called as the Delegation Records as
these records on the Parent Server indicates the delegation of
the domain to the Authoritative servers.
The NS record will also be listed in the Zone records of the
Authoritative Name Server itself. These records are called as
the Authoritative Records.
The NS records found on the Parent Server should match the NS
records on the Authoritative Server as well. However, you can
have NS records listed on the Authoritative server that is not
listed in the Parent Server. This arrangement is normally used
to configure Stealth Name Servers.
Example of NS Record With syntax
example.com. IN NS ns1.live.secure.com.
where
IN indicates the Internet
NS indicates the type of record which Name Server record
The above indicates that the ns1.live.secure.com is the
authoritative server for the domain example.com
SOA Record
An SOA record or start of authority record specifies the DNS
server providing authoritative information about an Internet
domain, the email of the domain administrator, the domain serial
number, and several timers relating to refreshing the zone.
An SOA(State of Authority) Record is the most essential part of
a Zone file. The SOA record is a way for the Domain
Administrator to give out simple information about the domain
like, how often it is updated, when it was last updated, when to
check back for more info, what is the admins email address and
so on. A Zone file can contain only one SOA Record.
A properly optimized and updated SOA record can reduce bandwidth
between nameservers, increase the speed of website access and
ensure the site is alive even when the primary DNS server is
down.
Example of SOA Record with syntax
Here is the SOA record. Notice the starting bracket ``(``. This
has to be on the same line, otherwise the record gets broken.
; name TTL class rr Nameserver email-address
mydomain.com. 14400 IN SOA ns.mynameserver.com.
root.ns.mynameserver.com. (
2004123001 ; Serial number
86000 ; Refresh rate in seconds
7200 ; Update Retry in seconds
3600000 ; Expiry in seconds
600 ; minimum in seconds )
name - mydomain.com is the main
name in this zone.
TTL - 14400 - TTL defines the
duration in seconds that the record may be cached by client side
programs. If it is set as 0, it indicates that the record should
not be cached. The range is defined to be between 0 to
2147483647 (close to 68 years !) .
Class - IN - The
class shows the type of record. IN equates to Internet. Other
options are all historic. So as long as your DNS is on the
Internet or Intranet, you must use IN.
Nameserver -
ns.nameserver.com. - The nameserver is the server which holds
the zone files. It can be either an external server in which
case, the entire domain name must be specified followed by a
dot. In case it is defined in this zone file, then it can be
written as ``ns'' .
Email address -
root.ns.nameserver.com. - This is the email of the domain name
administrator. Now, this is really confusing, because people
expect an @ to be in an email address. However in this case,
email is sent to root@ns.nameserver.com, but written as
root.ns.nameserver.com . And yes, remember to put the dot behind
the domain name.
Serial number - 2004123001 - This
is a sort of a revision numbering system to show the changes
made to the DNS Zone. This number has to increment , whenever
any change is made to the Zone file. The standard convention is
to use the date of update YYYYMMDDnn, where nn is a revision
number in case more than one updates are done in a day. So if
the first update done today would be 2005301200 and second
update would be 2005301201.
Refresh - 86000 -
This is time(in seconds) when the slave DNS server will refresh
from the master. This value represents how often a secondary
will poll the primary server to see if the serial number for the
zone has increased (so it knows to request a new copy of the
data for the zone). It can be written as ``23h88M'' indicating
23 hours and 88 minutes. If you have a regular Internet server,
you can keep it between 6 to 24 hours.
Retry - 7200 - Now assume that a
slave tried to contact the master server and failed to contact
it because it was down. The Retry value (time in seconds) will
tell it when to get back. This value is not very important and
can be a fraction of the refresh value.
Expiry - 3600000 - This is the time
(in seconds) that a slave server will keep a cached zone file as
valid, if it can't contact the primary server. If this value
were set to say 2 weeks ( in seconds), what it means is that a
slave would still be able to give out domain information from
its cached zone file for 2 weeks, without anyone knowing the
difference. The recommended value is between 2 to 4 weeks.
Minimum - 600 - This is the default
time(in seconds) that the slave servers should cache the Zone
file. This is the most important time field in the SOA Record.
If your DNS information keeps changing, keep it down to a day or
less. Otherwise if your DNS record doesn't change regularly,
step it up between 1 to 5 days. The benefit of keeping this
value high, is that your website speeds increase drastically as
a result of reduced lookups. Caching servers around the globe
would cache your records and this improves site performance.
SRV Record
The theory behind SRV is that given a known domain name e.g.
example.com, a given service e.g. web (http) which runs on tcp
in this case, a DNS query may be issued to find the host name
that provides such on behalf of the domain - and which may or
may not be within the domain.
Example of SRV Record with syntax
srvce.prot.name ttl class rr pri weight port target
_http._tcp.example.com. IN SRV 0 5 80 www.example.com.
srvce
Defines the symbolic service name (see IANA port-numbers)
prepended with a '_' (underscore). Case insensitive. Common
values are:
_http - web service
_ftp - file transfer service
_ldap - LDAP service
prot
Defines the protocol name (see IANA service-names) prepended
with a '_' (underscore). Case insensitive. Common values are
_tcp - TCP protocol
_udp - UDP protocol
name
Incomprehensible description in RFC 2782. Leaving the entry
blank (without a dot) will substitute the current zone root (the
$ORIGIN), or you can explicitly add it as in the above _http._tcp.example.com.
(with a dot).
ttl
Standard TTL parameter. For more information about TTL values.
pri
The relative Priority of this service (range 0 - 65535). Lowest
is highest priority.
weight
Used when more than one service with same priority. A 16 bit
unsigned integer in the range 0 - 65535. The value 0 indicates
no weighting should be applied. If the weight is 1 or greater it
is a relative number in which the highest is most frequently
delivered i.e. given two SRV records both with Priority = 0, one
with weight = 1 the other weight = 6, the one with weight 6 will
have its RR delivered first 6 times out of 7 by the name server.
port
Normally the port number assigned to the symbolic service but
does this is not a requirement e.g. it is permissible to define
a _http service with a port number of 8100 rather than the more
normal port 80.
target
The name of the host that will provide this service. Does not
have to be in the same zone (domain).
TXT Record
A TXT record allows an administrator to insert arbitrary text
into a DNS record. For example, this record is used to implement
the Sender Policy Framework specification.
Example of TXT Record with syntax
SPF domains have to publish at least two directives: a version
identifier and a default mechanism.
mydomain.com. TXT "v=spf1 -all"
This is the simplest possible SPF record: it means your domain
mydomain.com never sends mail.
It makes sense to do this when a domain is only used for web
services and doesn't do email.
MX servers send mail, designate them.
mydomain.com. TXT "v=spf1 mx -all"
Let's pretend mydomain.com has two MX servers, mx01 and mx02.
They would both be allowed to send mail from mydomain.com.
other machines in the domain also send mail, designate them.
mydomain.com. TXT "v=spf1 mx ptr -all"
This designates all the hosts whose PTR hostname match
mydomain.com.
any other machines not in the domain also send mail from that
domain, designate them.
mydomain.com. TXT "v=spf1 a:mydomain.com mx ptr -all"
mydomain.com's IP address doesn't show up in its list of MX
servers. So we add an "a" mechanism to the directive set to
match it.
mydomain.com. TXT "v=spf1 a mx ptr -all"
This is shorthand for the same thing.
Each of your mail servers should have an SPF record also.When
your mail servers create a bounce message, they will send it
using a blank envelope sender: <>. When an SPF MTA sees a blank
envelope sender, it will perform the lookup using the HELO
domain name instead. These records take care of that scenario.
amx.mail.net. TXT "v=spf1 a -all"
mx.mail.net. TXT "v=spf1 a -all"
NAPTR Record
NAPTR records (NAPTR stands for "Naming Authority Pointer") are
a newer type of DNS record that support regular expression based
rewriting.
Example of NAPTR Record with syntax
$ORIGIN 3.8.0.0.6.9.2.3.6.1.4.4.e164.arpa.
NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:info@example.com!" .
NAPTR 10 101 "u" "E2U+h323" "!^.*$!h323:info@example.com!" .
NAPTR 10 102 "u" "E2U+msg" "!^.*$!mailto:info@example.com!" .
This record set maps the phone number +441632960083 onto three
possible identically ordered URIs, with a preference for SIP,
then H323, and finally email. In each case, the regular
expression matches the full AUS (^.$), and replaces it with a
URI (e.g., sip:info@example.com). As this is a terminal record,
this URI is returned to the client.Though most NAPTR records
replace the full AUS, it is possible for the regular expression
to back-reference part of the AUS, to grab an extension number,
say:
$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. *
NAPTR 10 100 "u" "E2U+sip""!^+441632960(.*)$!sip:\1@example.com!"
.
Once the client has the URI it must be resolved using DNS, but
this is no longer part of the DDDS algorithm..
wildcard DNS record
A wildcard DNS record is a record in a DNS zone file that will
match all requests for non-existent domain names, i.e. domain
names for which there are no records at all.
