DNS: Domain Name Server (often referred to as simply a

Name Server)
Network resources are identified by numeric IP addresses, but these IP addresses are difficult for network users
to remember. The DNS database contains records that map user-friendly alphanumeric names for network
resources to the IP address used by those resources for communication. In this way, DNS acts as a mnemonic
device, making network resources easier to remember for network users
Since computers communicate with each other using numbers, and humans prefer host names, DNS is necessary
in order for computers to translate our host names back to IP addresses.

Host Names
Domain Name Service (DNS) is the service used to convert human readable names of hosts to IP
addresses. Host names are not case sensitive and can contain alphabetic or numeric letters or the
hyphen. Avoid the underscore. A fully qualified domain name (FQDN) consists of the host name
plus domain name as in the following example:
computername.domain.com
The part of the system sending the queries is called the resolver and is the client side of the
configuration. The nameserver answers the queries. Read RFCs 1034 and 1035. These contain the
bulk of the DNS information and are superceded by RFCs 1535-1537. Naming is in RFC 1591. The
main function of DNS is the mapping of IP addresses to human readable names.
Three main components of DNS
1. resolver
2. name server
3. database of resource records(RRs)

Domain Name System

The Domain Name System (DNS) is basically a large database which resides on various computers
and it contains the names and IP addresses of various hosts on the internet and various domains. The
Domain Name System is used to provide information to the Domain Name Service to use when
queries are made. The service is the act of querying the database, and the system is the data
structure and data itself. The Domain Name System is similar to a file system in Unix or DOS
starting with a root. Branches attach to the root to create a huge set of paths. Each branch in the
DNS is called a label. Each label can be 63 characters long, but most are less. Each text word
between the dots can be 63 characters in length, with the total domain name (all the labels) limited
to 255 bytes in overall length. The domain name system database is divided into sections called
zones. The name servers in their respective zones are responsible for answering queries for their
zones. A zone is a subtree of DNS and is administered separately. There are multiple name servers
for a zone. There is usually one primary nameserver and one or more secondary name servers. A
name server may be authoritative for more than one zone.
DNS names are assigned through the Internet Registries by the Internet Assigned Number Authority

(IANA). The domain name is a name assigned to an internet domain. For example, mycollege.edu
represents the domain name of an educational institution. The names microsoft.com and 3Com.com
represent the domain names at those commercial companies. Naming hosts within the domain is up
to individuals administer their domain.
Access to the Domain name database is through a resolver which may be a program or part of an
operating system that resides on users workstations. In Unix the resolver is accessed by using the
library functions "gethostbyname" and "gethostbyaddr". The resolver will send requests to the name
servers to return information requested by the user. The requesting computer tries to connect to the
name server using its IP address rather than the name.

Structure and message format

The drawing below shows a partial DNS hierarchy. At the top is what is called the root and it is the start of all
other branches in the DNS tree. It is designated with a period. Each branch moves down from level to level.
When referring to DNS addresses, they are referred to from the bottom up with the root designator (period) at the
far right. Example: "myhost.mycompany.com.".

DNS is hierarchical in structure. A domain is a subtree of the domain name space. From the root, the assigned
top-level domains in the U.S. are:

GOV - Government body.

EDU - Educational body.

INT - International organization

NET - Networks

COM - Commercial entity.

MIL - U. S. Military.

ORG - Any other organization not previously listed.

Outside this list are top level domains for various countries.
Each node on the domain name system is separated by a ".". Example: "mymachine.mycompany.com.". Note
that any name ending in a "." is an absolute domain name since it goes back to root.

DNS Message format:

Bits
0-15

Name
Identification

16-31

Flags

Description
Used to match responses to requests. Set by client and returned by server.
Tells if query or response, type of query, if authoritative answer, if
truncated, if recursion desired, and if recursion is available.

32-47
48-63
64-79
80-95
96-??
??-??
??-??

Number of questions
Number of answer RRs
Number of authority RRs
Number of additional RRs
Questions - variable lengths
Answers - variable lengths
Authority - variable lengths
Additional Information ??-??
variable lengths

