In order to understand why BIND administrators want this functionality, we'll spend some time explaining what BIND Views offer, what Windows offers, and how they differ. Then we'll look at an example to try and help bring it all together.
What is DNS Views/BIND Views?
BIND Views is a feature of BIND that allows you to create records with a configuration such that, when the name server responds to a lookup, it will return the IP address of the host relative to the configuration of the "view". To be more specific, you can make BIND provide network-specific IP address answers based off of the requester's IP address.
Why would you want to do this?
Let's say you have a web farm across a global enterprise and you have a corporate web portal that is rather complex. Instead of simply pointing everyone to http://www.randomcorpname.com/, you decide that you want to use a moniker like "my.randomcorpname.com". This "my" moniker configured as a "view" in BIND can default to the Hong Kong web farm and specific portion of the portal for it's Hong Kong users, the San Francisco portion of the portal and web farm for the San Francisco users, and London portion of the portal and web farm for the London users -- simply by users at each location typing in the same value: "my.randomcorpname.com."
Can you perform this same action in Windows DNS?
The answer is a mixed-bag of yes and no:
The short answer is Windows netmask ordering.
How do BIND Views and Windows netmask ordering differ?
In BIND Views, you can create View records that define network-by-network who will recieve what IP address as an answer. The configuration of the networks can be any number of network addresses across any number of different classes of network (A,B,C, etc.)
In Windows netmask ordering, the DNS server gets configured to "look" at a particular set of bits on the network mask of the requestor, and then provide the appropriate A-record relative the class configuration of the DNS server and there being an A-record for the hostname with that same "class-value" of the requester existing in DNS. By default, Windows DNS defaults to a "Class-C"-style matching.
Let's look at an example:
We'll shift our example using BIND above to the internal enclave since Windows netmask ordering would be so painful to manage in the same fashion as described above and because I'd never have a Windows DNS server on a non-internal boundary of my network. So in our shifted example, we are a sprawling company with offices all over the world. We have a portal website where we want people being directed to specific servers/farms based off of their location in the world but each location have the ability to use the same moniker to access the intranet portal: intranet.randomcorpname.local.
Hostname/A-Record, IP Address
hk-web01.randomcorpname.local., 10.0.1.11
hk-web02.randomcorpname.local., 10.0.1.12
sf-web01.randomcorpname.local., 10.1.1.11
sf-web02.randomcorpname.local., 10.1.1.12
lon-web01.randomcorpname.local., 10.2.1.11
lon-web02.randomcorpname.local., 10.2.1.12
Additional A-Records for Netmask Ordering
intranet, 10.0.1.11
intranet, 10.0.1.12
intranet, 10.1.1.11
intranet, 10.1.1.12
intranet, 10.2.1.11
intranet, 10.2.1.12
In this example and in most medium-to-large networks, the default configuration for netmask ordering in Windows DNS will not work for proximity-based resolution because you typically segregate clients/workstations by subnet. Any machines that are NOT on the same /24 as the web server, will ignore netmask ordering and proceed to just round-robin. In our example with the current IP configuration, you would need to adjust the netmask ordering mask from the default Class-C to a Class-B (or something in between) in order to make this work.
If we were to adjust the netmask ordering mask of our DNS servers to a Class B (0x0000ffff), then our Windows DNS server would properly respond as desired. In our example with our Windows DNS server configured with a netmask ordering mask set to 0x0000ffff, then a client in Hong Kong (let's say, 10.0.2.10) who does a lookup on "intranet" will properly round-robin between 10.0.1.11 and 10.0.1.12. Similarly, a client with address 10.2.2.10 (London), will appropriately round-robin between 10.2.1.11 and 10.2.1.12.
Notice that we've changed the comparison of the third octet (Class-C) to the second octet (Class-B). Also notice how static this configuration is and how dependent it is upon a very strict and consistent IP addressing scheme.
Relevant Command-Line Utilities/Commands to Netmask Ordering:
References:
What is DNS Views/BIND Views?
BIND Views is a feature of BIND that allows you to create records with a configuration such that, when the name server responds to a lookup, it will return the IP address of the host relative to the configuration of the "view". To be more specific, you can make BIND provide network-specific IP address answers based off of the requester's IP address.
Why would you want to do this?
Let's say you have a web farm across a global enterprise and you have a corporate web portal that is rather complex. Instead of simply pointing everyone to http://www.randomcorpname.com/, you decide that you want to use a moniker like "my.randomcorpname.com". This "my" moniker configured as a "view" in BIND can default to the Hong Kong web farm and specific portion of the portal for it's Hong Kong users, the San Francisco portion of the portal and web farm for the San Francisco users, and London portion of the portal and web farm for the London users -- simply by users at each location typing in the same value: "my.randomcorpname.com."
Can you perform this same action in Windows DNS?
The answer is a mixed-bag of yes and no:
- Is the robustness of BIND Views identical in Windows? No.
- Is it even close? No.
- Can I perform similar, network-centric DNS answers using Windows DNS? Yes -- Windows actually does this by default on Windows 2003 DNS servers and beyond but for it to work properly, your network has to be IP'd in such a way to support it or Windows DNS will simply default to round-robining.
The short answer is Windows netmask ordering.
How do BIND Views and Windows netmask ordering differ?
In BIND Views, you can create View records that define network-by-network who will recieve what IP address as an answer. The configuration of the networks can be any number of network addresses across any number of different classes of network (A,B,C, etc.)
In Windows netmask ordering, the DNS server gets configured to "look" at a particular set of bits on the network mask of the requestor, and then provide the appropriate A-record relative the class configuration of the DNS server and there being an A-record for the hostname with that same "class-value" of the requester existing in DNS. By default, Windows DNS defaults to a "Class-C"-style matching.
Let's look at an example:
We'll shift our example using BIND above to the internal enclave since Windows netmask ordering would be so painful to manage in the same fashion as described above and because I'd never have a Windows DNS server on a non-internal boundary of my network. So in our shifted example, we are a sprawling company with offices all over the world. We have a portal website where we want people being directed to specific servers/farms based off of their location in the world but each location have the ability to use the same moniker to access the intranet portal: intranet.randomcorpname.local.
Hostname/A-Record, IP Address
hk-web01.randomcorpname.local., 10.0.1.11
hk-web02.randomcorpname.local., 10.0.1.12
sf-web01.randomcorpname.local., 10.1.1.11
sf-web02.randomcorpname.local., 10.1.1.12
lon-web01.randomcorpname.local., 10.2.1.11
lon-web02.randomcorpname.local., 10.2.1.12
Additional A-Records for Netmask Ordering
intranet, 10.0.1.11
intranet, 10.0.1.12
intranet, 10.1.1.11
intranet, 10.1.1.12
intranet, 10.2.1.11
intranet, 10.2.1.12
In this example and in most medium-to-large networks, the default configuration for netmask ordering in Windows DNS will not work for proximity-based resolution because you typically segregate clients/workstations by subnet. Any machines that are NOT on the same /24 as the web server, will ignore netmask ordering and proceed to just round-robin. In our example with the current IP configuration, you would need to adjust the netmask ordering mask from the default Class-C to a Class-B (or something in between) in order to make this work.
If we were to adjust the netmask ordering mask of our DNS servers to a Class B (0x0000ffff), then our Windows DNS server would properly respond as desired. In our example with our Windows DNS server configured with a netmask ordering mask set to 0x0000ffff, then a client in Hong Kong (let's say, 10.0.2.10) who does a lookup on "intranet" will properly round-robin between 10.0.1.11 and 10.0.1.12. Similarly, a client with address 10.2.2.10 (London), will appropriately round-robin between 10.2.1.11 and 10.2.1.12.
Notice that we've changed the comparison of the third octet (Class-C) to the second octet (Class-B). Also notice how static this configuration is and how dependent it is upon a very strict and consistent IP addressing scheme.
Relevant Command-Line Utilities/Commands to Netmask Ordering:
- dnscmd /Info /LocalNetPriorityNetmask
- dnscmd /Config /LocalNetPriorityNetmask 0x0000ffff
References:
Would this method also work for specifying a forwarder DNS server for certain domains/zones based on the requester IP? Currently we use BIND view feature to define several views, based on originating subnets, to redirect some of the subnets (from an "island network") to internal corporate DNS servers (which is an 'outside network' to all of our subnets, separated by a DMZ). So basically, one view redirects queries for www.corp.com to internal corporate DNS servers, while another view will redirect queries for the same domain to a public Internet DNS server. Looking for a way to accomplish the same setup with Microsoft DNS... Thanks!
ReplyDeleteIn SEO Class C checker, a user can discover whether or not the same class C IP range is hosting two or more domains.class c ip checker
ReplyDelete