Start of Authority (SOA)
The first record in any zone file is the SOA resource record. This is the most essential part of the DNS zone file, it indicates the basic properties of the domain name server and the zone that the domain is in. Each zone file can contain only one SOA record.
Example:
example.com. 900 IN SOA ns.example.com. admin.example.com. (
2013031618 ; Serial Number
86400 ; refresh
7200 ; retry
3600000 ; expire
86400; minimum )example.com – This is the domain that the zone file holds information for.
900 – This is the time to live (TTL). This is the length of time before the file expires, usually in seconds.
IN – This defines the record class. IN stands for internet
ns.example.com. – This is the primary name server for this domain, this must match what is set at the registrar.
admin.example.com. – The email address for whomever is in charge of the domain.
Serial Number – Keeps track of changes made to the file. number HAS to go up by at least one with each change. In general this number is the date followed by the revision number.
Refresh – Time a secondary DNS server waits before checking for changes to the zone
Retry – Time to wait before retrying if a Refresh fails
Expire – Time before the secondary DNS Server stops responding to queries for the zone
Minimum – This value is supplied in query responses by servers for the zone to inform others how long they should cache a resource record provided in an answer.
Name Server (NS)
NS records tell recursive nameservers which nameservers are authoritative for a zone. Recursive nameservers look at the NS records to work out who to ask next when resolving a name. You can have as many NS records in your zone file as you would like (these need to be set at the registrar as well) but most folks default to 2-4)
NOTE: The only zone file that matters is the one located at the authoritative name server for the domain. You can find which nameservers the internet will look at through a whois on the domain. No other zone file will matter.
Below is what google’s name servers look like.
You can find this with the command:
dig google.com ns;; QUESTION SECTION:
;google.com. IN NS
;; ANSWER SECTION:
google.com. 900 IN NS ns3.google.com.
google.com. 900 IN NS ns4.google.com.
google.com. 900 IN NS ns1.google.com.
google.com. 900 IN NS ns2.google.com.mail exchange (MX)
MX records are responsible for specifying which mail server is in charge of receiving email messages on behalf of a domain. The email client tries to make an SMTP connection to the primary mail server listed in the zone file. The records are ranked by priority from lowest to highest with the lowest being the primary. In the event that the primary server is not available the next listed will be tried in order. MX records must point to a domain, not an IP.
Below is what google’s mail servers look like.
You can find this with the command:
dig google.com mx;; QUESTION SECTION:
;google.com. IN MX
;; ANSWER SECTION:
google.com. 600 IN MX 40 alt3.aspmx.l.google.com.
google.com. 600 IN MX 50 alt4.aspmx.l.google.com.
google.com. 600 IN MX 10 aspmx.l.google.com.
google.com. 600 IN MX 20 alt1.aspmx.l.google.com.
google.com. 600 IN MX 30 alt2.aspmx.l.google.com.address (A)
The A record is used to find the IP associated with a domain name. This is what will carry you back to the correct server when you enter a domain name into a browser. A records are for IPv4 addresses, eventually we should see these translate into AAAA records which are the IPv6 version of the address record.
Below is what google’s A records look like.
You can find this with the command:
dig google.com;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 74.125.225.64
google.com. 300 IN A 74.125.225.65
google.com. 300 IN A 74.125.225.66
google.com. 300 IN A 74.125.225.67
google.com. 300 IN A 74.125.225.68AAAA
The quad A record is the address record but points to an IPv6 record
dig google.com AAAA;; QUESTION SECTION:
;google.com. IN AAAA
;; ANSWER SECTION:
google.com. 200 IN AAAA 2607:f8b0:4009:804::1005canonical name (cname)
This record will alias one name to another. The dns lookup will then follow the new name to the A record. These records must point to a fully qualified domain name (fqdn).
Example:
subdomain IN CNAME domain.com.This means subdomain.domain.com will load the same data as that on domain.com
text (TXT)
txt records hold free form text of any type. Originally these were for human readable information about the server such as location or data center. The most common uses for txt records today are Sender Policy Framework SPF and DomainKeys Identified E-mail Domain Keys (DKIM).
Below is what google’s spf records look like.
You can find this with the command:
dig google.com txtExample:
;; QUESTION SECTION:
;google.com. IN TXT
;; ANSWER SECTION:
google.com. 900 IN TXT "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"service locator (SRV)
Generalized service location record, used for newer protocols instead of creating protocol-specific records such as MX. This is something that has been popping up more recently but still isn’t something you see too very often.
- service: the symbolic name of the desired service.
- proto: the transport protocol of the desired service; this is usually either TCP or UDP.
- name: the domain name for which this record is valid.
- TTL: standard DNS time to live field.
- class: standard DNS class field (this is always IN).
- priority: the priority of the target host, lower value means more preferred.
- weight: A relative weight for records with the same priority.
- port: the TCP or UDP port on which the service is to be found.
- target: the canonical hostname of the machine providing the service.
Example:
_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com.pointer (ptr)
Pointer records will point an IP to a canonical name. They are used in reverse dns. It is important to note that a reverse dns record needs to be set up on the authoritative nameservers for the person that owns the IP not the person that owns the canonical name. In most cases, reverse DNS needs to be configured by whoever controls the IP block (typically the hosting provider), not on the domain owner’s server.
Example:
Reverse DNS for the IP 209.59.159.10
dig -x 209.59.159.10;; QUESTION SECTION:
;10.159.59.209.in-addr.arpa. IN PTR
;; ANSWER SECTION:
10.159.59.209.in-addr.arpa. 900 IN PTR domain.com.