DNS Zone File

{ Notes in curly brackets are added by me. The rest of the file is unchanged }

{ The $ sign marks a directive — a control instruction to the zone file parser.They tell it how to interpret the records that follow. There are only a few defined ones:
$ORIGIN - Sets the base domain that gets appended to unqualified names
$TTL - Sets the default TTL for records that don't specify one
$INCLUDE - Imports another file into the zone
$GENERATE - Generates a range of records automatically }

{ The fields of a resource record are:
Owner TTL Class Type RDATA
When any of them is ommitted the value for it is inherited from a previous specified one or the default value set by the directives <the exeption is @ in which case it's not an ommission but a substition>                                                Three values can be inherited from the previous record when omitted:
Owner TTL Class }

{ AXFR = AXFR (Authoritative Zone Transfer) is a DNS transaction type (RFC 5936) used to replicate an entire DNS zone file from a primary to a secondary DNS server via TCP port 53. }

{ IXFR (Incremental Zone Transfer) is a DNS mechanism used to transfer only the changed records between a primary and secondary DNS server, rather than the entire zone file }

$ORIGIN example.com.
$TTL 86400
@	IN	SOA	dns1.example.com.	hostmaster.example.com. (
			2001062501 ; serial
			21600      ; refresh after 6 hours
			3600       ; retry after 1 hour
			604800     ; expire after 1 week
			86400 )    ; minimum TTL of 1 day

{@={value of $ORIGIN} IN SOA dns1.example.com. {master server for the zone}	hostmaster.example.com. {email address of the admin}( {all the resource records that exceel one line must be inside round brackets}
            2001062501 ; serial {This number is incremented when there is a change to the file}
			21600      ; refresh after 6 hours {how often a sec server should check if the zone needs to be refreshed.
Secondary server checks the serial number after 6 hours, if it didn't change, it checks after another 6 hours.}
			3600       ; retry after 1 hour  {How long a sec should wait after it failed to reach the primary}
			604800     ; expire after 1 week {how long should a sec server keep the zone data before discarding it.
If the secondary has been unable to reach the primary for the entire expire duration 1 week in this case, it stops serving the zone entirely — it will no longer respond authoritatively for it. The data isn't necessarily deleted from disk, but it is treated as too stale to serve. The practical implication is that the zone becomes unresolvable from that secondary until contact with the primary is re-established and a successful transfer occurs.}
			86400 )    ; minimum TTL of 1 day {This is meant only for resolvers. A resolver caching an NXDOMAIN <non-existent domain response> will return that cached negative response directly for up to 1 day without querying the authoritative server again. This has an operational consequence: if a name genuinely didn't exist but then gets added to the zone, resolvers that cached the NXDOMAIN won't see the new record until their negative cache entry expires.	You can always flush the cache though}

	IN	NS	dns1.example.com.
	IN	NS	dns2.example.com.

{Two name servers are usually required to prevent "Lame Delegations" because
a resolver will keep on trying to resolve the website if a server is down wasting resource across dns}

	IN	MX	10	mail.example.com.
	IN	MX	20	mail2.example.com.

{mail server responsible for the zone / lower value takes precedence, in this case 10}


dns1	IN	A	10.0.1.1
dns2	IN	A	10.0.1.2

{If the owner field is not fully qualified domain name, i.e with a dot at the end..
..the name gets appended to the origin of the zone, resulting in dns1.example.com}


server1	IN	A	10.0.1.5
server2	IN	A	10.0.1.6

{server1.example.com again appended to the origin of the zone example.com
origin of the zone is also called Apex Zone}


ftp	IN	A	10.0.1.3
	IN	A	10.0.1.4

{That is DNS-based load balancing, commonly called round-robin DNS. When a resolver queries for ftp.example.com, it gets both IP addresses back, and clients will alternate between them across successive queries, distributing traffic across two servers.
It is a crude form of load balancing — DNS has no awareness of server health or actual load, so if 10.0.1.3 goes down, DNS will still hand it out to half the clients.}

mail	IN	CNAME	server1
mail2	IN	CNAME	server2

{mail.example.com will resolve to 10.0.1.5 now..
..and mail2.example.com will resolve to 10.0.1.6}

www	IN	CNAME	server1

{This record contains a CNAME for server1 that will resolve www.example.com to server1.example.com but there is no A record
for example.com itself so consequently if someone typed in example.com the resolver would get an NXDOMAIN RESPONSE.}

{This is a PTR record that was not included in this file
3.1.0.10.in-addr.arpa. IN PTR ftp.example.com. Important: RFC 2181 §10.3 and the broader DNS specification state that certain record types — including PTR — must reference a canonical name, not an alias <so in this case ftp. works but www. doesn't}