http://www2.isupportyou.net/2010/07/understanding-dns-domain-naming-server.

html
Hi Friends,
First of all thanks for visiting my blog. I added Search option for my blog, you can easily
search for a particular topic using Google Search. If you are facing any issues, or if you have any
questions please mail me at charan@isupportyou.net Thanks.

Coming into the Topic.

What is DNS?
DNS stands for Domain Naming Server, it is a standard of naming domains in any operational
environment (Windows,Linux,Solaris,Any environment). It is a server which contains a database
of all the domains and all the servers which are associated with those domains.
Why it is Used?
Its a service dedicated to identify all the machines (domains & member servers) in a network. To
make this possible, every machine has to be registered in the authoritative DNS server of that
network. That means every operational network should have a dedicated DNS server to enable
identification and communication between the machines.
How it works?
As i said, it is dedicatedly used for identification, in technical words for name resolution.
Every machine in a network has a dedicated IP address & hostname as its identity. Whenever a
machine tries to communicate with another machine on the network it should first identify the
second machine, that means it should know the ip address of that particular machine. After
knowing the identity (i.e ip address), it will directly communicates with the second machine. So
to speak, a machine should know the ip address of the another machine, with which its going to
communicate before it starts. Another question Why the hostnames are used, if the machine
already have an identity in the terms of IP address? Hostname is an English word which is useful
for Human remembrance. It is impossible for a human being to remember lots of IP addresses,
but it is possible to remember English names of the same hosts (as we configure the hostnames
generally with employee name or department name or location name etc). For example we can
remember www.yahoo.com but not its ip address, because we are not having only one website on
the internet. To sum up Hostnames and IP addresses both are used to identification and
communication between two machines in a network. But machines are only able to communicate
with the IP addresses and which are impossible to remember for Humans (Keep in mind

machines never communicate with hostnames). To solve this situation DNS was implemented. It
basically contains a database of host records in a network. A host record contains Hostname :
IP address, see the image below for better under standing. Out Internet is purely depended on
DNS, when we access a particular website we will give its English name, when we press ENTER
immediately the machines starts finding the IP address of the website using the DNS server
configured on it. I will explain the name resolution process in details. And one more thing about
the DNS is, it is the only largest database on the internet which changes every second. If this
database goes down by a chance, we must remember all the ip addresses to access the internet.
hahaha it will not happen, why because we have so many backup solutions already implemented.

How the name resolution takes place?

I will explain this concept with internet as an example. Before that i want you to check some
settings on your machine. Check the TCP/IP properties and see whether DNS server is
configured or not. If you are seeing obtain automatically option, open command prompt and type
ipconfig /all and press Enter. You will get DNS servers information along with your machines
IP address. Now lets talk about the scenario, When you try to open a website like
www.google.com, what happens next? how your machine gets IP address of the
www.google.com. Here it goes.
1. The request sent to the DNS server which is configured on your machine.
2. The DNS server checks for the host record of www.google.com in its database, if it contains a
record for www.google.com, it will directly send response with the IP address of
www.google.com. Otherwise it starts requesting another DNS server.
3. Before it goes to another DNS server, how it identifies which DNS server is responsible for
this request ? It checks the entire hostname (it is called as FQDN : Fully Qualified Domain
Name), i.e in googles case www.google.com. (note the FQDN ends with a period, and this
period is called as root domain).

4. Every DNS server contains a roothint file associated with it, and the same will be used to
identify the responsible DNS server. Root hint file contains Master DNS servers information.
Here you go it looks like this. These are the master DNS servers for .com, .net, .edu, .org
domains etc.
5. So in your case, the domain is .com, DNS server
sends request to .com master DNS server (for ex:
assume it as 198.41.0.4), the .com master DNS server
contains name server records for all machines ending
with .com . That means it definitely contains DNS
server IP address for google.com. In the same way it
contains all .com servers yahoo.com, microsoft.com & so on.
6. It does not contain the IP address of google.com, it contains DNS server IP of google.com.
7. So then the request is forwarded to google.com DNS server, in that server you will have a host
record with the name www and its IP address. Finally you reached it. With the found IP address
the request comes back as a response in the same reverse way to the DNS server which is
configured in your machine, that DNS server tells the IP address of www.google.com to your
machine.
8. This process happens in milliseconds in the background. i.e by the time you will get Website
found waiting for reply message in the status bar of your internet explorer.
9. Oh my god!!!! Is that simple? Yes it is. The same process occurs in corporate networks also.
But the requests are handled by their local DNS servers only.
In my previous discussion about Understanding DNS, you learned most of the basic things
related to DNS. In this post i want to elaborate more about DNS. Let's start...
DNS Records
There are so many records associated with a DNS Server. Name resolution process does not
happen in a proper way with out these records.
As you know the DNS server main purpose is to resolve the host names to IP's and vice versa.

