Domain Name System (DNS) Zones

Domain Name System (DNS) is divided into many multiple various zones. These zones distinguish between specifically managed areas within DNS namespace. 

Domain Name System (DNS) Zones is any distinct, connecting segment of domain name space in Domain Name System (DNS) for which administrative responsibility has been delegated to single administrative space which allows for more smooth control of DNS components. Namespace of web is organized into hierarchical layout of subdomains below DNS root domain. Individual domains of this tree may function as delegation points for administrative authority and management.

◉ DNS zones are hierarchical concept. Therefore, namespace is subdivided into areas (zones) for this purpose. The purpose of DNS zones is to permit easier control over multiple levels of website.

◉ As the number of resource records increases for single domain, it becomes complex to manage all of them. Network administrations moderate this issue by breaking down their configurations into multiple zones.

◉ Root name servers are responsible for root zone. Each TLD name server is responsible for zone covering its specific TLD, and authoritative name servers are responsible for some even smaller zones below that.

◉ The root and TLD name servers are actually just authoritative name servers, but, zones that they’re authoritative for are special cases.

◉ DNS zones aren’t necessarily physically separated from each other; zones are strictly used for delegating control.

Example –

Imagine large tech company named “Dreamwave” that owns domain “www.dreamwave” with further 2 TLD servers: www.dreamwave.com and www.dreamwave.org. This company has offices in Canada, India, and Japan. Let’s say each office has around 1000 people with their own uniquely named desktop computer. This would be 3000 “A records” for both .com, .org TLD, and to keep track of if it was all configured as single zone. What corporate could do, instead, is break up each office into their own zone.

So now, we could have ca.largecompany.com, in.largecompany.com, and jp.largecompany.com as subdomains, each with their own DNS zones. A total of four authoritative name servers would now be required for setup, one for dreamwave.com and one for each of subdomains, and similarly and total of four authoritative name servers for dreamwave.org.

Figure – zone hierarchy of “Dreamwave” along with DNS nameservers

Zone files :

Zones are configured through what is referred to as zone files, that contain an actual representation of zone, simple configuration files, that declare all resource records for specific zone. A zone file needs to contain an SOA or Start of Authority resource record declaration and Global Time to Live (TTL). This SOA record declares zone and therefore name of name server that’s authoritative for it. Global Time to Live (TTL), states for how records should be kept in local DNS cache. Along with SOA record and TTL, you’ll usually find NS records that indicate other name servers which will even be liable for this zone. The format of zone file is defined in RFC 1035 and 1034.

DNS zone file comprises of directives and resource records.

Directives begin with a $. There are three Directives:

◉ $TTL – Time to Live value for zone.

◉ $ORIGIN – Defines base name -used in domain name substitution

◉ $INCLUDE – Include a file

$TTL directive must be present at top of zone file before SOA record. While talking about zone files, it’s imperative to know about Reverse Lookup Zone.

Reverse Lookup Zone :

A reverse lookup zone contains mapping from an IP address to host (opposite function of most DNS zones). These zones are used for troubleshooting, spam filtering, and bot detection.

Just like how subdomains can go many layers deep, zones are often constructed to have many layers too, a bit like subdomains, although it’s rare to see certain zones deeper than just few levels.