There can be variable numbers of questions sent.

Answers are variable numbers of resource records.

Question format includes query name, query type and query class. The query name is the name being looked up.
The query class is normally 1 for internet address. The query types are listed in the table below. They include
NS, CNAME, A, etc.
The answers, authority and additional information are in resource record (RR) format which contains the
following.
1. Domain name
2. Type - One of the RR codes listed below.
3. Class - Normally indicates internet data which is a 1.
4. Time to live field - The number of seconds the RR is saved by the client.

5. Resource data length specifies the amount of data. The data is dependent on its type such as CNAME, A,
NS or others as shown in the table below. If the type is "A" the data is a 4 byte IP address.
The table below shows resource record types:
Type
A
NS
CNAME
PTR
HINFO
MX
AXFR
ANY

RR value
1
2
5
12
13
15
252
255

Description
Host's IP address
Host's or domain's name server(s)
Host's canonical name, host identified by an alias domain name
Host's domain name, host identified by its IP address
Host information
Host's or domain's mail exchanger
Request for zone transfer
Request for all records

Usage and file formats

If a domain name is not found when a query is made, the server may search for the name elsewhere and return
the information to the requesting workstation, or return the address of a name server that the workstation can
query to get more information. There are special servers on the Internet that provide guidance to all name
servers. These are known as root name servers. They do not contain all information about every host on the
Internet, but they do provide direction as to where domains are located (the IP address of the name server for the
uppermost domain a server is requesting). The root name server is the starting point to find any domain on the
Internet.

Name Server Types

There are three types of name servers:
1. The primary master builds its database from files that were preconfigured on its hosts, called zone or
database files. The name server reads these files and builds a database for the zone it is authoritative for.
2. Secondary masters can provide information to resolvers just like the primary masters, but they get their
information from the primary. Any updates to the database are provided by the primary.
3. Caching name server - It gets all its answers to queries from other name servers and saves (caches) the
answers. It is a non-authoritative server.
The caching only name server generates no zone transfer traffic. A DNS Server that can communicate outside of
the private network to resolve a DNS name query is referred to as forwarder.

DNS Query Types

There are two types of queries issued:
1. Recursive queries received by a server forces that server to find the information requested or post a
message back to the querier that the information cannot be found.
2. Iterative queries allow the server to search for the information and pass back the best information it
knows about. This is the type that is used between servers. Clients used the recursive query.

3. Reverse - The client provides the IP address and asks for the name. In other queries the name is provided,
and the IP address is returned to the client. Reverse lookup entries for a network 192.168.100.0 is
"100.168.192.in-addr arpa".
Generally (but not always), a server-to-server query is iterative and a client-resolver-to-server query is recursive.
You should also note that a server can be queried or it can be the person placing a query. Therefore, a server
contains both the server and client functions. A server can transmit either type of query. If it is handed a recursive
query from a remote source, it must transmit other queries to find the specified name, or send a message back to
the originator of the query that the name could not be found.

DNS Transport protocol

DNS resolvers first attempt to use UDP for transport, then use TCP if UDP fails.

The DNS Database

A database is made up of records and the DNS is a database. Therefore, common resource record types in the
DNS database are:

A - Host's IP address. Address record allowing a computer name to be translated into an IP address. Each
computer must have this record for its IP address to be located. These names are not assigned for clients
that have dynamically assigned IP addresses, but are a must for locating servers with static IP addresses.

PTR - Hosts domain name, host identified by its IP address

CNAME - Hosts canonical name allows additional names or aliases to be used to locate a computer.

MX - Hosts or domains mail exchanger.

NS - Hosts or domains name server(s).

SOA - Indicates authority for the domain

TXT - Generic text record

SRV - Service location record

RP - Responsible person

HINFO - Host information record with CPU type and operating system.

When a resolver requests information from the server, the DNS query message indicates one of the preceding
types.

DNS Files

