Name resolution no longer had to return the same answer to everyone
DNS normally appears straightforward. A computer asks for the address associated with a name, and a DNS server returns the appropriate record. From the client’s perspective, the process can seem like a simple lookup.
Real networks are more complicated. An organization may have servers in several locations, separate internal and external networks, multiple copies of an application, or resources that should be available only to particular clients. Returning exactly the same DNS information to every request is not always the best approach.
DNS Policy in Windows Server introduced a way to make the server’s response depend on defined conditions. Instead of treating every query identically, administrators could create rules controlling how different requests were processed.
The answer to a DNS request could depend on characteristics of the query rather than only on the name being requested.
A DNS Query Contained More Than a Name
When a DNS server receives a request, the requested hostname is obviously important, but it is not the only information available to the server. The request also arrives from a particular client and through a particular server interface. Other conditions can also be considered when policies are applied.
DNS Policy made those characteristics useful for controlling name resolution.
A policy could distinguish requests according to the network from which the client originated.
The interface receiving a query could help distinguish internal requests from external ones.
Policies could evaluate characteristics such as the requested name and query type.
These conditions gave administrators a way to determine not merely whether the server knew an answer, but which answer or behavior was appropriate for a particular request.
One Zone Could Have More Than One View
A traditional DNS zone contains the records associated with a domain. If an organization needed substantially different versions of those records for different groups of users, maintaining the arrangement could become complicated.
Zone scopes provided another possibility. A DNS zone could contain multiple scopes, and each scope could hold its own collection of records.
A zone scope is a separate instance of records within a DNS zone. Different scopes can contain different information for the same DNS names, allowing policies to determine which collection of records should answer a request.
This meant that the same hostname could exist in more than one scope with different IP addresses.
Internal and External Clients Could Receive Different Answers
One of the clearest uses for this capability was split-brain DNS. An organization might use the same domain name internally and externally while needing different DNS information for each environment.
For example, an internal user might need a hostname to resolve to a private address that is reachable only from the company network. Someone on the Internet requesting the same hostname might need the public address instead.
Internal request
A query arriving from the organization’s private network can be directed to a zone scope containing internal DNS records.
External request
The same hostname requested from outside the organization can receive the public record intended for Internet clients.
The hostname does not have to change. The policy determines which DNS data is appropriate for the requesting client.
DNS policies and zone scopes allowed internal and external versions of a zone to be hosted on the same Windows DNS server in supported configurations.
The Client’s Network Could Influence the Response
Client subnets gave DNS administrators another useful condition. If the server could identify the network associated with a request, a policy could select a response appropriate for that network.
This made location-aware name resolution possible. Organizations operating resources in different geographical regions could direct clients toward a nearby copy of an application or service.
A computer requests the address associated with a DNS name.
Configured policy criteria are compared with information associated with the incoming query.
The server determines which scope or response rules apply to that request.
The client receives DNS information selected for the conditions that matched.
DNS could therefore participate in traffic management without requiring the application itself to make the initial routing decision.
Several Application Servers Could Share the Requests
Applications are often deployed on more than one server for capacity or availability. DNS Policy could help distribute clients among different application instances by controlling the records returned from zone scopes.
This was not the same as inspecting every packet after a connection had been established. DNS operated earlier, when the client was determining which address to contact.
Once a client received an address and connected to it, DNS was no longer carrying the application traffic. Its role was to help determine which destination the client attempted to reach.
That distinction matters because DNS-based traffic management behaves differently from a dedicated load balancer sitting directly in the application traffic path.
Time Could Become Part of the Decision
Policy conditions were not limited to network location. DNS behavior could also be influenced by time, allowing different resources to be returned during different periods.
An administrator might have multiple application locations and want the preferred destination to change according to a schedule. Instead of manually rewriting DNS records each time, policies could define how queries should be handled during particular periods.
Queries can favor one set of DNS resources.
The applicable rule changes as the configured time conditions change.
Queries can be answered using another intended resource or distribution.
The DNS data could remain organized while policy controlled when particular responses were selected.
Policies Could Also Restrict DNS Behavior
Choosing between valid answers was only one use for DNS Policy. Rules could also control how the server handled requests that should not be processed normally.
Query filtering allowed administrators to define conditions under which DNS requests were allowed or denied. This could help control unwanted queries and provide more precise behavior than treating every requester the same way.
- Differentiate requests by client subnet
- Distinguish queries arriving on different server interfaces
- Select records from different zone scopes
- Control responses for particular DNS names or query types
- Apply different behavior according to defined policy conditions
The result was a DNS server that could make decisions according to administrator-defined rules rather than relying on one universal response path.
Recursion Could Be Available to Some Clients but Not Others
A DNS server may answer authoritative queries for domains it hosts while also performing recursive lookups for clients that need names elsewhere on the Internet. Allowing unrestricted recursion to external users, however, can turn a server into an open resolver.
DNS Policy provided a way to separate those roles more carefully. Recursion scopes and policies could permit recursive resolution for trusted internal clients while preventing external clients from receiving the same service.
Policy-based recursion control allowed administrators to distinguish between clients that should receive recursive name resolution and those that should not.
This was especially useful when the same DNS server had to serve both private and public-facing responsibilities.
The Same DNS Infrastructure Became More Flexible
Before policy-driven responses, some DNS designs required additional servers or separately maintained zones simply because different clients needed different answers. The DNS information itself was not necessarily difficult to create. The challenge was keeping the different views separated and directing clients to the correct one.
Zone scopes and query-resolution policies changed that arrangement.
| Requirement | Policy-based approach |
|---|---|
| Different internal and external records | Use separate zone scopes with policies selecting the appropriate scope |
| Direct clients according to network location | Use client subnet criteria |
| Return different resources at different times | Apply time-based query policies |
| Control which clients receive recursion | Use recursion scopes and recursion policies |
| Filter selected DNS requests | Apply query policies matching the required conditions |
Not every DNS deployment required these capabilities. For a small network with simple name resolution, ordinary zones and records could remain sufficient. The value appeared when the same DNS infrastructure had to serve clients with different requirements.
DNS Changed From a Lookup Table Into a Decision Point
The fundamental job of DNS remained the same. Clients still needed names translated into information that allowed them to locate network resources. What changed was the amount of control available before the server returned that information.
A query could be evaluated against policy conditions, matched with an appropriate scope, and answered according to where the client was located or how the administrator wanted that class of request handled.
DNS Policy gave Windows Server administrators a way to make name resolution responsive to network conditions and administrative rules. The same DNS name could lead different clients toward different resources without requiring every situation to be divided across completely separate DNS servers.
That made DNS more than a static directory of names and addresses. In larger networks, it could become an active part of deciding how clients reached the resources intended for them.
