Hot Downloads

Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: DNS zones vs domains

DNS zones vs domains 7 years 4 months ago #30362

  • KiLLaBeE
  • KiLLaBeE's Avatar
  • Offline
  • Expert Member
  • Posts: 466
  • Karma: 0
In the context of Microsoft DNS, how is a DNS zone different from a DNS domain and why would I want to use a domain when I can use a zone for the same purpose? I've learned most of the detailed information about Microsoft DNS but I'm still unclear on "domains vs zones."

For example, if I create a zone called "zone.com" and I later want to create a subdomain for that zone, I can either create a completely new zone called "subdomain.zone.com" or I can just right-click the "zone.com" zone on DNS Manager and choose New Domain" and then name the new domain "subdomain." Why would I want to use one method over the other? When is it best to use one method over the other? Does one method have functionality that the other one doesn't?

I know that you would typically create a new zone for a subdomain if you wanted to delegate the zone elsewhere, control dynamic updates, control replication. Are these really the only benefits? Is name resolution different?

Thanks for your time
The administrator has disabled public write access.

Re: DNS zones vs domains 7 years 4 months ago #30364

  • FallenZer0
  • FallenZer0's Avatar
  • Offline
  • Senior Member
  • Posts: 259
  • Karma: 0
I've learned most of the detailed information about Microsoft DNS but I'm still unclear on "domains vs zones."

Hi,

A Zone in its simplest definition is a portion of the DNS Namespace. Let us consider an example.

killabee.firewall.cx

Keeping aside the type of resolution being implemented, the DNS Resolver is supplied with a list of addresses for the root name servers.