CACHE.DNS - The DNS Cache file. This file is used to resolve internet DNS queries. On Windows
systems, it is located in the WINNTROOT\system32\DNS directory and is used to configure a DNS
server to use a DNS server on the internet to resolve names not in the local domain.

Example Files
Below is a partial explanation of some records in the database on a Linux based system. The reader should view
this information because it explains some important DNS settings that are common to all DNS servers. An
example /var/named/db.mycompany.com.hosts file is listed below.
mycompany.com.
IN
SOA
mymachine.mycompany.com.
root.mymachine.mycompany.com. (
1999112701
; Serial number as date and two digit number
YYMMDDXX
10800
; Refresh in seconds 28800=8H
3600
; Retry in seconds 7200=2H
604800
; Expire 3600000=1 week
86400 )
; Minimum TTL 86400=24Hours
mycompany.com.
IN NS
mymachine.mycompany.com.
mycompany.com.
IN MX
10
mailmachine.mycompany.com.
mymachine.mycompany.com.
IN A
10.1.0.100
mailmachine.mycompany.com.
IN A
10.1.0.4
george.mycompany.com.
IN A
10.1.3.16

A Line by line description is as follows:

1. The entries on this line are:
1. mycompany.com. - Indicates this server is for the domain mycompany.com.
2. IN - Indicates Internet Name.
3. SOA - Indicates this server is the authority for its domain, mycompany.com.
4. mymachine.mycompany.com. - The primary nameserver for this domain.
5. root.mymachine.mycompany.com. - The person to contact for more information.
The lines in the parenthesis, listed below, are for the secondary nameserver(s) which run as slave(s) to
this one (since it is the master).
2. 1999112701 - Serial number - If less than master's SN, the slave will get a new copy of this file from the
master.
3. 10800 - Refresh - The time in seconds between when the slave compares this file's SN with the master.
4. 3600 - Retry - The time the server should wait before asking again if the master fails to respond to a file
update (SOA request).
5. 604800 - Expire - Time in seconds the slave server can respond even though it cannot get an updated
zone file.
6. 86400 - TTL - The time to live (TTL) in seconds that a resolver will use data received from a nameserver
before it will ask for the same data again.
7. This line is the nameserver resource record. There may be several of these if there are slave name servers.
8. mycompany.com.

IN

NS

mymachine.mycompany.com.

Add any slave server entries below this like:

mycompany.com.
mycompany.com.
mycompany.com.

IN
IN
IN

NS
NS
NS

ournamesv1.mycompany.com.
ournamesv2.mycompany.com.
ournamesv3.mycompany.com.

9. This line indicates the mailserver record.

10.

mycompany.com.
mailmachine.mycompany.com.

IN

MX

10

There can be several mailservers. The numeric value on the line indicates the preference or precedence
for the use of that mail server. A lower number indicates a higher preference. The range of values is from
0 to 65535. To enter more mailservers, enter a new line for each one similar to the nameserver entries
above, but be sure to set the preferences value correctly, at different values for each mailserver.
11. The rest of the lines are the name to IP mappings for the machines in the organization. Note that the
nameserver and mailserver are listed here with IP addresses along with any other server machines
required for your network.
12. mymachine.mycompany.com.
13. mailmachine.mycompany.com.
14. george.mycompany.com.

IN
IN
IN

A
A
A

10.1.0.100
10.1.0.4
10.1.3.16

Domain names written with a dot on the end are absolute names which specify a domain name exactly as it exists
in the DNS hierarchy from the root. Names not ending with a dot may be a subdomain to some other domain.
Aliases are specified in lines like the following:
mymachine.mycompany.com
george.mycompany.com
Linux1.mycompany.com
Linux2.mycompany.com

IN
IN
IN
IN

CNAME
CNAME
CNAME
CNAME

nameserver.mycompany.com.
dataserver.mycompany.com.
engserver.mycompany.com.
mailserver.mycompany.com.

When a client (resolver) sends a request, if the nameserver finds a CNAME record, it replaces the requested
name with the CNAME, then finds the address of the CNAME value, and return this value to the client.
A host that has more than one network card which is set to address two different subnets can have more than one
address for a name.
mymachine.mycompany.com

