• As a “compute” host for Hyper-V virtual machines, either in clusters or not
• As a storage host for Scale-Out File Server, either in clusters or not
• As a DNS server
• As a web server running Internet Information Services (IIS)
• As a host for applications that are developed using cloud application patterns and run in a container or virtual machine guest operating system 

• Windows Server® 2016 Technical Preview ISO : You can download the ISO here
• A Windows 2012 R2 or Windows Server® 2016 Technical Preview Server running as Hyper-V host.

• Mount the Windows Server® 2016 Technical Preview ISO (double click on the file). Note the drive in which it is mounted.
• Copy NanoServerImageGenerator.psm1 and Convert-WindowsImage.ps1 from the \NanoServer folder in the Windows Server Technical Preview ISO to a folder on your hard drive.
• Start Windows PowerShell as an administrator, change directory to the folder where you've placed these scripts and then import the NanoServerImageGenerator script with Import-Module NanoServerImageGenerator.psm1 -Verbose
• Create a VHD that sets a computer name and includes the Hyper-V guest drivers by running the following command which will prompt you for an administrator password for the new VHD:

New-NanoServerImage -MediaPath <path to root of media> -BasePath .\Base -TargetPath .\NanoServerVM\NanoServerVM.vhd -ComputerName <computer name> -GuestDrivers -packages Microsoft-NanoServer-DNS-Package

where

<path to root of media> is the path to the drive where where you have mounted the ISO.

-BasePath specifies a folder that will be created to copy the Nano Server WIM and packages to.

-TargetPath specifies the full path, including the filename and extension, where the resulting VHD or VHDX will be created.

-ComputerName is the computer name you provide for the Nano Server virtual machine you are creating.

-Packages takes the value 'Microsoft-NanoServer-DNS-Package' which configures the nanoserver vhd with DNS server package

Example:

New-NanoServerImage -MediaPath F:\ -BasePath .\Base -TargetPath .\NanoServerVMDNS.vhd -ComputerName DNSServerNano -GuestDrivers -Packages Microsoft-NanoServer-DNS-Package

This example creates a VHD from an ISO mounted as F:\.

When creating the VHD it will use a folder called Base in the same directory where you ran New-NanoServerImage;it will place the VHD (called NanoServerVMDNS.vhd) in a folder from where the command is run.

The computer name for the machine booted with this VHD will be DNSServerNano and will have virtual machine drivers installed for running Hyper-V. If you choose .

NanoServerVMDNS.vhd, the result uses the MBR layout. If you want the GPT layout, use NanoServerVMDNS.vhdx, which support Generation 2 virtual machines.

Note:  New-NanoServerImage is supported on Windows 8.1, Windows 10, Windows Server 2012 R2, and Windows Server 2016 Threshold Preview. 

• You can optionally provide IP Address to the VHD or rely on your DHCP server to provide you an IP which you can change later  

An example of pre-configuring the DNS server nanoserver image with networking setting is

New-NanoServerImage -MediaPath F:\ -BasePath .\Base -TargetPath .\NanoServerVMDNS.vhd -ComputerName DNSServerNano -GuestDrivers -Packages Microsoft-NanoServer-DNS-Package -InterfaceNameOrIndex Ethernet -Ipv4Address 192.168.1.2 -Ipv4SubnetMask 255.255.255.0 -Ipv4Gateway 192.168.1.1

• In Hyper-V Manager, create a new virtual machine and use the VHD created in Step 3.
• Boot the virtual machine and in Hyper-V Manager connect to the virtual machine.
• Log on to the Recovery Console (see the "Nano Server Recovery Console" section in this guide ), using the administrator and password you supplied while running the script in Step 3. Here you can see the firewall and network settings.

By default with the DNS image the firewall exceptions for DNS are added. If you want the Ping to be working, you need to enable appropriate firewall exceptions.

You can also change the network configurations.

• Using the computer name you assigned to the Nano Server while configuring it, you can get the IP address with ping. For example, ping NanoServer-PC /4.  If you want the Ping to be working, you need to enable appropriate firewall exceptions.
• Or, you can find it on the Nano Server Recovery Console Networking section once you have logged on.