A Record : Contains information about IP address. It is helpful in resolving host names to

IP addresses.

PTR Record : Pointer record, contains information about host name. It is helpful in
resolving IP address to hostname.

CNAME Record : Alias of A Record. It is helpful in giving multiple names to a single

host. Which means, the same host is able to provide multiple services. In that case, for
segregation of service and to communicate with that service we need to give different
names to each service. Even though these services are hosted on a single server, but we
can send our request to the target service. CNAME record was helpful in identifying and
communicating with that service on that server.

MX Record : It is a record helpful in identifying the mail server in a DNS domain (for
that organization)

NS Record : It is a record helpful in identifying the DNS server in a DNS domain (for
that organization)

SRV Record : This record is created when we install a service which is DNS dependent.
It is automatically generated and will be associated with a specific IP address. It is called
as Service record.

SOA Record : Start of Authority record, this is not a record associated with any IP
address. But it is associated with a number, which determines the update number. What
ever the update, when ever it is done this number will be incremented.

These are the records associated with each and every server in this world. A fact is that " DNS is
the biggest database in the world and that is the only one which gets updated every second
" And this database is not located at a single place, it is spread across the world in different
places like, different companies, different ISP's, different homes etc. And the name resolution
process is explained in my previous post Understanding DNS. That is the reason why, a DNS
request goes to different location to get the correct answer.
In my next article related to DNS, i will discuss about HOW TO TROUBLESHOOT DNS
PROBLEMS, KEEP VISITING OR SUBSRCIBE NOW TO GET THE LATEST POST
UPDATES.

___________________________________________________________________________________
Introduction to DNS Records

Updated Tuesday, January 20, 2015 by Elle Krout

The Domain Name System (DNS) is the Internets address book. DNS directs web traffic
to your Linode and email to your inbox by mapping memorable domain names
like example.com to IP addresses

like 12.34.56.78 or 0123:4567:89ab:cdef:0123:4567:89ab:cdef . This guide introduces

basic DNS concepts and the different types of DNS records.
How DNS Works

Before adding any DNS records, you should learn the basics of DNS. Youll start by
dissecting a domain name, and then youll learn about the mechanics of DNS resolution,
including name servers, zone files, and individual DNS records.
Domain Names

Domain names are best understood by reading from right to left. The broadest domain
classification is on the right, and become more specific as you move to the left. In the
examples below, the top-level domain, or TLD, is .com.
1example.com
2mail.hello.example.com

Every term to the left of the TLD and separated by a period is considered a more
specific subdomain, although conventionally, first-level subdomains plus their TLDs
(example.com) are referred to as domains. Moving to the left, hello and mail are the
second- and third-level subdomains, respectively. Typically, subdomains are used to
uniquely identify specific machines or services, but this is left up to the domain owner.
Name Servers

Choosing and specifying name servers is an essential part of domain ownership. If you
dont, the Internet wont know where to find your DNS information, and your domain
wont resolve. Name servers host a domains DNS information in a text file called
the zone file. Theyre are also known as Servers of Authority (SOAs). You can host your
DNS information on name servers in one of several locations:

Linode (recommended)

Your registrar

Your own DNS server

Third-party DNS hosting

Using Linodes free name servers is the easiest approach, because Linode provides a
default zone file with all the right IP addresses for your website and email. For basic
DNS setups and many advanced ones, Linodes name servers will work beautifully.
However, you can also look into the options offered by your registrar and third-party
DNS hosts, or host your own DNS if you want to take control of as much of the DNS
process as possible.
Youll specify name servers on your domain registrars website. Theyll take care of
publishing that information to the higher-level name servers. Youll want to specify at
least two name servers. That way, if one of them is down, the next one can continue to
serve your DNS information.
DNS Records and Zone Files