IN
IN

A
A

10.1.0.100
10.1.1.100

When a client queries the nameserver for the address of a multi homed host, the nameserver will return the
address that is closest to the client address. If the client is on a different network than both the subnet addresses
of the multi homed host, the server will return both addresses.
For more information on practical application of DNS, read the DNS section of the Linux User's Guide.
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.

An important part of the email delivery system is "MX" records. MX records

essentially tell the world what server to send mail to for a particular domain name.
Priority field: The priority preference for that MX record. MX records are processed in
order starting with the one with the lowest priority value and working towards high
priority records. In situations where you have multiple email servers, or backup email
servers, set a lower priority value for your primary mail server and a higher priority
value for your backup server.
Record field: You can specify a 3rd level mail domain here, but typically you will want
to leave it as "@" to specify the record is for the root domain name.
Address field: The address of the target mail server. It is recommended to use a
domain name value here as opposed to an IP address. Typically you would first
create an "A" record of "mail" pointing to the IP address of your mail server, and
specify "mail.domain.com" here as the address entry for the MX record.
Example MX records:
Priority: 10
Record: @
Address: mail.domain.com
Priority: 20
Record: @
Address: mail2.domain.com

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
An SRV record stands for service and is used to define a TCP service on which the domain operates
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.
Typically a TXT record is used to get information about a domain. They can be used to specify what email servers are
allowed to send mail for your domain with what is known as a "Sender Policy Framework (SPF)" record - which is very
useful in combating spammers from falsely marking spam emails as from your domain name. They can also be used to
provide a public "DomainKey" to be used to further prove the identity of emails being sent from your mail server to prove to
spam filters that your domain's email is legitimate email.
Record field: The name of the TXT record. For example, to create an SPF record you would want to leave it as "@" to
specify the record is for the root domain name. DomainKeys require a more detailed record name.
Address field: This is the value of the TXT record.
Example TXT records:
Record: @
Address: v=spf1 a mx -all
Record: dkDomain._domainKey
Address: p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhANZYB0

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.

Absolute domain
Each node on the domain name system is separated by a ".". Example: "mymachine.mycompany.com.". Note that any
name ending in a "." is an absolute domain name since it goes back to root.

Difference between dns recursive and interactive query?

Recursive queries When a client system sends a recursive query to a local name server, that local name server must
return the IP address for the friendly name entered, indicate that it can't find an address, or return an error saying that
the requested address does not exist.
Name servers do not refer the client system requesting a recursive query to other DNS servers. When answering
recursive queries, the originating client does not receive address information directly from any DNS server other than
the local name server.
Typically, the local name server will first check DNS data from its own boot file, cache, database, or reverse lookup file.
If the server is unsuccessful in obtaining the answer from those local sources, it may contact other DNS servers for

assistance using iterative queries and then pass the information it receives back to the client that originated the name
resolution request.
Iterative queries In iterative queries, name servers return the best information they have. Although a DNS server may
not know the IP address for a given friendly name, it might know the IP address of another name server likely to have
the IP address being sought, so it sends that information back. The response to an iterative query can be likened to a
DNS server saying, "I don't have the IP address you seek, but the name server at 10.1.2.3 can tell you."
The process is straightforward. Here's one example in which a local name server uses iterative queries to resolve an
address for a client: The local name server receives a name resolution request from a client system for a friendly name
(such as www.techrepublic.com). The local name server checks its records. If it finds the address, it returns it to the
client. If no address is found, the local name server proceeds to the next step. The local name server sends an iterative
request to the root (the "." in .com) name server. The root name server provides the local name server with the
address for the top-level domain (.com, .net, etc.) server. The local name server sends an iterative query to the toplevel domain server. The top-level domain server replies with the IP address of the name server that manages the
friendly name's domain (such as techrepublic.com). The local name server sends an iterative request to the friendly
name's domain name server. The friendly name's domain name server provides the IP address for the friendly name
(www.techrepublic.com) being sought. The local name server passes that IP address to the client.
It seems complicated, but the process completes in a matter of moments. Or, if an address isn't found, a 404 error
message is returned to the client.