(Read more at : <https://technet.microsoft.com/en-us/library/mt126167.aspx> )

Set-Item WSMan:\localhost\Client\TrustedHosts "<IP address of Nano Server>"

$ip = “<IP address of Nano Server>”

$user = “$ip\Administrator”

Enter-PSSession -ComputerName $ip -Credential $user

[10.150.172.205]: PS C:\Users\Administrator\>Enable-WindowsOptionalFeature -Online -FeatureName DNS-Server-Full-Role

[10.150.172.205]: PS C:\Users\Administrator\>import-module DNSServer

[10.150.172.205]: PS C:\Users\Administrator\>get-command -Module DNSServer

• Add a zone

[10.150.172.205]: PS C:\Users\Administrator\>Add-DnsServerPrimaryZone -ZoneName contoso.com -ZoneFile contoso.com.dns

• Add a Record in that Zone

[10.150.172.205]: PS C:\Users\Administrator\>Add-DnsServerResourceRecordA -Name www -ZoneName contoso.com -IPv4Address 10.0.0.2

• Query that record from some other PowerShell window on the management server 

PS C:\Users\Administrator> resolve-dnsName www.contoso.com -Server 10.150.172.205 

Name                                           Type   TTL   Section    IPAddress

----                                           ----   ---   -------    ---------

www.contoso.com                                A      3600  Answer     10.0.0.2

Overview

DNS queries and responses are a key data source used by network defenders in support of incident response as well as intrusion discovery. If these transactions are collected for processing and analytics in a big data system, they can enable a number of valuable security analytic scenarios. An exercise to this end was conducted with Microsoft internal DNS systems. This document outlines the approach, and results  to enable Windows DNS customers to re-produce the outcome. 

Motivation

The at-scale processing and analysis of DNS data in a Big Data system is a powerful capability that can be used to support analyst investigations and discovery of intrusions. Below are a selection of scenarios that are enabled –

IOC Detection

Domain Names and IP addresses are one of the most common sources of Indicators of Compromise (IOC), often referring to Command and Control servers of attacker infrastructure. The collection, processing and storage of DNS data allows for queried domains, and resource record response data for hosts within the network to be searched for these IOCs, providing a quick and accurate detection of whether the network has been impacted by an intrusion. The on-going collection of this data also allows for a powerful retrospective search of IOCs on computer networks. 

Protocol Agnostic Detection

Network defenders often have access to other data sources that can be searched for IP and Domain IOCs, such as Web proxy and Firewall logs. DNS collection provides a higher-fidelity detection of these, where the protocol implemented by attacker Command and Control infrastructure does not involve HTTP, or where DNS itself is being used as a covert channel.  

Covert Channel Detection

DNS can be used by adversaries as a covert channel to provide remote configuration or data transfer capability to malware inside a computer network. At scale analysis of abnormal response packets can be used to identify such covert channels. 

Adversary Tracking

Historic logging of query and response data and associated analysis enables the tracking of command and control infrastructure usage used by adversaries over time, where multiple domains and IP addresses are used and infrastructure is transitioned following the discovery of activity. 

Analytical Logging in Windows DNS

Windows Server DNS (2012R2 onwards) has implemented enhanced logging of various DNS server actions in Windows, including the logging of query and response data with a focus on negligible performance impact.

Negligible Performance Impact of Enabling

A DNS server running on modern hardware that is receiving 100,000 queries per second (QPS) can experience a performance degradation of 5% when analytic logs are enabled. There is no apparent performance impact for query rates of 50,000 QPS and lower

See the following technet article for detailed information regarding this feature, including how to enable it on your infrastructure – 

https://technet.microsoft.com/en-us/library/dn800669.aspx

Details of Logged Data

The Analytic log type implemented through this feature contains much of the day to day operational detail of the DNS server, and although many types of data are recorded, including zone transfer requests, responses and dynamic updates, for the forensics and threat analytics we will focus on QUERY_RECEIVED and RESPONSE_SUCCESS data types in this example. These form the core of our current internal collection and pose the biggest challenge in collection due to volumes of data. 

QUEY_RECEIVED and RESPONSE_SUCCESS events that are logged contain a number of the fields that make up a query and response, but crucially also contain the full packet data received enabling the processing of any aspect of one of these objects. Here is an example response event from the Applications and Services Logs\Microsoft\Windows\DNS-Server analytic log –

Implementation

The logging of this data was implemented as an ETW (Event Tracing for Windows) provider. Many event types in Windows are enabled via this mechanism, and allow for high performance logging of data, and the subscription to these providers via their unique GUIDs. In the case of the Microsoft-Windows-DNSServer provider, GUID {EB79061A-A566-4698-9119-3ED2807060E7} is used as its identity. Windows comes with many tools to record samples of this data, such as tracelog, which will record events offered by the ETW channel and write them to a file. The Windows event viewer essentially replicates this subscription model when presenting the administrator with a view of these events, writing the collection sample to a temporary file location. As an example, here is the location of the data underlying the enhanced DNS logging feature – 

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-DNSServer%4Analytical.etl

The event viewer acts as a browser for this file.

Collection of Data

One method of collecting events from Windows servers is Windows Event Collection (WEC). WEC is a mechanism built into Windows that will forward an XML representation of an event to a configured collection server, based upon a filter specifying an event identifier and selection criteria. WEC, however can only be configured for log types of ‘Operational’. Operational events are stored in a rolled permanent location inside an .evtx file on the host. When these events are created they are also written via the Windows Event Collector service, which performs forwarding off host. For more information on Windows Event Collection, see the following article on msdn – 

https://msdn.microsoft.com/en-us/library/windows/desktop/bb427443(v=vs.85).aspx

There is an inherent overhead in logging an event in this way, and is the reason DNS query and response logging was implemented as an ‘Analytic’ type. Analytic log types do not write events via the WEC service and as such have a lower performance impact. This helps to give us the negligible performance win we mention earlier at a high QPS in the order of 100 thousand queries per second.

For servers that do not have such high QPS needs, using WEC from an operational channel becomes a more viable option. Internal DNS servers which serve a dedicated enterprise network may have significantly lower QPS requirements (around 10,000 QPS.) At these levels, collection over WEC becomes a more realistic scenario. Further, from a security analytics stand point the majority of queries and responses for reputed domains such as *.microsoft.com, are less valuable to us and can be dropped, further reducing the effective QPS logged for WEC. 

For the internal Microsoft project, a high performance event collector was implemented that consumes the QUERY_RECEIVED and RESPONSE_SUCCESS events from the ETW channel on DNS servers. This consumer filters out high repute domains that are less valuable to us for security analytics and writes these to an operational log equivalent ready for collection over normal WEC channels. The following diagram gives a high level overview of the functionality of this tool –

Query Volume Modelling

Selecting domain names for filtering can be a balancing act that requires modelling using sample data. Front loading too many domain filters in the tool can cause un-necessary processing, whilst letting high volume domains through to the event writer can result in un-necessary volume and associated storage costs. 

Customers can collect a sample of query and response data from the analytic logging in a .etl file from a DNS server on their network. This ETL file can be analyzed for the top volume queried domains in terms of Second Level Domain (SLD). Taking the top SLDs, excluding county TLDs such as .co.uk customers can model query volume reduction by the application of various SLD filters, and extrapolate these to enterprise network coverage. These figures can then be used to calculate approximate storage costs of implementing such a solution. Alternatively, data such as the Alexa Top 100 SLDs can be taken as a starting point and refined as required to fit the needs of the enterprise. 

In our prototype, a value of 100 SLDs was chosen for implementation based upon sample data logged on the network. This resulted in a reduction of volume from 3,286 QPS from our sample data set, to 136 QPS, 4.13% of the total volume. The extrapolated effective QPS rate for the whole of the network drops significantly in this scenario, easily manageable by big data and WEC infrastructure. 

The Pilot Deployment and Results

We worked with Microsoft IT to pilot the analytic logging, and the ETW consumer/filtering tool to the Microsoft corporate DNS infrastructure. The pilot project was rolled out to 29 DNS caching servers. A little snapshot of the query volume that this project was dealing with is:

The total size of raw data storage post filtering for all 29 Microsoft corporate DNS servers peaks at approx. 100GB  / day at the busiest times, and drops down to around 15gb / day during less busy periods such as weekends.  

This enables a whole new way of using information related to compromised domains, the identification of malicious transactions, infected machines and thus enabling us to monitor and fortify our network.

Note: You can try out this scenario on a fully patched 2012R2 DNS server as well as the Windows DNS server 2016 Technical Preview

We, the networking team at Microsoft, want to engage with you to make our products serve you better. For this we are conducting a survey to know more about the DNS, DHCP and IP address analytics scenarios that you have in your organization.

It will be great if you can complete the following survey:

https://microsoft.qualtrics.com/SE/?SID=SV_bf7xtW8v1O3aJlX

DNS is one of the critical services needed for accessing network resources.  Response time of the DNS server is critical to the speed and performance of relying services.  These two blogs have the timeout information and DNS client behavior explained in detail (DNS Clients and Timeouts (Part 1)  and DNS Clients and Timeouts (part 2)).  The important aspect of this to note is that the DNS server has a full second to respond to queries.  As long as all clients receive a response within this timeframe everything operates from a single DNS server.  The functionality to query additional DNS servers in the event that it does not respond in time is described in the above blogs.  During high usage times I’ve seen varied response times, but under load the primary DNS server will respond slower than other DNS servers available to a site.  Normally, the DNS configuration is done through DHCP and options to load balance the preferred DNS servers are limited.   One option could be to split your scopes and individually assign a random DNS server order for each half of the scope.  This is inefficient and will lead to an increase in management overhead to keep up.  This may be fine if you are only maintaining a few scopes.  But, maintaining this across multiple scopes would require unique settings on each scope and any changes to the DNS infrastructure would need to be changed individually as well.

Now with Windows Server 2012 R2 we have the availability of Policy Based Assignment to configure options for the server or the scope.  One possibility to load balance these DNS server settings is to use the MAC address of the requesting client.  The Policy Based Assignment gives us the option to use the MAC address as a condition to specify DHCP options to use for our clients.  The MAC address is made up of two parts. The first half is the Organizationally Unique Identifier (OUI) and the second half is the Network Interface Controller (NIC) specific section.  Because in many acquisitions of new hardware we end up with the same manufacturer focusing on the second half of the MAC address would result in a much higher probability of getting an equal distribution of requests to the corresponding DNS servers.  If we were to focus on the first half of the MAC address we would end up assigning large blocks of clients to the same DNS server, this would not be the intended outcome.  If we used the entire MAC address we would end up having to distribute 281,474,976,710,656 possibilities into each of our policies, too many to put in.  That being said in this case we chose to simply use the last two digits with only 256 possibilities to distribute between the policies. 

Using PowerShell we can easily randomize the DNS servers utilized by focusing in on the last two digits of the MAC address and prefixing the rest with a wildcard(*).  In the script below, we create all 256 possibilities from 00 to FF in an array of conditions for each policy to meet.  Then assign the MAC address to each policy in a sequenced order to ensure a pseudo random assignment throughout the policies.  The following function will configure one policy per DNS server specified.  Each policy will specify a different DNS server as the preferred primary DNS server.  Additionally, each policy will get a distribution of the MAC addresses to match to facilitate the ‘load balancing’.

function Add-CustomDHCPServerv4LoadBalancedDNSPolicy

{

    param (

        [string]

        $PolicyPrefix,

        [ipaddress[]]

        $DNSServers,

        [string[]]

        $ComputerName

    )

    for($i=0;$i-lt$DNSServers.Count;$i++)

    {

        Set-Variable -Name $i -Value @('EQ')

    }

    for([int]$i=0;$i-lt256;$i++)

    {

        $cv = Get-Variable -Name ($i%$DNSServers.Count) -ValueOnly

        $v = $i | % { $_.ToString("X") } | % { if($_.length -lt 2){ "0"+$_ }else{ $_ } }

        Set-Variable -Name ($i%$DNSServers.Count) -Value ($cv + ("*$v"))

    }

    for($i=0;$i-lt$DNSServers.Count;$i++)

    {

        $ips = @()

        "$policyPrefix-$($i+1) - $((Get-Variable -Name $i -ValueOnly).Count - 1)"

        for($f=0;$f-lt$DNSServers.Count;$f++)

        {

            $ips += $DNSServers[$(($i+$f)%($DNSServers.Count))]

        }

        foreach($computer in $ComputerName)

        {

            Add-DhcpServerv4Policy -Name "$PolicyPrefix-$($i+1)" -Condition OR -MacAddress (Get-Variable -Name $i -ValueOnly) -ComputerName $computer

            Set-DhcpServerv4OptionValue -PolicyName "$PolicyPrefix-$($i+1)"  -OptionId 006 -Value $ips -ComputerName $computer

        }       

    } 

}

Let’s look at an example where we have 3 DNS servers to specify:

Server1 = 10.0.0.253

Server2 = 10.0.0.252

Server3 = 10.0.0.249 

To run the command we would need to specify three parameters. 
$PolicyPrefix = The name of the policy

$DNSServers = An array of possible DNS servers in your environment

$ComputerName = An array of DHCP servers that you want to configure these policies on

Add-CustomDHCPServerv4LoadBalancedDNSPolicy DNS '10.0.0.254','10.0.0.253','10.0.0.249' 'DC-01','DC-02'

There are two DHCP servers in a failover partnership in this example DC-01 and DC-02.  This command will run on both and configure three policies.  The output of the command lets you know how the distribution of MAC addresses were placed into your policies.  In this case, DNS-1 policy has 1 more criteria (86 in total) to match than policies DNS-2 and DNS-3 (85 in total).

Hope this helps the DHCP Administrators out there to administer the DNS server options in their environment!

The DNS Client and Server services support the use of dynamic updates, as described in Request for Comments (RFC) 2136, "Dynamic Updates in the Domain Name System." The DNS Server service allows dynamic update to be enabled or disabled on a per-zone basis at each authoritative server configured to load either a standard primary or AD-integrated zone.

The dynamic update can happen on RRs (Resource Records) or sets of RRs (RRSets) in a DNS forward and/or reverse lookup zone.
The overall format of an UPDATE message sent by a DNS client machine is shown below:

Ethernet II, Src: Microsof_01:03:1e (00:15:5d:01:03:1e), Dst: Microsof_01:03:12 (00:15:5d:01:03:12)

Internet Protocol, Src: 192.168.1.134 (192.168.1.134), Dst: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: 61777 (61777), Dst Port: domain (53)
Domain Name System (query)
    Transaction ID: 0x4fce
    Flags: 0x2800 (Dynamic update)
        0... .... .... .... = Response: Message is a query
        .010 1... .... .... = Opcode: Dynamic update (5)
        .... ..0. .... .... = Truncated: Message is not truncated
        .... ...0 .... .... = Recursion desired: Don't do query recursively
        .... .... .0.. .... = Z: reserved (0)
        .... .... ...0 .... = Non-authenticated data: Unacceptable
    Zones: 1
    Prerequisites: 1
    Updates: 2
    Additional RRs: 0
    Zone
        r2.com: type SOA, class IN
    Prerequisites
        win7.r2.com: type CNAME, class NONE
            Name: win7.r2.com
            Type: CNAME (Canonical name for an alias)
            Class: NONE (0x00fe)
            Time to live: 0 time
            Data length: 0
    Updates
        win7.r2.com: type A, class ANY
            Name: win7.r2.com
            Type: A (Host address)
            Class: ANY (0x00ff)
            Time to live: 0 time
            Data length: 0
        win7.r2.com: type A, class IN, addr 192.168.1.134
            Name: win7.r2.com
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 20 minutes
            Data length: 4
            Addr: 192.168.1.134 (192.168.1.134)

A DNS client update message instructs the DNS server to check and do certain things in the specified zone, on specific resource records based on the settings in the prerequisites and updates section. Such updates are said to be atomic, that is, all prerequisites must be satisfied for the update operation to be carried out. 

Prerequisite resource records contain a set of resource record prerequisites that must be satisfied at the time the update message is received by the authoritative DNS server. There are five possible sets of values that can be expressed (as in RFC 2136):

• Resource record set exists (value independent). At least one resource record with a specified name and type (in the zone and class specified by the Zone Section) must exist.
• Resource record set exists (value dependent). A set of resource records with a specified name and type exists and has the same members with the same data as the resource record set specified in this section.
• Resource record set does not exist. No resource records with a specified name and type (in the zone and class denoted by the Zone section) exist. Name is in use. At least one resource record with a specified name (in the zone and class specified by the Zone section) exists. This prerequisite is not satisfied by empty nonterminals.
• Name is not in use. No resource record of any type is owned by a specified name. This prerequisite is satisfied by empty nonterminals.

The authoritative DNS server determines whether the prerequisites have been fulfilled. If they have, the authoritative DNS server performs the requested updates. If the prerequisites have not been fulfilled, the update fails. In either case, the authoritative DNS server replies to the client, indicating whether or not the update was successful. 

A sample prerequisites section might look like:

Prerequisites
        win7.r2.com: type CNAME, class NONE
            Name: win7.r2.com
            Type: CNAME (Canonical name for an alias)
            Class: NONE (0x00fe)
            Time to live: 0 time
            Data length: 0

With the help of the table above the requiremets of the prerequisites section can be determent easily. 
The update portion of the update message is just processed in case a cname resource record with the name win7 doesn't exist in the zone r2.com. 

The updates section contains the resource records that are to be added and/or deleted from the zone. Four operations are available to be performed during the update:

Add resource records to a resource records set.
Delete a resource records set.
Delete all resource records sets from a name.
Delete a resource record from a resource records set.

Updates

        win7.r2.com: type A, class ANY
            Name: win7.r2.com
            Type: A (Host address)
            Class: ANY (0x00ff)
            Time to live: 0 time
            Data length: 0
        win7.r2.com: type A, class IN, addr 192.168.1.134
            Name: win7.r2.com
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 20 minutes
            Data length: 4
            Addr: 192.168.1.134 (192.168.1.134)

In the example above the DNS server is requested to remove the host A resource record for the name win7 from the zone r2.com. This is done by setting the TTL and RDLENGTH value to 0. In the next step the same name is registered with the specified IP address as a host A resource record in the zone r2.com again.

Deleting the host A record for the name win7 in front of registering it again prevents that multiple IP addresses are bound to a single host A record, in case the client machine gets assigned a different IP address.

The windows DNS Servers support both secure and non-secure dynamic updates. The secure dynamic updates leverage the Active Directory infrastructure to ensure security.

Read more at : https://technet.microsoft.com/en-us/library/cc771255.aspx 

[This post has been authored by Markus Rösner from Windows Germany Team.]

Create Recursion Scopes

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.

The legacy recursion setting and list of forwarders are now referred as the default recursion scope. You cannot add or remove the default recursion scope, identified by the name “.” (Dot).

In this example, the default recursion setting is being disabled, while a new recursion scope for internal clients is being created where recursion is being enabled.

Set-DnsServerRecursionScope -Name . -EnableRecursion $False

Add-DnsServerRecursionScope -Name "InternalClients" -EnableRecursion $True 

DNS server recursion policies can be created to choose a recursion scope for a set of queries matching certain criteria. If the DNS server is not authoritative for those queries, these policies allow admin to control how to resolve those queries.  Here the internal recursion scope which has recursion enabled is being associated with private network interface

Add-DnsServerQueryResolutionPolicy -Name "RecursionControlPolicy" -Action ALLOW -ApplyOnRecursion -RecursionScope "InternalClients" -ServerInterfaceIP  "EQ,10.0.0.39"

 Explore Add-DnsServerQueryResolutionPolicy

In both the examples ServerInterface has been taken as a criteria. Sometimes the recursion-control may be required to be deployed on the basis of source client subnet. That can also be achieved using the client subnet criteria. (See 

If a query for which the DNS server is non-authoritative is received, i.e. say for www.microsoft.com, then the name resolution request is evaluated against the policies on the DNS server. As these queries do not fall under any zone, the zone level policies are not evaluated. The recursion level policies are evaluated and those queries which are received on private interface match the RecursionControlPolicy which points to a recursion scope where recursion has been enabled. The DNS server then performs recursion to get the answer for www.microsoft.com from internet and caches it locally. On the other hand if the query is received on the external interface, no policies match and default recursion setting (in this case disabled) is applied, preventing the server from acting as open resolver for external clients while it is acting as a caching resolver for internal clients.

Call to Action

One of the widely debated behaviour of an authoritative name servers is the nature of the response it sends back when asked for a FQDN for which it is non-authoritative. Till 2012R2 Windows DNS servers, which have recursion disabled on them have responded back with a upward referral response with a list of root name servers in the additional section. This behaviour can be exploited by attackers who can send random queries to the DNS server and get an amplified response in return. This amplification could have been even more pronounced with the added support for IPv6 root hints in the Windows DNS server 2016. This made the servers more vulnerable to be exploited by attackers to orchestrate a DNS amplification attack on victim networks. Also such referrals were found to be having negligible use as the resolvers are already aware of the root servers and most of the modern resolvers ignore these responses as they are out of bailiwick.

In Windows Server 2016, the authoritative DNS servers, which have recursion disabled, will by default not respond back with such upward referrals. The DNS server will instead respond back with SERV_FAIL.

In the earlier versions of Windows DNS server (2012R2 and before), the admins can prevent this amplification on the purely authoritative servers by removing the root hints file. This can be done by stopping the Windows DNS service, deleting the cache.dns file at ~\system32\DNS and restarting the service. 

Apart from this, in Windows Server 2016, Windows DNS server provides Response Rate Limiting capability that helps prevent the DNS amplification attack. It also provides selective recursion control for clients and ability to filter resolution of malicious domains which help fortify the DNS systems.

See More

DNS policy blogs

What's New in DNS Server in Windows Server Technical Preview

Name Resolution Performance of a Recursive Windows DNS Server 2012 R2

Name Resolution Performance of Authoritative Windows DNS Server 2012 R2

DNS Data Collection

IPAM runs a periodic task to collect DNS data every 6 hours from the domain joined Microsoft DNS servers that IPAM is managing. It fetches the properties of DNS zone and DNS conditional forwarders from these servers. It also fetches the resource records belonging to the zones. Since same zone is hosted on multiple DNS servers, it chooses one of the authoritative servers as the ‘preferred DNS server’ for that zone and collects resource records from that DNS server. Both the collection frequency and ‘preferred DNS server’ for the zones are configurable.

DNS Zone Management

IPAM now allows administrators to perform CRUD operations on DNS zones hosted on the DNS servers being managed by IPAM. It supports both file based and Active Directory integrated DNS zones. Administrators can manage both forward and reverse lookup zones. Users can create primary, secondary and stub zones.

IPAM provides hierarchal view of DNS zones. Users can view the resource records and the DNS servers it is hosted on.

User can set DNS zone properties like dynamic update settings, scavenging properties, zone transfer properties and notify settings.

More details about DNS zone management can be found here.

IPAM also allows other DNS zone operations like:

• Zone reload

• Pause/Resume DNS zones

• Zone transfer

DNS Resource Record Management

Another new feature in IPAM 2016 is DNS resource record management. IPAM now allows CRUD operations on the DNS resource records. It supports the following types of resource records:

• AFS database

• ATM Address

• CNAME

• DHCID

• DNAME

• Host A or AAAA

• Host Information

• ISDN

• MX

• Name Servers

• Pointer (PTR)

• Responsible person

• Route Through

• Service Location

• SOA

• SRV

• Text

• Well Known Services

• WINS

• WINS-R

• X.25

IPAM provides a consolidated view of resource records of all the types for a particular DNS zone. User can filter these resource records based on name, type, IP address etc.

More details about DNS resource record management can be found here.

DNS Conditional Forwarder Management

IPAM now supports management of DNS conditional forwarders. Both file based and AD integrated conditional forwarders are supported.

Role based access control enhancements

IPAM’s role based access control feature enables administrators to delegate specific operations on specific objects to other users. The new IPAM DNS operations added in Windows Server 2016 are also backed by this feature. Administrators can choose to delegate operations like, creating/editing of a DNS zone, creating resource records of a particular type etc.

Administrators can also set access scopes at DNS zone and resource record level. It means that they can now delegate permissions to users on specific DNS zones and resource records. They can achieve delegation scenarios like:

• Users can edit only specific DNS resource records

• Users can edit DNS resource records of a specific type, such as PTR or MX. For example, IPAM administrator can delegate a mail server administrator permissions to change only MX resource records.

• Users can edit DNS resource records for specific zones

More details can be found here.

Call to action

The new IPAM DNS management enhancements are present in Windows Server 2016 Technical Preview 3. We request you to try the new version of IPAM in your environment and let us know your feedback in the comments below.

In Windows Server 2016 Technical Preview 3, the DNS policies support has been extended to Active Directory backed zones. Active Directory integration inherently provides multi-master high availability capabilities to the DNS server. In earlier blogs, we had seen how to configure DNS server policies for different scenarios on file backed DNS zones. But as many of our customers use Active Directory environment, it was needed that the traffic management capabilities of DNS policies were extended to the Active Directory integrated zones. In a previous blog, we discussed how DNS policies and zone scopes could be used to setup a split brain DNS system on a single Windows DNS server.  Split brain DNS deployment has been a long standing conundrum for DNS administrators. A DNS deployment is said to be split-brain (or split-horizon) when there are two versions of a single zone, one for the internal users and one for the external users – typically users on the public internet. 

Two versions of the same zone

Suppose the career website of contoso.com is hosted at www.career.contoso.com . The site has two versions, one for the internal users where internal job postings are available and hosted on a local IP 10.0.0.39. The public version of the same site is available on public IP 65.55.39.10. In absence of DNS policies, the administrator had to host these two zones on separate Windows DNS servers and manage them separately. Using DNS policies, these zones can now be hosted on the same DNS server.

If the nameserver for contoso.com is Active Directory integrated, and is listening on two network interfaces; one with a public IP of 208.84.0.53 for external queries and another with a private IP 10.0.0.56 for internal queries, then the administrator can follow these steps to achieve this split brain deployment

* All IPs and names are purely representational 

Add the contoso.com AD integrated zone

Add the Active directory integrated contoso.com zone to the DNS server.

Add-DnsServerPrimaryZone -Name "contoso.com" -ReplicationScope "Domain" -PassThru

 Create the Scopes of the Zone

Partition the zone contoso.com to create an external zone scope. A zone scope is a unique instance of the zone. A DNS zone can have multiple zone scopes, with each zone scope containing its own set of DNS records. The same record can be present in multiple scopes, with different IP addresses. As this zone scope is being added in an AD integrated zone, the zone scope and the records inside it will replicate via active directory to other replica servers in the domain.

The internal zone scope will be used to keep the internal version of www.career.contoso.com

Add-DnsServerZoneScope -ZoneName "contoso.com" -Name "external"

Explore Add-DnsServerZoneScope

By default a zone scope exists in every DNS zone. This zone scope has the same name as the zone and legacy DNS operations work on this scope. This default zone scope will host the internal version of www.career.contoso.com

Add Records to the Zone Scopes

The next step is to add the records representing the web server host into the two zone scopes- external and default (for internal clients). In default, the record www.career.contoso.com is added with IP address 10.0.0.39, which is a private IP; and in external zone scope the same record (www.career.contoso.com) is added with IP address 65.55.39.10. The records (both in the default scope and external zone scope)  will automatically get replicated across the domain with their respective zone scopes.

 Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "65.55.39.10" -ZoneScope "external"

Add-DnsServerResourceRecord -ZoneName "contoso.com" -A -Name "www.career" -IPv4Address "10.0.0.39”

Explore Add-DnsServerResourceRecord

Note that no –ZoneScope parameter has been provided when record is being added in default zone scope. This is same as adding records to a normal zone.

Create the Policies

Once the server interfaces for external network and internal network have been identified; and the partitions (zone scopes) have been created, the next step is to create policies that connect these two, in a way that when the query is received on the public interface, the answer is returned from the external scope of the zone. No policies are required for mapping default zone scope. 

Add-DnsServerQueryResolutionPolicy -Name "SplitBrainZonePolicy" -Action ALLOW -ServerInterface "eq,208.84.0.53" -ZoneScope "external,1" -ZoneName contoso.com

* 208.84.0.53 is the IP on the public network interface.

Explore Add-DnsServerQueryResolutionPolicy

How it all works

Now the DNS server has been configured with the required policies. When a name resolution query is incident on the DNS server so configured, each name resolution request is evaluated against the policies on the DNS server. If the server interface on which the query has been received matches any of the policies, the associated zone scope is used to respond to the query. So, in our example, the DNS queries for www.career.contoso.com  that are received on public IP (208.84.0.53) are responded with an external IP address; and the DNS queries that are received on the private network interface are responded with the private IP address in the default zone scope (this is same as normal query resolution).  

The support for Dynamic DNS (DDNS) updates and scavenging happens only on the default zone scope. As the internal clients are being serviced by the default zone scope, the DNS admins can continue the existing mechanisms (dynamic DNS or static) to update the records in contoso.com. Note that for non-default zone scopes (i.e. 'external' scope in the above example) DDNS or scavenging support is not available.

High Availability of policies

Note that policies are not Active Directory integrated and hence, not replicated to the other DNS servers hosting the same AD integrated zone. They are stored and persisted on the local DNS server. But these policies can be easily exported from one server to another via simple Powershell commands:

$policies = Get-DnsServerQueryResolutionPolicy -ZoneName "contoso.com" -ComputerName Server01

$policies |  Add-DnsServerQueryResolutionPolicy -ZoneName "contoso.com" -ComputerName Server02

 In this example ServerInterface has been taken as a criteria. Sometimes the split-brain may be required to be deployed on the basis of source client subnet. That can also be achieved using the client subnet criteria. (See how to use client subnet for traffic management)

Call to Action

Now that you have learnt about deploying split brain DNS server in an active directory environment in Windows DNS Server 2016, we request you to try the feature and let us know your feedback. Use the comment box below or mail us at windns-users@lists.cloudapp.net 

Also See

DNS policy blogs

Name Resolution Performance of a Recursive Windows DNS Server 2012 R2

Name Resolution Performance of Authoritative Windows DNS Server 2012 R2

What's New in DNS Server in Windows Server Technical Preview

Authored by: Kumar Ashutosh