1. DNS zones and resource records
Topics covered: Review: zones and resource records
SOA record in depth
Review: other types of RR's

2. Zones and RRs
Name servers store information about the name space in units called “zones”
A DNS zone is any distinct, contiguous portion of the domain name space in the Domain Name System (DNS) for which administrative responsibility has been delegated to a single manager.
To answer DNS queries DNS server zones must contain „resource records“
RRs are Classified into types (SOA, NS, A, CNAME etc.)
To define the zone at least SOA and NS records must be presented

3. SOA explained

4. SOA example owner-name
Generically this is a normal owner or label field. I is the 'root name' or the apex of the zone. Most commonly written (which substitutes the $ORIGIN) but can be the explicit base Domain Name in FQDN format (which is the same as the $ORIGIN or its synthesized version) as shown above.
ttl
Standard TTL values apply (range 0 to clarified by RFC 2181). A Slave DNS does not use this TTL value but various parameters defined within the SOA RR - see below. For more information about TTL values.
class
Defines the class of record and normally takes the value IN = Internet (Defaulted ii not present). It may also take the value HS = Hesiod and CH = Chaos both historic MIT protocols.
name-server
Any name server that will respond authoritatively for the domain. Called the Primary Master in the context of Dynamic DNS (DDNS). If DDNS is not used this may be any suitable name server either within the zone file (in-zone) or in an external or foreign zone (also called out-of-zone or even out-of-bailiwick by those of a more literary bent or with a taste for the exotic). To mimimise confusion this is most commonly written as a Fully-qualified Domain Name (FQDN - ends with a dot). If the record points to an EXTERNAL server (not defined in this zone) it MUST be a FQDN and end with a '.' (dot), for example, ns1.example.net. If the name server is within this domain (in this zone file) it can be written as ns1 (without the dot) which will be expanded to include the $ORIGIN. In the jargon this field is called MNAME field which is why we called it name-server. When to use the dot.
-addr
address of the person responsible for this zone and to which may be sent to report errors or problems. In the jargon this is called the RNAME field which is why we called it -addr. The address of a suitable DNS admin but more commonly the technical contact for the domain. By convention (in RFC 2142) it is suggested that the reserved mailbox hostmaster be used for this purpose but any sensible and stable address will work. NOTE: Format is mailbox-name.domain.com, for example, hostmaster.example.com (uses a dot not the more sign, has other uses in the zone file) but mail is sent to Most commonly ending with a '.' (dot) but if the address lies within this domain you can just use hostmaster (see also example below). when to use the dot.
sn = serial number
Unsigned 32 bit value in range 1 to with a maximum increment of In BIND implementations this is defined to be a 10 digit field. This value MUST increment when any resource record in the zone file is updated. A slave (Secondary) DNS server will read the master DNS SOA record periodically, either on expiry of refresh (defined below) or when it receives a NOTIFY and compares, arithmetically, its current value of sn with that received from the master. If the sn value from the master is arithmetically HIGHER than that currently stored by the slave then a zone transfer (AXFR/IXFR) is initiated by the slave. If the value of sn from the master DNS SOA is the same or LOWER then no zone transfer is initiated. The convention is to use a date based sn value to simplify the task of incrementing the sn - the most popular convention being yyyymmddss where yyyy = year, mm = month and dd = day ss = a sequence number in case you update it more than once in the day! Using this date format convention the value indicates the last update was on the 10th February 2005 and it was the third update that day. The date format is just a convention, not a requirement, so BIND (or any other DNS software) will not validate the contents of this field. It is easy to make mistakes and get serial numbers out of sequence. Fix Serial Numbers.
Note: the arithmetic used by the serial number is defined in RFC 1982.
refresh
Signed 32 bit time value in seconds. Indicates the time when the slave will try to refresh the zone from the master (by reading the master DNS SOA RR). RFC 1912 recommends 1200 to seconds, low (1200) if the data is volatile or (12 hours) if it's not. If you are using NOTIFY you can set it to much higher values, for instance, 1 or more days (> seconds). BIND Time format.
retry
Signed 32 bit value in seconds. Defines the time between retries if the slave (secondary) fails to contact the master when refresh (above) has expired or a NOTIFY message is received. Typical values would be 180 (3 minutes) to 900 (15 minutes) or higher. BIND Time format.
expiry
Signed 32 bit value in seconds. Indicates when the zone data is no longer authoritative. Used by Slave (Secondary) servers only. BIND9 slaves stop responding authoritatively to queries for the zone when this time has expired and no contact has been made with the master. Thus, every time the refresh values expires (or a NOTIFY message is received) the slave will attempt to read the SOA record from the zone master - and initiate a zone transfer AXFR/IXFR if sn is HIGHER. If contact is made the expiry and refresh values are reset and the cycle starts again. If the slave fails to contact the master it will retry every retry period but continue to respond authoritatively for the zone until the expiry value is reached at which point it will stop answering authoritatively for the domain. RFC 1912 recommends to seconds (2-4 weeks) to allow for major outages of the zone master. BIND Time format.
nx = nxdomain ttl
Signed 32 bit value in seconds. RFC 2308 (implemented by BIND 9) redefined this value to be the negative caching time - the time a NAME ERROR = NXDOMAIN result may be cached by any resolver. The maximum value allowed by RFC 2308 for this parameter is 3 hours (10800 seconds). Note: This value was historically (in BIND 4 and 8) used to hold the default TTL value for any RR from the zone that did not specify an explicit TTL. RFC 2308 (and BIND 9) uses the $TTL directive as the zone default TTL. You may find older documentation or zone file configurations which reflect the old usage. BIND Time format.