======================================================================

The different types of zones used in Windows Server 2003 DNS are listed below:

Primary zone

Secondary zone

Active Directory-integrated zone

Reverse lookup zone

Stub zone

A primary zone is the only zone type that can be edited or updated because the data in the zone is the original
source of the data for all domains in the zone. Updates made to the primary zone are made by the DNS server
that is authoritative for the specific primary zone. Users can also back up data from a primary zone to a
secondary zone.
A secondary zone is a read-only copy of the zone that was copied from the master server during zone transfer. In
fact, a secondary zone can only be updated through zone transfer.
An Active Directory-integrated zone is a zone that stores its data in Active Directory. DNS zone files are not
needed. This type of zone is an authoritative primary zone. An Active Directory-integrated zones zone data is
replicated during the Active Directory replication process. Active Directory-integrated zones also enjoy the
Active Directorys security features.
A reverse lookup zone is an authoritative DNS zone. These zones mainly resolve IP addresses to resource names
on the network. A reverse lookup zone can be either of the following zones:

Primary zone

Secondary zone

Active Directory-integrated zone

A stub zone is a new Windows Server 2003 feature. Stub zones only contain those resource records necessary to
identify the authoritative DNS servers for the master zone. Stub zones therefore contain only a copy of a zone,
and are used to resolve recursive and iterative queries:
Stub zones contain the following information:

Start of Authority (SOA) resource records of the zone

Resource records that list the authoritative DNS servers of the zone

Glue address (A) resource records that are necessary for contacting the authoritative servers of the zone.

Zone delegation occurs when users assign authority over portions of the DNS namespace to subdomains of the
DNS namespace. Users should delegate a zone under the following circumstances:

To delegate administration of a DNS domain to a department or branch of the organization.

To improve performance and fault tolerance of the DNS environment. Users can distribute DNS database
management and maintenance between several DNS servers.

Understanding DNS Zone Transfer

A zone transfer can be defined as the process that occurs to copy the zones resource records on the primary DNS
server to secondary DNS servers. Zone transfer enables a secondary DNS server to continue handling queries if
the primary DNS server fails. A secondary DNS server can also transfer its zone data to other secondary DNS
servers that are beneath it in the DNS hierarchy. In this case, the secondary DNS server is regarded as the master
DNS server to the other secondary servers.
The zone transfer methods are:

Full transfer: When the user configures a secondary DNS server for a zone and starts the
secondary DNS server, the secondary DNS server requests a full copy of the zone from the
primary DNS server. A full transfer of all the zone information is performed. Full zone
transfers tend to be resource intensive. This disadvantage of full transfers has led to the
development of incremental zone transfers.

Incremental zone transfer: With an incremental zone transfer, only those resource records
that have since changed in a zone are transferred to the secondary DNS servers. During
zone transfer, the DNS database is on the primary.
DNS server and the secondary DNS server are compared to determine whether there are
differences in the DNS data. If the primary and secondary DNS servers data are the same,
zone transfer does not take place. If the DNS data of the two servers are different, transfer
of the delta resource records starts. This occurs when the serial number on the primary
DNS server database is higher than that of secondary DNS server. For incremental zone
transfer to occur, the primary DNS server has to record incremental changes to its DNS
database. Incremental zone transfers require less bandwidth than full zone transfers.

Active Directory transfers: These zone transfers occur when Active Directory-integrated
zones are replicated to the domain controllers in a domain. Replication occurs through
Active Directory replication.

DNS Notify is a mechanism that enables a primary DNS server to inform secondary DNS
servers when its database has been updated. DNS Notify informs the secondary DNS
servers when they need to initiate a zone transfer so that the updates of the primary DNS
server can be replicated to them. When a secondary DNS server receives the notification
from the primary DNS server, it can start an incremental zone transfer or a full zone
transfer to pull zone changes from the primary DNS servers.