DNS Info Zone DNS What is a Master DNS zone?

What is a Master DNS zone?

Are you reading about DNS? Great! For sure, you are a passionate online business guy. It’s not a simple topic, but it helps a lot to have the whole picture for later defining your business’s real needs and choices. Let’s get a bit of context to understand better the Master DNS zone and its role in the DNS space.

What is the DNS namespace?

Shortly, DNS namespace is the name service supplied by the Internet for organizing networks (TCP/IP). It works in a hierarchical structure that includes different levels where diverse domains exist. On the very top, the root-level domain is. One level down, top-level domains (TLDs) are (.com, .org, .net, .mx, .uk, etc.). After, the second-level domain comes to indicate who (business or organization) registered the domain name. And last, subdomains, the additional domain name’s parts to point specific sections of a domain.

Example of domain name: blog.masterexample.com.

Reading from right to left, the last dot represents the root level.

TLD: .com

Second level domain: .masterexample

Subdomain: blog

This is the DNS namespace structure.

What is a DNS zone? 

A DNS zone is a holder of DNS records and settings that belong to the DNS namespace. This last can host one or multiple DNS zones. Every zone’s management is in charge of a specific DNS host or service. This division in different zones was created for having better control while administrating the space more efficiently.

DNS zones also play a role in the DNS responding process. Whenever a domain is requested, an IP address must be found through a DNS lookup. That can be understood basically as the checking of DNS zones. The request will be directed to the authoritative server that is in charge of the DNS zone that corresponds to the requested domain. Finally, this authoritative server will supply the domain’s IP address, and the request will be responded.

What is a Master DNS zone? 

The Master zone, also called the Primary zone, is a copy of the DNS database with the important abilities to be read and/or written. It is the zone that allows the necessary modifications. From it, all the updates or changes will be distributed to the rest of the network. Not everywhere, just in the Master zone, you or your administrator can add information or make changes in order to keep security and order. 

For instance, when you need to add a DNS record, the place to do it is exactly the Master zone. All changes or updates can usually be done manually or automatically. In case you need to write some new data on your Master zone, the server that contains it must be up. If it is unavailable, modifications are not possible.

This database has the advantage of being saved in .txt. This is a standard text file that makes backing up and recovering simple if needed.

Considering how important is the data the Master zone holds, having a backup is a must. What you need to is to create a Slave or Secondary zone for having a copy. The main and big difference is that the Slave or Secondary zone will store this copy for you, but it won’t be editable.

This DNS process about getting an up-to-date copy of the Master zone to the Slave zone is named zone transfer. You can get updates of copies by configuring your Slave zone/s (server/s) to request it to the Master zone with the frequency you decide.

Besides, the Master zone itself can be set up to notify the Slave zones every time there are changes for getting an updated copy.

Hiding Your Master DNS: Best DNS Practice for Administrators

Hiding your Master DNS is one of the best DNS practices that every DNS administrator should prioritize. By concealing the identity and location of your Master DNS server, you enhance security, protect sensitive information, and mitigate potential attacks. It prevents targeted attacks, unauthorized access, and ensures data integrity. Implementing this practice is crucial for maintaining the overall security and resilience of your DNS infrastructure.

Conclusion

DNS Master zone is a key link of the DNS chain. Important for saving, distributing, and updating vital domains’ data. 

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Post

Anycast DNS

What is Anycast DNS?What is Anycast DNS?

Domain name system (DNS) is a very wide and complex topic. A lot can be said about it, and Anycast DNS is one of the many actors involved in this ‘movie’. DNS is the Internet’s backbone. Without DNS infrastructure, we couldn’t navigate as simply as we currently do. DNS is a context we must have to properly explain Anycast DNS.

What is DNS?

(more…)

Reverse DNS

Reverse DNS: Meaning & ImportanceReverse DNS: Meaning & Importance

Reverse DNS is our topic today. So, in this article we will take a detailed look at what its main purpose is and how to check it. So let’s start.

Reverse DNS – meaning

Here it is – Reverse DNS or rDNS for short. Its goal is to connect an IP address to the domain name with which it is linked. It works in the opposite direction as Forward DNS, with the domain name pointing to the related IP address. DNS hosting firms often offer rDNS as an add-on option. If you do decide to use it, you must also set up a Master Reverse zone and PTR records. Because of them, you will be able to produce proof that the precise IP address and your domain name match.

(more…)

DNS glue records

DNS Glue Records Explained: How They Prevent Delegation LoopsDNS Glue Records Explained: How They Prevent Delegation Loops

DNS delegation tells recursive resolvers which authoritative name servers hold the answers for a domain. Usually, a resolver can look up the address of a delegated name server through ordinary DNS. A problem appears when the name server’s hostname is inside the very domain it serves: the resolver needs the domain’s authoritative server to find the server’s address, but it needs that address to reach the authoritative server.

DNS glue records break this circular dependency. The parent zone supplies the address information needed to contact the child name server along with the delegation. Glue is small, but incorrect or missing glue can make a correctly configured zone unreachable from parts of the Internet.

What is a DNS glue record?

A glue record is an A or AAAA address record placed in the parent-side delegation context for a child name server. It is not a separate DNS record type named “GLUE.” The term describes how the parent supplies address data that helps a resolver follow the referral to the child zone.

Consider a domain delegated to these servers:

example.com.  IN NS  ns1.example.com.
example.com.  IN NS  ns2.example.com.