The resolver queries one of the root name servers for the namespace killabee.firewall.cx in the Root Zone indicated by a Period at the end of the DNS Namespace killabee.firewall.cx. but the root zone(.) does not directly contain that record. The root zone (.) contains referrals to the authoritative name servers for the Top Level Domains (TLD's) like com, org, net and in our example, the cx Zone.

Next we query one of the name servers authoritative for the cx zone to resolve killabee.firewall.cx , but the cx zone still does not directly contain that record. Just like the root zone, the cx zone contains referrals to the authoritative name servers for the each individual "cx" domain, including the firewall.cx We then receive a referral to the name server responsible for the firewall.cx Zone and the process continues.

I hope you see that a Zone is nothing more than a part of the global DNS Namespace.

If there are no sub-domains, then essentially the Zone and the Domain are one and the same.

Cheers
FallenZer0
-There Is A Foolish Corner In The Brain Of The Wisest Man- Aristotle
The administrator has disabled public write access.

Re: DNS zones vs domains 7 years 4 months ago #30366

  • sose
  • sose's Avatar
  • Offline
  • Honored Member
  • Posts: 813
  • Thank you received: 4
  • Karma: 3
fallenzer0 has spoken my mind

but this will also help

Humans like to use easily remembered names (FQDN), whereas digital machines such as computers like to use numbers (IP addresses). DNS is simply the go-between, allowing us to enter a name into a Web browser’s address bar or e-mail address instead of a cryptic number. For example, I want to go to www.abuzaria.com. Let’s follow the steps of how my Web browser accomplishes that:


I type www.abuzaria.com in the Web browser.


The Web browser then asks the resolver (a background client DNS application that resolves FQDNs to IP addresses) to convert www.abuzaria.com into an IP address.


The resolver first checks the host’s file and the local cache to see if the FQDN/IP address combination is available. If it is, the resolver passes the IP address to my computer’s network protocols to set up a connection. If not, it starts zonal checks :the resolver contacts the name server at my ISP, asking it for the IP address of www.abuzaria.com.



If the ISP’s name server has that information in its cache, it will immediately return the IP address to the resolver, which once again sets up a connection. One important term that we need to understand is recursive name server. It’s simply a name server such as my ISP’s that relies on other name servers for authoritative answers.



If not found, my ISP’s name server takes over looking for the www.abuzaria.com name server by querying what are called authoritative name servers. To explain, the three components of the FQDN www.abuzaria.com determine the order of the authoritative name servers queried. Com is the top level of this particular name, so the search starts there; the next level is abuzaria, and finally www. (zone by zone)





First, my ISP’s name server queries the root name server (authoritative for .com, .net, etc). The root name server returns the IP address for the appropriate .com name server to my ISP’s name server.



Next, my ISP’s name server queries the .com name server (authoritative for name servers in the .com domain) for the IP address of the abuzaria.com name servers. The .com name server returns the appropriate IP addresses to my ISP’s name server.


Now my ISP’s name server queries abuzaria.com name server for the IP address associated with www.abuzaria.com.


Finally, my ISP’s name server has the required IP address, sending it to the resolver application on my computer so it can establish a connection.


Once connected, the Web server will send the specified Web pages back for display on my Web browser.


That seems like a great deal of back and forth just to get the IP address of a Web site.

Thankfully, these transactions take only milliseconds due to several features incorporated in the DNS protocol.


fallenzer0

we hope to see more of your contributions in subsequent times


sose
the operating system is thesame whereever you go
sose
Network Engineer
analysethis.co/index.php/forum/index
The administrator has disabled public write access.

Re: DNS zones vs domains 7 years 4 months ago #30391

  • KiLLaBeE
  • KiLLaBeE's Avatar
  • Offline
  • Expert Member
  • Posts: 466
  • Karma: 0
Below are two screen shots (or maybe just links to screen shots if the Img tag doesn't work) that show what I mean.

Both screen shots show you Windows Server 2003's DNS Manager, the properties of a Host (A) record, and a command prompt with the NSLOOKUP command issued.

On the first screen shot, shown below, you'll see that I have a zone called "zone.com" with a subdomain called "subdomain." In the subdomain, I have a Host (A) record with the shown IP address. Notice the Host (A) record's FQDN while it is under a subdomain. When I issue the NSLOOKUP command for the FQDN of the Host (A) record, it resolves to the IP address it is assigned as expected and without any issues.



On the second screen shot, shown below, you'll see that I still have the zone "zone.com," but I also have an additional zone called "subdomain.zone.com" created, also with a Host (A) record's properties displaying its assigned IP address. Notice that the Host (A) record's FQDN is the same as it was under screen shot 1. When I issue the NSLOOKUP command for the FQDN of the Host (A) record, it also resolves just fine and without issues.


This leads me to my question: If both "features" allow the records to resolve the same, then why would I choose to store a record in a "zone" when I can store it in a "domain"? I know that there are advantages to using a zone for a subdomain rather than an actual "domain" (I list them on my first post). I also know that when you have a zone, you actually have a separate DNS text file that represents that zone, whereas when you have a subdomain of a zone, that subdomain is represented WITHIN that zone text file.

I guess what I'm really asking is for confirmation that a zone offers just those the benefits I initially listed and nothing more. Sorry for making my original post sound as if I was asking for the procedure on name resolution.

Thanks for your continued assistance
The administrator has disabled public write access.

Re: DNS zones vs domains 7 years 4 months ago #30393

  • Smurf
  • Smurf's Avatar
  • Offline
  • Moderator
  • Posts: 1390
  • Karma: 1
Thats quite interesting, wouldn't have thought that it would work the second way but clearly it does.

Anyhow, the only thing that i would say is that it probably only works because its on the same server as the root zone, what happens if you try putting it onto a different DNS server ? I would guess that resolution wouldn't work because you need to create a delegation to it in the original zone so it would know where to forward requests to.
Wayne Murphy
Firewall.cx Team Member
www.firewall.cx

Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
The administrator has disabled public write access.

Re: DNS zones vs domains 7 years 4 months ago #30443

  • FallenZer0
  • FallenZer0's Avatar
  • Offline
  • Senior Member
  • Posts: 259
  • Karma: 0
This leads me to my question: If both "features" allow the records to resolve the same, then why would I choose to store a record in a "zone" when I can store it in a "domain"?

Here it is. . . . . . . .

example: www.firewall.cx

www, is simply the CNAME or the Host Name of a Server, which has been assigned an IP address in the Zone/Domain firewall.cx

Consider, sales.firewall.cx Now, here the Zone, firewall.cx has all the records for the Zone firewall.cx and also a record that would point to the Name Server responsible for the Zone sales.firewall.cx.

The Name Server for the Zone sales.firewall.cx has records for the resources in its zone, in the Naming scheme of the DNS Name Space called a Domain.

It should be clear that a Zone is simply a portion of the overall DNS Namespace aka, Domain.

Cheers
FallenZer0

//Edit:

If you look carefully the 2 screen shots above, one can see that in the screen shot 1, abc is a resource in the FQDN, subdomain.zone.com,

but, take a look at screen shot 2,. . . . . zone.com and subdomain.zone.com appears to be 2 completely different domains. You can see they are simply two different domain names that have a forward look up zones set up and under the subdomain.zone.com, domain there exists a resource called "abc" which is completely a different resource compared to the resource in the screen shot 1.

I hope you are able to see the above differences which are very clear.

Keep both the screen shots next to each other and you can clearly see what I am talking about. Infact, the two are not the same as you say.
-There Is A Foolish Corner In The Brain Of The Wisest Man- Aristotle
The administrator has disabled public write access.
  • Page:
  • 1
  • 2
Time to create page: 0.091 seconds

CCENT/CCNA

Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V

Linux

  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup