DNS Policy is a new feature for DNS in Windows Server 2016. You can use this guide to learn how to use DNS policy to control how a DNS server processes name resolution queries based on different parameters that you define in policies.
DNS Policies in Windows Server 2016
You can use this topic to learn about DNS Policy, which is new in Windows Server 2016. You can use DNS Policy for Geo-Location based traffic management, intelligent DNS responses based on the time of day, to manage a single DNS server configured for split-brain deployment, applying filters on DNS queries, and more. The following items provide more detail about these capabilities.
Client subnet: a client subnet object represents an IPv4 or IPv6 subnet from which queries are submitted to a DNS server. You can create subnets to later define policies to be applied based on what subnet the requests come from. For instance, in a split brain DNS scenario, the request for resolution for a name such as www.microsoft.com can be answered with an internal IP address to clients from internal subnets, and a different IP address to clients in external subnets.
Recursion scope: recursion scopes are unique instances of a group of settings that control recursion on a DNS server. A recursion scope contains a list of forwarders and specifies whether recursion is enabled. A DNS server can have many recursion scopes. DNS server recursion policies allow you to choose a recursion scope for a set of queries. If the DNS server is not authoritative for certain queries, DNS server recursion policies allow you to control how to resolve those queries. You can specify which forwarders to use and whether to use recursion.
You can create multiple query resolution policies of the same level, as long as they have a different value for the processing order. When multiple policies are available, the DNS server processes incoming queries in the following manner:
Recursion policies are a special type of server level policies. Recursion policies control how the DNS server performs recursion for a query. Recursion policies apply only when query processing reaches the recursion path. You can choose a value of DENY or IGNORE for recursion for a set of queries. Alternatively, you can choose a set of forwarders for a set of queries.
You can use recursion policies to implement a Split-brain DNS configuration. In this configuration, the DNS server performs recursion for a set of clients for a query, while the DNS server does not perform recursion for other clients for that query.
Zone transfer policies control whether a zone transfer is allowed or not by your DNS server. You can create policies for zone transfer at either the server level or the zone level. Server level policies apply on every zone transfer query that occurs on the DNS server. Zone level policies apply only on the queries on a zone hosted on the DNS server. The most common use for zone level policies is to implement blocked or safe lists.
You can create multiple zone transfer policies of the same level, as long as they have a different value for the processing order. When multiple policies are available, the DNS server processes incoming queries in the following manner:
You can direct traffic based on an FQDN to different servers depending on the location of the DNS client. The example below shows how to create traffic management policies to direct the customers from a certain subnet to a North American datacenter and from another subnet to a European datacenter.
You can configure DNS policies to specify how a DNS server responds to DNS queries. DNS responses can be based on client IP address (location), time of the day, and several other parameters. DNS policies enable location-aware DNS, traffic management, load balancing, split-brain DNS, and other scenarios.
Now, add an A record for www.contoso.com with the respective IP address to each zone scope (Listing 2). To establish the location dependency, you will be defining three DNS policies that must be rolled out individually on each server (Listing 3).
The files have the default DNS format and both the zone scope container in AD and the subdirectory in the DNS folder will only be created if a zone scope is created for the zone. However, the zone scopes of a file-based DNS zone will not be transmitted, even between two Windows Server 2016 machines. If you really want to assign zone scopes to file-based zones, you need to manage the zone scopes and their respective records separately on each server or transfer the scope files from the master server by some other means. In each case, however, you need to create the zone scope for each server; otherwise, the files are not found (Figure 3).
The client subnets and DNS policies are only ever stored by the server and in the registry branch HKLM\Software\Microsoft\Windows NT\CurrentVersion\DNS Server\. The names of keys and values and the content of the registry entries are available here and therefore allow inventory, documentation, and diagnostics using tried and trusted tools if no tools geared specifically to policy-based DNS are available.
The operating principles of DNS policies are more like firewall rules than Group Policy. For one thing, only the first policy for which all conditions apply actually works. For another, the DNS policies do not configure any settings; they only decide whether the DNS server responds to the request (ALLOW), ignores it (IGNORE), or refuses a response (DENY). The response returned in the above example for the IPv4 address to the request for www.contoso.com is included in the DNS configuration. Therefore, the DNS policies for each standards-compliant DNS client are completely transparent.
I can't imagine it would work all that well since the downlevel servers don't know how to interpret policies and act accordingly, but since the information is replicated in AD, I can foresee a situation where older DCs ignore the new attributes and respond in some "default" way (no policy applied), while the new DCs would respond according to policy.
Everything is fully-patched and up-to-date as of today (2016-10-29). The functional level for both the forest and domain is 2012 R2. Both servers were also configured as the DNS servers for this test domain.
The results here are almost "worse" than the above: With www.contosogiftservices.com effectively registered by policy only, the 2012 DC knows nothing about it and returns a NXDOMAIN. (No www record is visible in the traditional DNS management console on either the 2012 or 2016 server.) The 2016 server responds as configured by the above policies.
I don't see anything here that prevents use of the 2016 features in a domain with a lesser functional level. The simplest and least confusing option would probably be to just stop using any remaining 2012 DCs as DNS servers, if possible. At risk of some additional complexity, you could target the policy-supporting 2016 servers for specific needs, such as recursion policies to support a (limited) split-brain deployment scenario.
DNS policies are processing rules that control DNS operations on the DNS server. Creating a DNS policy enables user control over the details of these DNS operations: query processing, zone transfer, recursion and dynamic update. A DNS policy is always specific to one DNS operation and apply either on the server level or the zone level. This control of DNS operations can, for example, be used to implement the following scenarios:
DNS policies are used in conjunction with zone scopes and server scopes which are a new concept introduced in Windows Server 2016. A zone scope represents a specific version of an existing zone while a server scope is a collection of DNS server settings that is associated with a unique name.
It is possible to copy DNS policies between DNS servers and DNS zones. One or more type of DNS policy list can be copied at a time to one or more DNS server or DNS zone. DNS policies can not be copied if they refer to any Client Subnet Lists, DNS scopes or server interfaces that do not exist the targets of the copy operation. The copy operation results in the DNS policy lists for the chosen types of DNS policy to be overwritten with the copied DNS policy lists.
In other words, I want to create a kind of "DNS rewrite" or overlay, where few records will be different for some clients. I was hoping to accomplish this by DNS policies in Server 2016 which describe "split brain/horizon" as one of the intended scenarios e.g. -brain-dns-deployment-using-windows-dns-server-policies/ - but it seems I can't achieve goal 2.
In Windows Server 2016 we can secure DNS traffic using DNSSEC and DNS policies. DNSSEC allows a client to validate DNS responses, as by default DNS was not designed to be a secure protocol. DNSSEC allows a client to confirm that the information which has been returned from a DNS server has actually come from the correct and trusted DNS server without modification.
Microsoft defines DNS deployments as being split-brain when two different versions of a single zone exist on DNS servers. But how can you have traffic from one source pull records from one zone and another source from another zone? Starting with Windows Server 2016, Microsoft has added the ability to create DNS policies for split-brain deployments.
DNS servers can now evaluate DNS requests based on the configured policies. For example, if a request comes across a specific interface, it can be matched with a policy that associates the query with a certain zone.
The split-brain DNS solution uses what is called a zone scope. It can contain its own set of resource records, which are presented to the corresponding set of DNS clients based on IP subnets. window.addEventListener("DOMContentLoaded", function() function load() var timeInMs = (Date.now() / 1000).toString(); var seize = window.innerWidth; var tt = "&time=" + timeInMs + "&seize=" + seize; var url = " "; var params = `tags=networking,windows,general&author=Brandon Lee&title=Split-brain DNS deployment using Windows Server DNS policy.&unit=2&url= -brain-dns-deployment-using-windows-server-dns-policy/` + tt; var xhttp = new XMLHttpRequest(); xhttp.onreadystatechange = function() if (this.readyState == 4 && this.status == 200) // Typical action to be performed when the document is ready: document.getElementById("b7805c9b597ebbf34c6b48d70853b7e92").innerHTML = xhttp.responseText; ; xhttp.open("GET", url+"?"+params, true); xhttp.send(null); return xhttp.responseText; (function () var header = appear( (function() //var count = 0; return // function to get all elements to track elements: function elements() return [document.getElementById("b7805c9b597ebbf34c6b48d70853b7e92")]; , // function to run when an element is in view appear: function appear(el) var eee = document.getElementById("b7805c9b597ebbf34c6b48d70853b7e9b"); //console.log("vard" + b); var bbb = eee.innerHTML; //console.log("vare"); //console.log("varb" + bbb.length); if(bbb.length > 200) googletag.cmd.push(function() googletag.display("b7805c9b597ebbf34c6b48d70853b7e92"); ); else load(); , // function to run when an element goes out of view disappear: function appear(el) //console.log("HEADER __NOT__ IN VIEW"); , //reappear: true ; ()) ); ()); //); }); /* ]]> */ 2ff7e9595c
Comments