Zone files are nothing but simple text files, that can be easily modified by using text editors such as VIM, gedit, neno etc. This file contains the complete details of all resource records for that domain. In other words it will contains the entire ip to domain mapping of the domain. During this blog post I will be using a zone file made for BIND(Berkeley Internet Name Domain) DNS server from CentOS 7 Linux operating system, which is a very widely used DNS server package. Zone files are made in such a way that it can be made portable for any DNS server.
The main purpose of this blog post is to understand the contents of a zone file, and how they play a major role in the DNS system(we will also be studying some of the widely used resource records in DNS). We will be discussing bind related configurations in a separate post, as it requires special attention.
TTL (Time To Live)
In the above shown example configuration file, there a TTL value assigned by the below method.
@TTL 1d
TTL stands for Time To Live, which mentions the time in seconds for which caching name servers can cache the data. Here the TTL value mentioned in the beginning of the file, is the bind's method of specifying the default TTL value for the domain, if not explicitly mentioned.
Let's take an example to understand TTL. I will do a simple dig against google.com, to see
What's the TTL ??
[root@master ~]# dig @127.0.0.1 master.zmailtech.com
; <<>> DiG 9.9.4-RedHat-9.9.4-50.el7 <<>> @127.0.0.1 master.zmailtech.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13237
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;master.zmailtech.com. IN A
;; ANSWER SECTION:
master.zmailtech.com. 86400 IN A 192.168.10.2
;; AUTHORITY SECTION:
zmailtech.com. 86400 IN NS ns1.zmailtech.com.
;; ADDITIONAL SECTION:
ns1.zmailtech.com. 86400 IN A 192.168.10.2
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec 13 21:47:11 IST 2017
;; MSG SIZE rcvd: 99
[root@master ~]#
In the above example, the TTL value of 86400 mentioned in the second column of the output is the number of seconds remaining for the TTL to expire. Please note the fact that, the above reply is given by your local name server which you have in your resolv.conf file. 86400 seconds means, that after 86400 seconds, your local DNS server will follow the entire procedure of fetching A record for zmailtech.com
But until that TTL expires, your local DNS server will sit and serve the cached records to all the clients. So if you repeatedly do a dig for google.com, you will always get a different value in TTL field(because its in seconds and goes on reducing).
If you really want to know the TTL of any record of any domain, you either need to do a dig to the authoritative name server for that domain, or do a dig + trace for that domain. So let's find out the exact TTL value for Google.com by doing a dig against its authoritative name server(which you will get by doing a dig NS google.com or a dig + trace)
[root@master ~]$ dig @ns1.google.com google.com
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 300 IN A 173.194.203.100
google.com. 300 IN A 173.194.203.138
google.com. 300 IN A 173.194.203.113
google.com. 300 IN A 173.194.203.102
google.com. 300 IN A 173.194.203.139
google.com. 300 IN A 173.194.203.101
So you will always get the TTL value of 300, when you do a dig by using ns1.google.com. Doing @<server> while using dig will ask dig to send the DNS query to that server, instead of your local DNS server mentioned in resolv.conf There are two things that you need to consider about TTL value.
- A low TTL value means, that your authoritative name server will get a higher number of queries, because the TTL gets expired fast, due to which resolvers, and DNS servers will query the server more often. But yeah if you change the records too often, then its advisable to keep a low TTL value, so that the latest entry gets updated fast. So for example you have a website www.example.com with an A record (we will be discussing A records in some time)of 172.16.140.43, and you want to change the IP address to something else, then in that case if you have a higher TTL value, the resolvers and DNS server's who already have the old entry will not refetch the current data until the TTL expires. So if you change records more often its advisable to keep a low value of TTL
- Keeping a higher value TTL will result in less number of queries hitting your authoritative name server. This is because once a record is cached in a local name server, it will not refetch the value until the TTL expires, and a high value TTL means less number of query, which intern means less load on your authoritative name server.
facebook.com. 172800 IN NS a.ns.facebook.com.
facebook.com. 172800 IN NS b.ns.facebook.com.
;; Received 153 bytes from 192.33.14.30#53(192.33.14.30) in 187 ms
172800 seconds in the above shown result means 48 hours. That large value is correct, because its very less often that people change the authoritative name server IP addresses(note the fact that the above output is the data given by a.ns.facebook.com showing the name servers for the domain facebook.com).
facebook.com. 172800 IN NS b.ns.facebook.com.
;; Received 153 bytes from 192.33.14.30#53(192.33.14.30) in 187 ms
172800 seconds in the above shown result means 48 hours. That large value is correct, because its very less often that people change the authoritative name server IP addresses(note the fact that the above output is the data given by a.ns.facebook.com showing the name servers for the domain facebook.com).
SOA or Start of Authority in a Zone file.
SOA is the mandatory record that must be there in all zone files. It specifies the main properties and characteristics of a domain. We will walk through each of them one by one. The default format of specifying a SOA record is shown below.
NAME TTL CLASS RR NAMESERVER EMAIL SERIALNUMBER REFRESH RETRY EXPIRY MIN
NAME: This specifies the name of the domain. As mentioned before, i am using a zone file made for bind DNS server. If you see our SOA begins with the following line
@ IN SOA ns1.zmailtech.com. admin.zmailtech.com.
@ shown in the above line is the NAME value for this SOA record. Using @ at this place will replace it with zmailtech.com as we have mentioned it in $ORIGIN. One important thing to understand here is the $ORIGIN entry, which is used to make all other entires in the zone file a FQDN. FQDN stands for Fully Qualified Domain Name, and it always ends with a dot (.).
So www.zmailtech.com is not a FQDN but www.zmailtech.com. is. The final DOT specifies the root name servers.
TTL: You can give different TTL values to different records, however we have already defined a default TTL value of 1 day in the beginning of the zone file. This default TTL value gets applied for all records that does not have an explicit TTL defined. So in case of our SOA record, the default TTL value of 1 day gets applied, as there is no TTL specific to SOA is defined.
CLASS: The default path used for all resource records are IN, which stands for internet(there are few other class as well which are mentioned in the RFC 2929).
RR: This specifies the resource record name. so its SOA here.
NAMESERVER: This is the primary name server for this domain/zone. Please note the fact that there must be a A record for this name server later in the same zone file that will specify the IP address of that name server. We will be discussing A records in some time.
EMAIL: This specifies the administrative contact email address for this domain. But if you see our example zone file, you will see that its admin.zmailltech.com instead of any email address. That's simiply because @ sign in zone file has some different meaning other than email address.
SERIALNUMBER: Its one of the important entries inside the SOA record in a zone file. Serial number tells the modification date of the zone file. Every time you modify the zone file, you also need to modify the serial number. Serial numbers in zone file follows a date format of
yyyymmddss. Which means if you have edited your zone file on 12th September 2013, your serial number will be 2013091200. This entry of serial number is mostly used for zone transfer to confirm the last modification of the zone. We will be discussing the zone transfer stuff in a dedicated post.
REFRESH: Indicates the time after which the secondary or slave DNS server for this domain re-fetches the SOA record for this zone.
RETRY: Specifies the retry interval if the slave will take, in case of a failure.
EXPIRY: This specifies the duration after which the slave name server will stop responding to DNS queries if the connection to master server cannot be established by following retry interval.
MIN: You might have seen something like NXDOMAIN, while digging for any domain name. for example lets dig for a non existent domain name.
[root@master ~]$ dig xyz.zmailtech.com
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.30.rc1.el6_6.2 <<>> xyz.zmailtech.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23931
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;xyz.zmailtech.com. IN A
If you see the above dig command, i have used a domain name that does not exist. So the name server for google.com replied with the status of NXDOMAIN, which is evident from the line ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23931, in the above output.
NXDOMAIN means non-existent domain name. So this MIN, filed in the SOA indicates the duration for which caching name servers (like your local name server) will cache the NXDOMAIN value.
Hence our final zone file SOA record will look something like below, which was also previously shown in the image.
@ IN SOA ns1.zmailtech.com. admin.zmailtech.com. (
2017121501 ; serial
1D ; refresh
1H ; retry
1W ; expire
3H ) ; minimum
No comments:
Post a Comment