The next aspect of DNS management is specifying DNS records, which actually match
domain names to IP addresses. The DNS records are then automatically bundled up
into a zone file, which is what allows the Internet to look up the correct IP address for
your domain. If you decide to use Linodes name servers, our DNS Manager will help
you create a default zone file. It contains records similar to the following:
1
2; example.com [448369]
3$TTL 86400
4@ IN SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600
586400
6@
NS ns1.linode.com.
7@
NS ns2.linode.com.
8@
NS ns3.linode.com.
9@
NS ns4.linode.com.
1@
NS ns5.linode.com.
0@
MX 10 mail.example.com.
1@
A 12.34.56.78
1mail
A 12.34.56.78
1www
A 12.34.56.78
2

Every domains zone file contains the admins email address, the name servers, and the
DNS records. Of course, you are not limited to these default entries. You can create a

variety of DNS records for as many different subdomains as you wish. To learn how to
add individual DNS records using the DNS Manager, read this article.
DNS Resolution

So how does DNS actually work? First, the domain name needs to get translated into
your Linodes IP address. DNS matches human-friendly domain names
like example.com to computer-friendly IP addresses like 12.34.56.78. This happens in a
special text file called a zone file, which lists domains and their corresponding IP
addresses (and a few other things). A zone file is a lot like a phone book that matches
names with street addresses.
Heres how the DNS lookup process works:
1. You type a domain name like example.com in to the address bar.
2. Your computer connects to the Internet through an Internet Service Provider (ISP).
3. The ISPs DNS resolver queries a root nameserver for the proper TLD nameserver. In
other words, it asks the root nameserver, Where can I find the nameserver
for .com domains?
4. The root nameserver responds with the IP address for the .com nameserver.
5. The ISPs DNS resolver visits the .com nameserver, using the IP address it got from the
root nameserver. It asks the .com nameserver, Where can I find the nameserver
forexample.com?
6. The .com nameserver responds with the IP address for the example.com nameserver.
7. The ISPs DNS resolver visits your domains nameserver and reads the zone file.
8. The zone file shows which IP address goes with the domain.
9. Now that the ISP has the IP address for example.com, it connects you to your Linode.

10. Apache handles everything after that, ensuring that the correct files and folders
get displayed in your visitors browser.

The scenario described above is what happens if the ISP has no current information
about the requested domain. In actuality, ISPs cache a lot of DNS information after
theyve looked it up the first time. This results in faster lookups and less strain on DNS
servers. Usually caching is a good thing, but it can be a problem if youve recently made
a change to your DNS information, like when you move to Linode from a different

hosting provider. In those cases, youll want to pay attention to your zone files time to
live (TTL) so that your DNS change happens as quickly as possible.
Types of DNS Records
A and AAAA

An A record matches up a domain (or subdomain) to an IP address. In other words, it

points your domain name to your Linodes IP address, which allows web traffic to reach
your Linode. This is the core functionality of DNS. A typical A record looks like the
following:
1example.com

12.34.56.78

You can also make A records for subdomains you want to direct to your server:
1hello.example.com

12.34.56.78

You can point different subdomains to different IP addresses.

If you want to point every subdomain of example.com to your Linodes IP, you can use
an asterisk (***) as your subdomain:
1*.example.com A

12.34.56.78

An AAAA record is just like an A record, but for IPv6 IP addresses. A typical AAAA
record looks like the following:
1example.com

AAAA

0123:4567:89ab:cdef:0123:4567:89ab:cdef

AXFR

An AXFR record is a type of DNS record used for DNS replication, although there are
also more modern ways to do DNS replication. AXFR records are not used in ordinary
zone files. Rather, they are used on a slave DNS server to replicate the zone file from
a master DNS server. For an example of how to configure Linodes nameservers as
slave DNS servers using AXFR, visit thisguide about configuring DNS on cPanel.

CNAME

A CNAME record or Canonical Name record matches up a domain (or subdomain) to a

different domain. With a CNAME record, DNS lookups use the target domains DNS
resolution as the aliass resolution. Heres an example:
1alias.com
CNAME example.com.
2example.com
A
12.34.56.78