5. SOA important notes
The opening '(' (bracket) MUST appear on the same line as the SOA record. This is defined in RFC and BIND will reject the whole zone if this rule is broken. The terminating ')' (bracket) can appear on any line
The name server defined in the SOA record will ALWAYS have a NS record (there may be more than one NS record). For the sake of completeness the NS record is shown in the example fragments.
out-of-zone NS should not have A records (those are rejected by bind)
Do not forget trailing dots on NS

6. The A record The “Address” record One or more normally defines a host
Contains an IPv4 Address (the address computers use to uniquely identify each other on the internet)
Eg. The record:
enos A IN
In the itcollege.ee domain, defines the host uniquely identifiable as “enos.itcollege.ee” to be reachable at the IPv4 Address

7. The CNAME record A CNAME defines an alias
The alias will then be resolved, if another CNAME is encountered then the process continues until an A record is found
Eg. The record:
ftp CNAME enos.itcollege.ee.
In the itcollege.ee domain, defines the name uniquely identifiable as “ftp.itcollege.ee” to be and alias to “enos.itcollege.ee”

8. MX record
An MX record defines the mail servers for a particular domain
Mail eXchange records hold the name of hosts, and their priorities, able to deliver mail for the domain.
Eg. The record:
itcollege.ee MX 10 mail
In the itcollege.ee domain, defines the host mail to be the priority 10 mail server for the “itcollege.ee” domain
NB! of course you need an A record for mail
mail A IN

9. PTR record
You can think of the PTR record as an opposite of the A record. While the A record points a domain name to an IP address, the PTR record resolves the IP address to a domain/hostname. PTR records are used for the reverse DNS (Domain Name System) lookup.
PTR records of your external IP-s are usually under control of your ISP (exceptions)
You can create your own PTR records in your internal address space.

10. TXT records and DS records
A TXT record (short for text record) is a type of resource record in the Domain Name System (DNS) used to provide the ability to associate some arbitrary and unformatted text with a host or other name
TXT records are widely used to implement DNS extensions such as:
Anti-SPAM measures
DomainKeys Identified Mail (DKIM)
Domain-based Message Authentication, Reporting and Conformance (DMARC)
Sender Policy Framework (SPF)
Verify domain ownership (google)
Other custom uses
DS records are for DNSSEC
DNS Security Extensions,” commonly known as DNSSEC, provide a way to be sure that you are communicating with the correct website or other service.
Both topics are too complicated to cover in depth in this course

11. A Zone example