What is DNS recods?

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.axxess.co.za.
Internet addresses are the numbers which routers use to move traffic across the Internet, such as 211.1.13.115

A Record:

An A record or address record. Suppose you have the somedomain.co.za domain and want to assign 64.48.49.111 IP address to your web server, then you should create an A record with www.somedomain.co.za as Fully Qualified Domain Name and 64.48.49.111 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.

EXAMPLE: example.com. IN A 64.48.49.111 (example.com will point to IP 64.48.49.111)

MX Record:

An MX record or mail exchange record maps a domain name to a list of mail exchange servers for that domain. The MX record shows that all emails @ example.com should be routed to the mail server at mydomain.com. The DNS record shows that mydomain.com is located at 64.48.49.111. This means that email meant for test@example.com will be routed to the email server at 64.48.49.111. 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 ``example.com.example.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

EXAMPLE: example.com. 14400 IN MX 0 example.com.

  Use of multiple mail server

example.com. 14400 IN MX 0 example.com.

example.com. 14400 IN MX 10 server2.example.com.

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.example.com to example.com, 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.example.com CNAME www.example.com where www.example.com is an A record listing an IP address, and stuff.example.com points to www.example.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: mail.example.com IN CNAME mail.example.net

AAAA Record:

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

PTR Record:

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.

EXAMPLE: 64.48.49.111.in-addr.arpa. IN PTR name.net

NS Record:

EXAMPLE: example.com. IN NS ns1.axxessdns.co.za.

The above indicates that the ns1.axxessdns.co.za is the authoritative server for the domain example.com

SOA Records:

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.


; 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 cant 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 doesnt 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.

TX 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 Records 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 doesnt do email.

MX servers send mail, designate them.

mydomain.com. TXT v=spf1 mx -all

Lets 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.coms IP address doesnt 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