Both name-server hostnames are inside example.com. Without their addresses, a resolver would have to ask the example.com authoritative servers where ns1.example.com is—but it cannot contact those servers until it knows the addresses. The parent zone avoids the loop by returning the NS referral plus A and, when configured, AAAA data for the child name servers.

This behavior belongs to the wider delegation process. The site’s DNS delegation guide explains how authority moves from a parent zone to a child. The ClouDNS article on DNS delegation provides another practical overview and appears here in the first half of this article.

When glue is required

In-bailiwick name servers

A name server is in-bailiwick when its hostname falls within the delegated namespace. For the delegation of example.com, ns1.example.com is in-bailiwick. The parent needs to provide its address as glue so a resolver can reach it without already resolving data from the child.

Out-of-bailiwick name servers

If example.com uses ns1.dns-provider.net, that server is outside the child domain. A resolver can follow the DNS hierarchy for dns-provider.net independently to find its address. The .com parent of example.com is not authoritative for that external hostname and generally does not need to supply glue for it.

This distinction is important because extra address data in a referral is not automatically authoritative. Resolvers apply bailiwick rules to decide which additional data can be accepted and cached safely.

Glue at the registrar and host records in the child zone

Operators commonly configure glue through a registrar feature named “child name server,” “host object,” “personal nameserver,” or “register nameserver.” This creates or updates the parent-side address association through the registry. It is different from merely adding an A or AAAA record in the domain’s own authoritative zone.

For an in-bailiwick server, both locations matter:

  • Parent-side glue: Lets a resolver reach the child authoritative server during delegation.
  • Child-zone A or AAAA record: Provides the authoritative address answer after the child server is reachable.

The values should be consistent. If the registry glue points to an old address while the child zone publishes a new one, resolvers may reach different servers depending on cached state and lookup path. Update both deliberately during a migration.

The article A record vs AAAA record explains the IPv4 and IPv6 address types used for name-server hostnames.

IPv4 and IPv6 glue

IPv4 glue uses A records, while IPv6 glue uses AAAA records. Publishing both can allow resolvers to reach authoritative service over either protocol, provided the DNS server and network actually work on both addresses.

Do not publish an IPv6 glue address merely because the server has an IPv6 interface. Test authoritative DNS over UDP and TCP on port 53 from outside the hosting network. A broken IPv6 path can introduce delays or intermittent resolution even when IPv4 works correctly.

Common glue-record failures

Glue is missing

The parent delegates to an in-bailiwick hostname but does not include its address. A resolver may be unable to escape the circular dependency, causing timeouts or SERVFAIL responses.

The address is stale

The authoritative server moved, but only the A or AAAA record in the child zone was changed. The parent continues directing resolvers to the old server through cached or live glue.

Parent and child NS sets disagree

The registry delegation lists servers that differ from the NS records served by the child zone. This does not always cause immediate failure, but it creates inconsistent authority and complicates caching and troubleshooting.

The server is reachable but not authoritative

Correct glue only provides an address. If the server at that address does not load the child zone or refuses public queries, the delegation is lame. Test that every listed server answers authoritatively for the domain.

Only one server or network works

Multiple NS names do not provide real redundancy when they resolve to one machine, one network path, or one unavailable location. Glue should describe an authoritative design that is actually reachable and resilient.

How to check DNS glue records

Start with a trace from the root toward the domain:

dig +trace example.com NS

At the parent referral, look for the delegated NS names and the associated A or AAAA records in the additional section. You can also query a parent server directly after identifying it:

dig example.com NS @a.gtld-servers.net
dig ns1.example.com A @a.gtld-servers.net
dig ns1.example.com AAAA @a.gtld-servers.net

The exact parent server depends on the top-level domain. Then query every delegated server directly:

dig example.com SOA @ns1.example.com
dig example.com NS @ns1.example.com
dig +tcp example.com SOA @ns1.example.com

Confirm that each server is reachable over UDP and TCP, returns an authoritative answer, serves the expected SOA serial, and publishes a child-side NS set consistent with the parent delegation.

Safely changing a glued name-server address

  1. Prepare the new server. Load the complete zone and verify authoritative answers before changing delegation data.
  2. Keep the old address active. Parent and resolver caches may retain the old glue until its TTL expires.
  3. Update the child host object. Use the registrar or registry workflow to change the parent-side glue.
  4. Update the child-zone address record. Make the A or AAAA record for the name server consistent with the new address.
  5. Query the parent and child separately. Do not rely on a single recursive resolver or control-panel display.
  6. Monitor during the cache window. Check availability, authoritative responses, and error rates from multiple networks.
  7. Retire the old server only after verification. Allow enough time for cached referrals to expire.

If the servers use primary-to-secondary replication, also verify that zone synchronization continues after the address change. The article DNS Zone Transfers Explained covers AXFR, IXFR, and secure peer configuration.

Glue records and DNS security

Glue is necessary routing information, but it is not a substitute for DNSSEC, secure registrar access, monitoring, or server hardening. Protect the registrar account because unauthorized changes to host objects or delegation can redirect resolution. Use multi-factor authentication and change controls where available.

The parent-child delegation model and the reason address records may be required in referrals are described in RFC 1034, Section 4.2.1.

Conclusion

DNS glue records solve a specific circular dependency: they give resolvers the address of an in-bailiwick authoritative name server before the child zone can be reached. Reliable operation depends on consistent parent glue and child-zone address records, reachable authoritative servers, correct NS sets, and careful migration timing. A trace and direct queries to both parent and child servers are the fastest way to verify the complete delegation path.