A DNS zone is a specific part of a domain’s namespace that is assigned to one legal entity, be it a person, company, or organization. This legal entity will be responsible for managing the zone. Understanding DNS zones is very much needed and you must be able to make a decision about what type of zone you must use.
Zone domain meaning
A zone can be defined as a part of a domain for which an individual DNS server is responsible for. It is part of the hierarchical layout of domains. It is used primarily to give different people authority over different parts of your domain. A DNS zone is usually defined in a zone file. A Zone ID is usually a long string of numbers and characters that represent a zone. Zone domain registration can be easily done as per your need.
Types of zone
Knowing the types of zones and what are the differences between them is important. Knowing when to use a Stub zone, a Conditional Forwarder, a secondary zone, or a Forwarder is crucial. This will let you alter the amount of control you give to the manager over your zone.
These secondary zones are copies of a master zone that are either “copied” or “zone transferred”. These copies are read-only and the manager will not be able to alter them. Instead of having to access the DNS server every time over a WAN link, the manager will be able to have the zone data available locally. Secondary zones are the least used type of zones. This is because secondary zones have many limitations. The main reason for avoiding this type of zone is that you might expose all of your DNS zone data in a secondary zone, this is not good for partners who want to keep a part of their DNS zone data private. These secondary zones also cannot be integrated with AD and all the zone data is stored in a text file. This would mean you must manually transfer individual copies to each one of your DNS servers.
This is one of the most commonly used zone options. This is the best option for people concerned with the security of their data as no data is exposed to your partners. This makes this zone ideal for many environments and scenarios.
With a conditional forwarder zone, none of your information will be transferred or shared with your partner. A conditional forwarder only requires you to know your business partner’s DNS server IPs so that you will be able to configure it. Your business partner does not even have to be the SOA, they could very well be any DNS server who is hosting the zone or has a reference to the zone. That said, there does need to be open communication between you and your partners and you must each know when the IPs of your DNS servers might change. This is required as you need to manually set them up.
Conditional forwarders were introduced in Windows 2003, but they did not have AD integration option. This would mean that if you had a 100 DNS servers, you will have to create a conditional forwarder for each one of those servers manually. The option to AD integrate was introduced to DNS conditional forwarders in Windows 2008. This would mean you will no longer have to create conditional forwarders for each server manually, thus conditional forwarders will be available all over the domain or forest-wide.
Many organizations have their own AD zones. If a business forwarder wants to resolve data at the domain of a partner’s organization, there are very few options to handle such requests. Before Windows 2003, the only way you could do it was if you created secondary zones and stored copies of each other’s zone using zone transfers. While this does do the task, it has serious limitations security-wise. You would need to trust your partner completely as you will be revealing all your data to him when you use secondary zones. Many businesses did not prefer this option as it exposed their data to their partner and you won’t be able to know what they are doing with your data. The other major concern is that if this data gets leaked to the public, your domain will be filled with malicious attackers.
With the introduction of stub zones and conditional forwarders, it was possible to overcome this major security breach. Stubs also have AD integration, thus you won’t have to manually create a stub for each of your servers. This makes stub zones a much wiser choice than secondary zones.
The only concern with stub zones is that the zone file contains the SOA and NS data records, this might lead to them being exposed to your partners. If you have really high-security standards, you will be better off using conditional forwarders rather than stubs.
Parent-Child DNS Zone Delegation
This kind of delegation is used when a child domain is hosting its own DNS server. Thus in a forest root domain, you will create a delegation zone that contains all the IPs of the DNS servers that are hosted in the child domain. This is usually performed when the child domain has its own administrator. This is mostly used as it will prevent these child domain administrators from being able to view all of the records in your forest root DNS.
Before you choose a type of zone for your partner, make sure that you understand your security needs and choose appropriately.