- Posts: 466
- Thank you received: 0
DNS zones vs domains
15 years 6 months ago #30362
by KiLLaBeE
DNS zones vs domains was created by KiLLaBeE
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
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
- FallenZer0
- Offline
- Premium Member
Less
More
- Posts: 259
- Thank you received: 0
15 years 6 months ago #30364
by FallenZer0
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
Replied by FallenZer0 on topic Re: DNS zones vs domains
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
15 years 6 months ago #30366
by sose
sose
Network Engineer
analysethis.co/index.php/forum/index
Replied by sose on topic Re: DNS zones vs domains
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
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
15 years 6 months ago #30391
by KiLLaBeE
Replied by KiLLaBeE on topic Re: DNS zones vs domains
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
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
15 years 6 months ago #30393
by Smurf
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.
Replied by Smurf on topic Re: DNS zones vs domains
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.
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.
- FallenZer0
- Offline
- Premium Member
Less
More
- Posts: 259
- Thank you received: 0
15 years 5 months ago #30443
by FallenZer0
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
Replied by FallenZer0 on topic Re: DNS zones vs domains
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
Time to create page: 0.136 seconds