With this setup, when alias.com is requested, the initial DNS lookup will find the CNAME
entry with the target of example.com . A new DNS lookup will be started
for example.com , which will find the IP address 12.34.56.78. Finally, visitors
to alias.com will be directed to 12.34.56.78 .
CNAME records exist so that domains can have aliases. You should not use a CNAME
record for a domain that gets email, because some mail servers handle mail oddly for
domains with CNAME records. Likewise, MX records cannot reference CNAME-defined
hostnames. Also, the target domain for a CNAME record should have a normal A-record
resolution. Chaining or looping CNAME records is not recommended.
In some cases, a CNAME record can be an effective way to redirect traffic from one
domain to another while keeping the same URL. However, keep in mind that a CNAME
record does not function the same way as a URL redirect. A CNAME record directs web
traffic for a particular domain to the target domains IP address. Once the visitor reaches
that IP address, the local Apache (or other web server) configuration will determine how
the domain is handled. If that domain is not configured on the server, the server will
simply display its default web page (if any). This may or may not be the web page for the
target domain in the CNAME record, depending on how the server is configured.
DKIM

A DKIM record or domain keys identified mail record displays the public key for
authenticating messages that have been signed with the DKIM protocol. This practice
increases the capability to check mail authenticity. A typical DKIM record looks like the
following:

1selector1._domainkey.example.com

TXT

k=rsa;p=J8eTBu224i086iK

DKIM records are implemented as text records. The record must be created for a
subdomain, which has a unique selector for that key, then a period (.), and
then _domainkey.example.com . The type is TXT, and the value includes the type of key,
followed by the actual key.
MX

An MX record or mail exchange record sets the mail delivery destination for a domain
(or subdomain). A typical MX record looks like the following:
1example.com
MX
2mail.example.com A

10 mail.example.com.
12.34.56.78

The above records direct mail for example.com to the mail.example.com server. The
target domain ( mail.example.com above) needs to have its own A record that resolves
to your Linode. Ideally, an MX record should point to a domain that is also
the hostname for its server.
Your MX records dont necessarily have to point to your Linode. If youre using a thirdparty mail service, like Google Apps, you should use the MX records they provide.
Priority is another component of MX records. This is the number written between the
record type and the target server (10 in the example above). Priority allows you to
designate a fallback server (or servers) for mail for a particular domain. Lower numbers
have a higher priority. Heres an example of a domain that has two fallback mail servers:
1example.com
2example.com
3example.com

MX
MX
MX

10 mail_1.example.com
20 mail_2.example.com
30 mail_3.example.com

In this example, if mail_1.example.com is down, mail will be delivered

to mail_2.example.com . If mail_2.example.com is also down, mail will be delivered
to mail_3.example.com .
NS

NS records or name server records set the nameservers for a domain (or subdomain).
The primary nameserver records for your domain are set both at your registrar and in
your zone file. Typical nameserver records (you need at least two) look like this:
1example.com
2example.com
3example.com
4example.com
5example.com

NS
NS
NS
NS
NS

ns1.linode.com.
ns2.linode.com.
ns3.linode.com.
ns4.linode.com.
ns5.linode.com.

The nameservers you designate at your registrar then carry the zone file for your
domain.
You can also set up different nameservers for any of your subdomains. Subdomain NS
records get configured in your primary domains zone file. For example, if youre using
Linodes nameservers, you could configure separate NS records in your Linode zone file
for the subdomain mail.example.com as shown below:
1mail.example.com
2mail.example.com

NS
NS

ns1.nameserver.com
ns2.nameserver.com

Primary nameservers get configured at your registrar; secondary subdomain

nameservers get configured in the primary domains zone file. The order of NS records
does not matter; DNS requests are sent randomly to the different servers, and if one
host fails to respond, another one will be queried.
PTR

A PTR record or pointer record matches up an IP address to a domain (or subdomain),

allowing reverse DNS queries to function. It performs the opposite service an A record
does, in that it allows you to look up the domain associated with a particular IP address,
instead of vice versa.
PTR records are usually set with your hosting provider. They are not part of your
domains zone file. This means that youll always set reverse DNS for your Linodes in
the Linode Manager, even if your nameservers are elsewhere. Likewise, if you have

servers somewhere else but are using Linodes nameservers, you will still have to set up
your PTR records with your hosting provider.
As a prerequisite for adding a PTR record, you need to create a valid, live A or AAAA
record that points the desired domain to that IP. If you want an IPv4 PTR record, point
the domain (or subdomain) to your Linodes IPv4 address. If you want an IPv6 PTR
record, point the domain to your Linodes IPv6 address. Beyond that, IPv4 and IPv6
PTR records work the same way.
For instructions on setting up reverse DNS on your Linode, see our Reverse DNS guide.
Its possible to have different IPs (including both IPv4 and IPv6 addresses) that have the
same domain set for reverse DNS. To do this, you will have to configure multiple A or
AAAA records for that domain that point to the various IPs.
SOA

An SOA record or Start of Authority record labels a zone file with the name of the host
where it was originally created. Next, it lists the contact email address for the person
responsible for the domain. There are also various numbers, which well get into in detail
in a moment. First, heres a typical SOA record:
@ IN SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600
1
86400

The administrative email address is written with a period (.) instead of an at symbol
(<@>).
Heres what the numbers mean:

Serial number: The revision number for this domains zone file. It changes when the file
gets updated.

Refresh time: The amount of time (in seconds) a secondary DNS server will keep the
zone file before it checks for changes.

Retry time: The amount of time a secondary DNS server will wait before retrying a failed
zone file transfer.

Expire time: The amount of time a secondary DNS server will wait before expiring its
current zone file copy if it cannot update itself.

Minimum TTL: The minimum amount of time other servers should keep data cached
from this zone file.

The single nameserver mentioned in the SOA record is considered the primary master
for the purposes of Dynamic DNS and is the server where zone file changes get made
before they are propagated to all other nameservers.
SPF

An SPF record or Sender Policy Framework record lists the designated mail servers for
a domain (or subdomain). It helps establish the legitimacy of your mail server and
reduces the chances of spoofing, which occurs when someone fakes the headers on an
email to make it look like its coming from your domain, even though the message did
not originate from your Linode. Spammers sometimes try to do this to get around spam
filters. An SPF record for your domain tells other receiving mail servers which outgoing
server(s) are valid sources of email, so they can reject spoofed email from your domain
that has originated from unauthorized servers. A very basic SPF record looks like the
following:
1example.com TXT

"v=spf1 a ~all"

In your SPF record, you should list all the mail servers from which you send mail, and
then exclude all the others. Your SPF record will have a domain or subdomain, type
(which is TXT, or SPF if your name server supports it), and text (which starts with
v=spf1 and contains the SPF record settings).
If your Linode is the only mail server you use, you should be able to use the example
record above. With this SPF record, the receiving server will check the IP addresses of
both the sending server and the IP address of example.com. If the IPs match, the check
passes. If not, the check will soft fail (i.e., the message will be marked but will not
automatically be rejected for failing the SPF check).
Make sure your SPF records are not too strict. If you accidentally exclude a legitimate
mail server, its messages could get marked as spam. We strongly recommend visiting

openspf.org to learn how SPF records work and how to construct one that works for
your setup. Their examples are also helpful.
SRV

An SRV record or service record matches up a specific service that runs on your
domain (or subdomain) to a target domain. This allows you to direct traffic for specific
services, like instant messaging, to another server. A typical SRV record looks like the
following:
1_service._protocol.example.com SRV

10

5060

service.example.com

Heres a breakdown of the elements in an SRV record:

Service: The name of the service must be preceded by an underscore (_) and followed
by a period (.). The service could be something like _xmpp.

Protocol: The name of the protocol must be proceeded by an underscore (_) and
followed by a period (.). The protocol could be something like _tcp.

Domain: The name of the domain that will receive the original traffic for this service.

Priority: The first number (10 in the example above) allows you to set the priority for the
target server. You can set different targets with different priorities, which allows you to
have a fallback server (or servers) for that service. Lower numbers have a higher priority.

Weight: If two records have the same priority, weight is used instead.

Port: The TCP or UDP port on which the service runs.

Target: The target domain or subdomain. This domain must have an A or AAAA record
that resolves to an IP address.

