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. resolver2. name server3. 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 Name Description0-15 Identification Used to match responses to requests. Set by client and returned by server.

16-31 FlagsTells if query or response, type of query, if authoritative answer, if

truncated, if recursion desired, and if recursion is available.32-47 Number of questions48-63 Number of answer RRs64-79 Number of authority RRs80-95 Number of additional RRs96-?? Questions - variable lengths There can be variable numbers of questions sent.??-?? Answers - variable lengths Answers are variable numbers of resource records.??-?? Authority - variable lengths

??-??Additional Information -

variable lengths

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 RR value DescriptionA 1 Host's IP address

NS 2 Host's or domain's name server(s)CNAME 5 Host's canonical name, host identified by an alias domain name

PTR 12 Host's domain name, host identified by its IP addressHINFO 13 Host information

MX 15 Host's or domain's mail exchangerAXFR 252 Request for zone transferANY 255 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 - Host’s domain name, host identified by its IP address CNAME - Host’s canonical name allows additional names or aliases to be used to locate a computer. MX - Host’s or domain’s mail exchanger. NS - Host’s or domain’s 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=8H3600 ; Retry in seconds 7200=2H604800 ; Expire 3600000=1 week86400 ) ; 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.100mailmachine.mycompany.com. IN A 10.1.0.4george.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. IN NS ournamesv1.mycompany.com.mycompany.com. IN NS ournamesv2.mycompany.com.mycompany.com. IN NS ournamesv3.mycompany.com.

9. This line indicates the mailserver record. 10. mycompany.com. IN MX 10

mailmachine.mycompany.com.

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. IN A 10.1.0.10013. mailmachine.mycompany.com. IN A 10.1.0.414. george.mycompany.com. IN A 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 IN CNAME nameserver.mycompany.com.george.mycompany.com IN CNAME dataserver.mycompany.com. Linux1.mycompany.com IN CNAME engserver.mycompany.com. Linux2.mycompany.com IN CNAME 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 A 10.1.0.100 IN A 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

AAAAACNAMEMX PTRNSSOASRVTXTNAPTR

The above DNS records are mostly used in all DNS Configurations. Now we will see each one with examples.

A Record

An A record or address record.

Address Record, assigns an IP address to a domain or subdomain name. When the domain name system was designed it was recommended that no two A records refer to the same IP address.

Suppose you have the somedomain.tld domain and want to assign 10.10.0.1 IP address to your web server, then you should create an A record with "www.somedomain.tld" as Fully Qualified Domain Name and "10.10.0.1" in the value field.

From now on, all the requests for www.somedomain.tld will be sent to a server with that IP.

Basically is useful to use an A record when you have subdomains residing on various systems.

Usefultip: you might use a "*.somedomain.tld" A record to allow WHATEVER.somedomain.tld to be resolved to your IP, though a wildcard CNAME record is often better than a wildcard A record.

Example of A Record with Syntax

example.com. IN A 69.9.64.11

Where

IN indicates Internet

A indicates the Address record.

The above example indicate that the IP Address for the domain example.com is 69.9.64.11

AAAA Record

An AAAA record or IPv6 address record maps a hostname to a 128-bit IPv6 address.

The regular DNS Address resource record is defined for a 32-bit IPv4 address, so a new one was created to allow a domain name to be associated with a 128-bit IPv6 address. The four “A”s (“AAAA”) are a mnemonic to indicate that the IPv6 address is four times the size of the IPv4 address. The AAAA record is structured in very much the same way as the A record in both binary and master file formats; it is just much larger. The DNS resource record Type value for AAAA is 28.

Example of AAAA Record with Syntax

The AAAA record is to help transition and coexistence between IPv4 and IPv6 networks.An IPv4 nameserver can provide IPv6 addresses:

linux aaaa 3ffe:1900:4545:2:02d0:09ff:fef7:6d2c

CNAME Record

A CNAME record or canonical name record makes one domain name an alias of another. The aliased domain gets all the subdomains and DNS records of the original.

You should use a CNAME record whenever you want associate a new subdomain to an already existing A record; i.e. you can make "www.somedomain.tld" to "somedomain.tld", which should already have been assigned an IP with an A record.

This allows you to have as many subdomains as you wish without having to specify the IP for every record. Use a CNAME if you have more services pointing to the same IP. This way you will have to update only one record in the convenience of a change of IP address.

Example of a CNAME record: "stuff.everybox.com CNAME www.everybox.com" where 'www.everybox.com' is an A record listing an IP address, and 'stuff.everybox.com' points to 'www.everybox.com'. It will NOT allow you to foward a domain to a specific web page. Use a webhop for that. Port numbers can be changed with webhops, as well; CNAMEs cannot change the HTTP default of 80 to any other port number.

Do not use CNAME defined hostnames in MX records. For example, this is not recommended

Example Of CNAME With syntax

mail.example.com IN CNAME mail.example.net

where

IN indicates Internet

CNAME indicates CNAME record.

MX Record

An MX record or mail exchange record maps a domain name to a list of mail exchange servers for that domain.

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: 10Record: @

Address: mail.domain.com Priority: 20Record: @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-addressmydomain.com. 14400 IN SOA ns.mynameserver.com. root.ns.mynameserver.com. (2004123001 ; Serial number86000 ; Refresh rate in seconds7200 ; Update Retry in seconds3600000 ; Expiry in seconds600 ; 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._domainKeyAddress: 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 top-level 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 zone’s zone data isreplicated during the Active Directory replication process. Active Directory-integrated zones also enjoy the Active Directory’s 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 zone’s 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.