Adding and removing servers to manage
You can use the DNS Manager console to manage servers running DNS by following these steps:
1. Press and hold or right-click DNS in the console tree, and then tap or click Connect To DNS Server.
2. If you’re trying to connect to the local computer, select This Computer. Otherwise, select The Following Computer, and then enter the IP address or fully qualified host name of the remote computer with which you want to connect.
3. Tap or click OK. Windows Server 2012 R2 attempts to contact the server. If it makes contact, it adds the server to the console.
NOTE If a server is offline or otherwise inaccessible because of security restrictions or problems with the Remote Procedure Call (RPC) service, the connection fails. You can still add the server to the console by tapping or clicking Yes when prompted.
In the DNS Manager console, you can delete a server by selecting its entry and then pressing Delete. When prompted, tap or click Yes to confirm the deletion. Deleting a server only removes it from the server list in the console tree. It doesn’t actually delete the server.
Starting and stopping a DNS server
To manage DNS servers, you use the DNS Server service. You can start, stop, pause, resume, and restart the DNS Server service in the Services node of Server Manager or from the command line. You can also manage the DNS Server service in the DNS Manager console. Press and hold or right-click the server you want to manage in the DNS Manager console, point to All Tasks, and then tap or click Start, Stop, Pause, Resume, or Restart as appropriate.
NOTE In Server Manager, under the DNS Server node, expand the DNS node and then press and hold or right-click the server with which you want to work. On the shortcut menu, select Start Service, Stop Service, Pause Service, Resume Service, or Restart Service as appropriate.
Using DNSSEC and Signing Zones
Windows 7 or later versions, in addition to Windows Server 2008 R2 or later, support DNS Security Extensions (DNSSEC). DNSSEC is defined in several Request For Comments (RFCs), including RFCs 4033, 4034, and 4035. These RFCs add origin authority, data integrity, and authenticated denial of existence to DNS. With DNSSEC, there are the following additional resource records to learn about:
■ DNSKEY (Domain Name System Key)
■ RRSIG (Resource Record Signature)
■ NSEC (NextSECure)
■ DS (Domain Services)
The DNS client running on these operating systems can send queries that indicate support for DNSSEC, process related records, and determine whether a DNS server has validated records on its behalf. On Windows servers, DNSSEC allows your DNS servers to securely sign zones, to host DNSSEC-signed zones, to process related records, and to perform both validation and authentication. The way a DNS client works with DNSSEC is configured through the Name Resolution Policy Table (NRPT), which stores settings that define the DNS client’s behavior. Typically, you manage the NRPT through Group Policy.
When a DNS server hosting a signed zone receives a query, the server returns the digital signatures in addition to the requested records. A resolver or another server configured with a trust anchor for a signed zone or for a parent of a signed zone can obtain the public key of the public/private key pair and validate that the responses are authentic and have not been tampered with.
As part of your predeployment planning, you need to identify the DNS zones to secure with digital signatures. DNS Server for Windows Server 2012 R2 has the following significant enhancements for DNSSEC:
■ Support for dynamic updates in Active Directory-integrated zones. Previously, if an Active Directory domain zone was signed, you needed to manually update all SRV records and other resource records. This is no longer required because DNS Server now does this automatically.
■ Support for online signing, automated key management, and automated trust anchor distribution. Previously, you needed to configure and manage signings, keys, and trust anchors. This is no longer required because DNS Server now does this automatically.
■ Support for validations of records signed with updated DNSSEC standards including NSEC3 and RSA/SHA-2.
With Windows Server 2012 R2, an authoritative DNS server also can act as the Key Master for DNSSEC. The Key Master generates and manages signing keys for both Active Directory-integrated zones protected by DNSSEC and standard (filebacked) zones protected by DNSSEC. When a zone has a designated Key Master, the Key Master is responsible for the entire key signing process from key generation to storage, rollover, retirement, and deletion.
Although key signing and management tasks can only be initiated from the Key Master, other primary DNS servers can continue to use zone signing-they just do so via the Key Master. You must choose a key master when you sign a zone with DNSSEC. You can transfer the key master role to another DNS server that hosts the zone at any time.
Additionally, keep the following in mind:
■ For file-backed zones, the primary server and all secondary servers hosting the zone must be a Windows Server 2008 R2 or later DNS server or a DNSSEC-aware server that is running an operating system other than Windows.
■ For Active Directory-integrated zones, every domain controller that is a DNS server in the domain must be running Windows Server 2008 R2 or later if the signed zone is set to replicate to all DNS servers in the domain. Every domain controller that is a DNS server in the forest must be running Windows Server 2008 R2 or later if the signed zone is set to replicate to all DNS servers in the forest.
■ For mixed environments, all servers that are authoritative for a DNSSEC-signed zone must be DNSSEC-aware servers. DNSSEC-aware Windows clients that request DNSSEC data and validation must be configured to issue DNS queries to a DNSSEC-aware server. Non-DNSSEC-aware Windows clients can be configured to issue DNS queries to DNSSEC-aware servers. DNSSEC-aware servers can be configured to recursively send queries to a non-DNSSECaware DNS server.
Securing DNS zones with digital signatures is a multistep process. As part of that process, you need to designate a key master . Any authoritative server that hosts a primary copy of a zone can act as the key master. Next, you need to generate a Key Signing Key and a Zone Signing Key. A Key Signing Key (KSK) that is an authentication key has a private key and a public key associated with it. The private key is used for signing all of the DNSKEY records at the root of the zone. The public key is used as a trust anchor for validating DNS responses. A Zone Signing Key (ZSK) is used for signing zone records.
After you generate keys, you create resource records for authenticated denial of existence by using either the more secure NSEC3 standard or the less secure NSEC standard. Because trust anchors are used to validate DNS responses, you also need to specify how trust anchors are updated and distributed. Typically, you’ll want to automatically update and distribute trust anchors. By default, records are signed with SHA-1 and SHA-256 encryption. You can select other encryption algorithms as well.
You don’t need to go through the configuration process each time you sign a zone. The signing keys and other signing parameters are available for reuse.