An example use of SRV records would be to set up Federated VoIP.

TXT

A TXT record or text record provides information about the domain in question to other
resources on the Internet. Its a flexible type of DNS record that can serve many different

purposes depending on the specific contents. One common use of the TXT record is to
create an SPF record on nameservers that dont natively support SPF. Another use is to
create a DKIM record for mail signing.
_______________________________________________________________________
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
As (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 siteperformance.
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 nonexistent domain names, i.e. domain names for which there are no records at all.

______________________________________________________________________________

Configure MX Records for Incoming SMTP E-Mail

Traffic

Posted on January 7, 2009 by Daniel Petri in Exchange Server with 0

Comments

How do I configure and test the MX Record for my Internet Domain name?

Sponsored
Exchange Monitoring Reporting Dashboard
Monitor vital messaging components with a one-look dashboard & avoid costly downtime.
Mailscape makes your job easier by providing Exchange monitoring and reporting in a concise,
easy-to-use solution.

Test Drive Mailscape Today!

When you want to run your own mail server, and it does not matter what
version and make of mail server youre using as long as the mail server is
using SMTP as the e-mail transfer mechanism youll need to configure the
MX Records for your domain.
MX is an acronym for Mail eXchange. MX is defined in RFC 1035. It specifies
the name and relative preference of mail servers for the zone. MX is a DNS
record used to define the host(s) willing to accept mail for a given domain.
I.e. an MX record indicates which computer is responsible for handling the
mail for a particular domain.
Without proper MX Records for your domain, only internal e-mail will be
delivered to your users. External e-mail from other mail servers in the world
will not be able to reach your server simply because these foreign servers
cannot tell to which server they need to talk (or open a connection to) in
order to send the mail destined for that domain.

You can have multiple MX records for a single domain name, ranked in
preference order. If a host has three MX records, a mailer will try to deliver
to all three before queuing the mail.
MX Records must be in the following format:
domain.com.

IN

MX

10

mail.domain.com.

The Preference field is relative to any other MX Record for the zone and can
be on any value between 0 and 65535. Low values are more preferred. The
preferred value is usually 10 but this is just a convention, not a thumb rule.
Any number of MX Records may be defined. If the host is in the domain it
requires an A Record. MX Records do not need to point to a host in the same
zone, i.e. an MX Record can. point to an A Record that is listed in any zone
on that DNS or any other DNS server.

External and Internet-connected networks

When connecting your mail server to the Internet (or to another exorganizational mailing system that uses SMTP) you must always make sure
that the rest of the world can successfully resolve your domains MX Record.
Failing to do so will cause e-mail traffic not to be delivered to you.
In order to properly configure your domains MX Record you should contact
your ISP (Internet Service Provider) or the party responsible for hosting your
DNS Domain name. They will ask you for your FQDN (Fully Qualified Domain
Name) and IP address of your mail server. Make sure you know them.
When your mail server is connected directly to the Internet
In cases where no NAT (Network Address Translation) is being used and
where your mail server is directly connected to the Internet, you will need to
provide them with the FQDN and IP address of your mail server.
Note: This is, by far, the least secure method for connecting a mail server to
the Internet.
Lets say you have the following LAN configuration:

In the above example you need to give the mail servers IP address as your
MX Record.
Domain name: dpetri.net
Record FQDN

Record Type

Record Value

mail.dpetri.net

212.143.143.130

dpetri.net

MX

mail.dpetri.net

MX Pref

10

You should make sure the ISP has had all the necessary routing tables
updated in order to provide Internet availability to your internal IP network
range.
Note: It doesnt matter if the real host name of the mail server is NOT
mail. Internet hosts dont mind that, they just need to know whats the
name of the mail server, and whats the IP address for that name.
When NAT is being used

In cases where NAT (Network Address Translation) is being used you will
need to provide them with the IP address of your external NAT interface, and
configure your NAT device with Static Mapping for TCP Port 25, and have all
TCP Port 25 traffic forwarded to the internal IP address of your mail server.
Lets say you have the following LAN configuration:

In the above example you need to give the NATs IP address as your MX
Record.
Domain name: dpetri.net
Record FQDN

Record Type

Record Value

mail.dpetri.net

192.90.1.1

dpetri.net

MX

mail.dpetri.net

MX Pref

10

Note: Make sure you properly configure the NAT device to forward all TCP
Port 25 traffic to 192.168.0.10.

When a Mail Relay is being used

In cases where you have a DMZ (Demilitarized Zone) with a Mail Relay host
(i.e. Linux, Windows 2000/2003 + IIS and SMTP, a dedicated appliance and
so on) you will need to provide the FQDN and IP address of your Mail Relay
machine, and configure the Firewall to only allow TCP Port 25 traffic to be
sent to the Mail Relays IP address, not to your real mail server.
You should then configure the Mail Relay to forward the incoming e-mail
traffic to the real mail server (after scanning it for spam, viruses and so on).
Lets say you have the following LAN configuration:

Sponsored

Instantly monitor vital messaging components. Get the Exchange

Dashboard Trial

Sponsored
In the above example you need to give the Mail Relays IP address as your MX
Record.

Domain name: dpetri.net

Record FQDN

Record Type

Record Value

mail.dpetri.net

192.90.1.17

dpetri.net

MX

mail.dpetri.net

MX Pref

10

Note: Make sure you properly configure the Firewall device to forward all
TCP Port 25 traffic to 192.90.1.17, and to allow 192.90.1.17 to send TCP
Port 25 traffic to your internal mail server at 192.168.0.10. Also, make sure
you let the internal mail server communicate only with the Mail Relay device
and that you set up an SMTP Connector on the mail server and configure it
to relay all external mail to the Mail Relay.
Note: Some networks might use the Internet Router as their NAT device,
and let the Firewall do just that. In those cases, the scenario is a mixture
between option #2 (NAT) and this one.

Internal networks
As stated above, there is usually no need to configure MX Records for
internal use, simply because internal (i.e. inter-organization) e-mail and
replication traffic is usually controlled via Active Directory-store information.
However there are some cases where you will want to configure internal MX
Records.

While these MX Records will generally not cause any harm even if you
configure them without actually needing them, you must pay close attention
to various configuration issues, especially when Mail-Relays and Smart-Hosts
are involved. Therefore I cannot say for sure if configuring non-necessary
MX Records will cause any problems to your local network. If you do not
know for sure (and this might be the case since youve bothered to read this
article in the first place) I suggest you consult a network specialist before
doing any changes.

Fault Tolerance
In case your mail server fails youd like to still be able to receive incoming email messages. Most small to medium sized companies will pay their ISPs
some monthly fee and that will buy them storage space on the ISPs mail
servers. For that to happen, a new MX Record will be added to their DNS
information, pointing to the ISPs mail server with a higher priority. For
example:
Record FQDN

Record Type

Record Value

MX Pref

mail.dpetri.net

192.90.1.17

mail.isp.com

212.143.25.1

dpetri.net

MX

mail.dpetri.net

10

dpetri.net

MX

mail.isp.com

100

Load Balancing
Medium to large sized companies will want to configure some load balancing
features for their incoming mail servers. For that to happen, the company
must set up a number of mail servers, each one with a different IP address
(actually, one can use Network Load Balancing NLB, or even clustering but
thats a topic for a different article). Then new MX Records will be added to

their DNS information, pointing to the mail servers, all with the same
priority. For example:
Record FQDN

Record Type

Record Value

MX Pref

maila.dpetri.net

192.90.1.17

mailb.dpetri.net

192.90.1.18

mailc.dpetri.net

192.90.1.19

mail.isp.com

212.143.25.1

dpetri.net

MX

maila.dpetri.net

10

dpetri.net

MX

mailb.dpetri.net

10

dpetri.net

MX

mailc.dpetri.net

10

dpetri.net

MX

mail.isp.com

100

Testing the MX Record configuration

Testing the MX Record configuration is critical especially when configuring it
for the first time with a new ISP you dont know that well and so on. Use
NSLOOKUP or DIG or any other DNS querying tool to make sure your
records are set straight.
Sample screenshot is of an NSLOOKUP test to Microsofts MX Records:

Also, make sure you can connect to the mail server by using the MX Record
information. You can do so by using Telnet, as described in the SMTP, POP3

and Telnet in Exchange 2000/2003 and Test SMTP Service in IIS and
Exchange articles.