If you would like to be notified when Wilfredo Lanz releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the first part in this article series please go to Windows Server 2012 DNS (Part 1).
The DNS server service is not installed on Windows Server 2012 by default. It must be added as a server role by using one of the following options:
- Server Manager
- Windows PowerShell
- Active Directory Domain Services Installation Wizard (when promoting the server to an Active Directory domain controller)
Once the installation is complete, a Microsoft Management console with the DNS Manager snap-in is automatically available from the tools menu and you are able to monitor one or more DNS servers from the Server Manager console. Typing dnsmgmt.msc from the command prompt or the Search box brings up the DNS Manager.
Let’s review the steps to install DNS using the Server Manager:
1. In the Server Manager console, click Add roles and features.
Figure 1
2. On the Before you Begin page, click Next.
3. On the Select installation type page, ensure that Role-based or feature-based installation is selected and click Next.
Figure 2
4. On the Select destination server page, ensure that the correct server is selected, and then click next.
Figure 3
5. On the Select server roles page, select DNS Server.
Figure 4
6. When the Add Roles and Features Wizard displays, click Add Features, and then click Next.
Figure 5
7. On the Select features page, click Next.
Figure 6
8. On the DNS Server page, click Next.
Figure 7
9. On the Confirm installation selections page, click Install.
Figure 8
10. On the Installation progress page, when the Installation succeeded message displays, click Close.
Figure 9
Let’s now review the DNS installation process using Windows PowerShell. We can verify the roles and features installed on Windows server 2012 by typing the following from a PowerShell prompt:
Get-windowsFeature| ? {$_.installed}.
Figure 10
The previous figure shows the features installed on Windows Server 2012 by default. To add the DNS server role using Windows PowerShell, first import the PowerShell ServerManager module and then run the Install-WindowsFeature cmdlet as seen below:
Figure 11
Using PowerShell again, we can verify that the DNS role is now installed:
Figure 12
Caching-only DNS Server
Whether you use the server manager or Windows PowerShell, the DNS server has no zone configured right after the installation. Without zones, you could still use this server as a caching-only DNS.
A caching-only DNS server is not authoritative for any domain. It receives name resolution requests and generates either an iterative query to the root hints on the Internet or it forwards the request to another DNS server when configured as a forwarder. The caching-only DNS server caches the answers before sending them back to the DNS client; that way, the next time a name resolution query comes asking for the same name, the caching-only DNS server responds from its own cache instead of generating another iterative query or forwarding the request.
To verify the root hints on your Windows Server 2012 DNS server use the following PowerShell cmdlet:
Figure 13
DNS Zones Types
Besides the forward and reverse lookup zones that we reviewed in our previous DNS article, there are four different zone types that can be configured on a Windows Server 2012 DNS server.
Primary zone. A DNS server can read and write data on a primary zone. This is possible because the DNS server stores the master copy of the zone data either in a text file or in the Active Directory database if the DNS is installed on a domain controller. If a local file is used, the file is named with the same name as the zone using a .dns extension like zone_name.dns. The zone file is saved to the %windir%\system32\dns directory by default.
When a file is used, the primary DNS server is the only one that has a writable copy of the database.
A DNS server is authoritative for the records that it holds on a primary zone. That means if the DNS server receives a name resolution query that includes the domain name on the primary zone, the DNS server will respond with a yes or no answer. The authoritative DNS will not forward that name resolution query to any other DNS server.
Secondary zone. A DNS server can read, but not write data on a secondary zone. A secondary zone is a copy of a primary zone that another DNS server hosts. The information on the secondary zone is obtained and updated via zone transfers from another server. A read-only text file is used to store the information locally; secondary zones cannot be store in the active directory database. A DNS server is authoritative for the records that it holds on a secondary zone.
Stub zone. A stub zone is a limited copy of a zone that consists of the following records: start of authority (SOA) resource records, name server (NS) records, and host name (A) records. These records are used to identify the zone’s authoritative DNS servers. The DNS server holding the stub zone is not authoritative for that zone. When this DNS server receives a name resolution query, it needs to ask one of the authoritative DNS servers from the stub zone.
Active Directory Integrated zone. Active directory integrated zones can be configured only on domain controllers that are also DNS servers. This is a primary zone with its data stored in the active directory database. See figure below.
Figure 14
There are several benefits of using active directory integrated zones, among them:
Secure dynamic updates. Dynamic updates allow DNS clients to register their resource records in the DNS database automatically without manual intervention. This feature is available on standard primary zones; however, only active directory integrated DNS zones can be configured for secure dynamic updates. This means that you can set permissions on the zone to allow only authorized computers to register in the DNS database.
Secure replication topology. There is no need to configure zone transfer on Active Directory integrated zones the way you have to do it with standard primary zones and secondary zones. With Active Directory integrated zones, the DNS data is transferred automatically as part of the active directory replication. All AD replication is encrypted by default.
Increase resilience. There is no single point of failure when you have multiple domain controllers holding active directory integrated zones. Each domain controller has a read/write copy of the DNS zone; this allows changes and automatic updates performed on any domain controller to be replicated across the domain or the forest using the powerful active directory replication engine.
Security permissions. Like any other active directory object, you can delegate administration and apply individual permissions to zones, and resource records by modifying the access control list (ACL) on the zone. See below the security tab on the properties of an active directory integrated zone:
Figure 15
Advanced Windows Server 2012 DNS configuration options
Windows server 2012 offers some advanced configuration options that allows you to improve the security and performance of your DNS infrastructure. Let’s review some of them:
DNS Security Extensions (DNSSEC). The DNS protocol does not have any built-in capabilities to ensure authentication or check the integrity of the DNS information that is exchanged between DNS servers or delivered to DNS clients. This known vulnerability can be exploited by attackers who may be able to hijack the name resolution activity when users are trying to reach a website on the internet. One purpose of the attacker could be to take control of the process and redirect the user’s browser to a phony scam website where the user is asked to enter personal information like username, password, credit card, bank account or social security numbers. DNSSEC uses Public Key Infrastructure (PKI) certificates with the DNS protocol to allow the DNS servers to validate DNS responses. With DNSSEC, an administrator can digitally sign a DNS zone, which is a way to digitally sign all the records within that zone.
When a DNS query is issued for a resource record in a signed zone, a digital signature is returned with the response so that validation can be performed. The validation process ensures that the data has not been modified or tampered with and can be trusted by the DNS resolver.
DNSSEC Resource Records
New resource record types are associated with DNSSEC. The signatures that are generated after implementing DNSSEC are contained within the DNS zone as a Resource Record Signature (RRSIG). When the DNS server responds to a name resolution query, one or more RRSIG records are returned in the response. A public cryptographic key that is stored in a DNSKEY resource record is used to verify the signature. The DNSKEY record is retrieved by a DNS server during the validation process. If no matching resource record is found, that means that there is no RRSIG record, however the DNS server response must still be validated, for in these cases the Next Secure (NSEC) records are used. A validator can use the NSEC record as proof that the name does not exist. The NSEC3 is a better alternative to the NSEC record; both are supported by Windows Server 2012.
Trust Points and Name Resolution Policy Table
Two important components of a DNSSEC implementation are Trust Points and Name Resolution Policy Table.
Trust Points. These provide a way to share the public key used to validate the RRSIG record’s digital signature with other trusted DNS servers. If the DNS server is running on a domain controller, trust points can be stored in the forest directory partition in Active Directory Domain Services (AD DS) from which they can be replicated to all DNS servers running on domain controllers in the forest.
Name Resolution Policy Table (NRPT). It lists zones or namespaces that perform DNSSEC queries and those that do not. It is possible to use either group policy or Windows PowerShell to configure the NRPT to require that DNSSEC validation be performed on DNS responses on select namespaces.
Using Windows PowerShell we can verify that a DNS zone is currently unsigned. On the PowerShell prompt enter: Resolve-Dnsname FQDN –serverDNS_Server_name–dnssecok. See the following output:
Figure 16
Now, let’s sign a DNS zone with DNSSEC to verify how this output changes. Here are the steps to sign the zone:
1. Open the DNS Manager, right-click on the DNS zone and select DNSSEC – Sign the Zone.
Figure 17
2. On the DNS Security Extensions (DNSSEC) page, click Next.
Figure 18
3. On the Signing Options page, select Use default settings to sign the zone, and click Next.
Figure 19
4. On the DNS Security Extensions (DNSSEC) page, click Next.
Figure 20
5. On the Signing the Zone page, click Finish.
Figure 21
Now we can see the RRSIG, DNSKEY, and NSEC3 resource records contained within the signed zone.
Figure 22
Running Windows PowerShell again verifies that the zone has been digitally signed. You can compare this result with the previous output, before we applied DNSSEC.
Figure 23
DNS Socket Pool and Cache Locking
DNSSEC is designed to protect the DNS clients’ name resolution queries from forged DNS data, including DNS cache poisoning. Socket Pool and Cache Locking are two more advanced configuration options that may help strengthen your DNS security.
DNS Socket Pool.This feature allows the DNS server to use a random source port out of a preconfigured range when sending DNS queries. By not using the same port for each new DNS query, the socket pool improves protection against DNS cache poisoning attacks.
The figure below shows how to use the dnscmd tool to verify and configure the DNS socket pool size.
Figure 24
Cache Locking. When cache locking is enabled, the DNS server will not allow cached records to be overwritten for the duration of the time to live (TTL) value on the DNS record. This feature protects the DNS cache records against possible DNS cache poisoning attacks by malicious users on the Internet.
Cache locking is configured as a percent value. Let’s say that you set the cache locking value at 75, the DNS server will not overwrite a cached entry for 75% of the duration of the TTL. By default, the cache locking percent value is 100 meaning that cached entries will not be overwritten for the entire duration of the TTL.
You can use the dnscmd tool to configure cache locking on a Windows Server 2012 DNS server. See figure below.
Figure 25
In this article, we walked through the installation process of the DNS role using both Windows Server 2012 Server Manager and Windows PowerShell. We used DNS Manager Console, PowerShell, and dnscmd to complete administrative tasks and reviewed some advance security features including active directory integrated zones, DNSSEC, socket pool and cache looking.
This article was originally published by Intense School.
If you would like to be notified when Wilfredo Lanz releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the first part in this article series please go to Windows Server 2012 DNS (Part 1).
