Also be aware that some zones may not benefit greatly from being signed. A public DNS zone - a zone accessible from the internet - is far more likely to be the target of a DNS spoofing attack than an internal zone that is only accessible to machines on a local network. Unless a corporate security policy or other requirement mandates it, signing an internal zone may not provide enough of a benefit to outweigh the additional overhead associated with it.
The procedure for signing a DNS zone has been greatly improved in Windows Server 2012 over that in Windows Server 2008 R2, but it is still fairly complex. Follow these steps to sign a zone:
Note: Although the following steps illustrate the signing of a forward lookup zone, the same procedure can be used to sign reverse lookup zones.
Open the DNS Manager console. If necessary, expand the server in the left pane and select Forward Lookup Zones. Note the DNSSEC Status column, which will indicate whether or not a zone has been signed.
Right-click the appropriate zone and select DNSSEC > Sign the Zone. This will launch the Zone Signing Wizard. Note: Due to a quirk of the DNS Manager console, you may need to expand Forward Lookup Zones and select the appropriate zone in the left pane before the option to sign it will become available.
Click Next on the introductory screen of the wizard.
Select Customize zone signing parameters and click Next. Note: It is also possible to sign the zone using the parameters of an existing signed zone, if there is one, or a default set of parameters, but we will select Customize in this article to illustrate all of the parameters.
Choose the Key Master for the zone. This is the server that generates the cryptographic keys and performs the actual signing of the zone. By default, the local server will be chosen, but any server hosting a primary (writable) copy of the zone may be the Key Master. Each signed zone can have only one Key Master, but this role can be moved to another server after the zone is signed. Click Next when done.
Review the description of the Key Signing Key (KSK) and click Next.
Click Add to open the New Key Signing Key window. At least one KSK must be generated, but it is possible to generate up to three per cryptographic algorithm. The following parameters are available when generating a new KSK:
Generate new signing keys or use pre-generated keys: Pre-generated keys will appear if the zone has been previously signed and un-signed.
Cryptographic algorithm: There are several algorithms to choose from. It is recommended that you choose something other than RSA/SHA-1.
Key length: A longer key length provides greater security at the cost of a heavier workload for the server, although the length of the KSK has less of an effect on the workload than the length of the Zone Signing Key (see below).
Key storage provider: Choose the Microsoft Software Key Storage Provider if keys are to be distributed through Active Directory.
DNSKEY signature validity period: The length of time for which the RRSIG records for the public keys are valid.
Replicate the private key to all authoritative DNS servers: This is recommended for AD-integrated zones, as the private key will be replicated to all DNS servers that host the zone.
Key rollover: Enabling automatic rollover is highly recommended, as it allows the KSK to be automatically replaced as it expires, with no break in validity.
Click OK to generate a KSK with the selected parameters. The new KSK will now appear in the list, as shown below.
You may create another KSK at this point (which will increase the workload of the Key Master) or click Next to continue.
Review the description of the Zone Signing Key (ZSK) and click Next.
Click Add to open the New Zone Signing Key window. At least one ZSK must be generated, but it is possible to generate up to three per cryptographic algorithm. Most of the parameters of the ZSK are the same as the ones used to generate a KSK (see above), with a couple of exceptions due to the different roles of the KSK and ZSK:
DS signature validity period: The length of time for which the signature of a DS record created in this zone is valid. This only comes into play if a secure child zone exists and is properly delegated.
Zone record validity period: The length of time for which the RRSIG records of all other records in the zone are valid.
Note that ZSKs typically have a shorter key length and significantly shorter rollover frequency than the KSK.
Click OK to generate a ZSK with the selected parameters. The new ZSK will now appear in the list, as shown below.
You may create another ZSK at this point (which will increase the workload of the Key Master) or click Next to continue.
Choose the method of authenticated denial of existence. NSEC3 is highly recommended (see DNS Records Associated with DNSSEC for more information) and offers the following parameters:
Iterations: The number of times the hashing algorithm will be applied to the names of records returned in an NSEC3 response.
Salt: This represents a random character string that is appended to the names of records returned in an NSEC3 response before they are hashed. It should generally always be selected. You have the option of selecting the length of the salt.
Use opt-out to cover unsigned delegations: This is typically only needed if the zone in question contains a large number of insecure delegations (delegations to unsigned zones). If all delegations are secure (in other words, if all child zones are properly signed) or there are no delegations, this setting has no effect.
Click Next to proceed.
Specify whether trust anchors for the zone should be automatically distributed and/or automatically updated when the keys for the zone roll over.
Distribution of trust anchors: Any server that has a trust anchor for the zone will be able to validate responses for the zone. This option will store the zone's trust anchor in the ForestDnsZones application directory partition if this server is a domain controller, which results in the trust anchor being replicated to all other DNS servers running on domain controllers in the Active Directory forest.
Automatic updates of trust anchors: When a zone's keys roll over (expire and are replaced), the corresponding trust anchor must be updated. Selecting this option allows this process to occur automatically when the keys automatically roll over, so if automatic key rollover is enabled, this option is highly recommended. Note that if the keys are manually rolled over, this option does not update the trust anchor; it must be manually updated.
Click Next to proceed.
Specify the following signing and polling parameters:
DS record generation algorithm: The cryptographic algorithm that will be used to generate a Delegation Signer (DS) record, which is used to secure a delegation to a child zone. See DNS Records Associated with DNSSEC for more information on DS records.
DS record TTL: The TTL (time-to-live) value of a DNS record represents how long the record can remain in a cache after it is returned in response to a query. This parameter represents the TTL value, in seconds, of a DS record.
DNSKEY record TTL: See above. This parameter represents the TTL value, in seconds, of a DNSKEY record.
Secure delegation polling period: The Key Master will regularly poll any child zones to keep their associated DS records up to date. This value specifies how often this polling occurs.
Signature inception: This value represents how far in the past, in hours, the validity period of signatures should begin at the time the zone is signed. For example, if this parameter is given a value of 2, the validity period of all signatures will be set to begin two hours before the time at which the zone is signed.
Click Next to proceed.
Review the summary and click Next to begin the zone-signing process. This may take some time to complete, depending on the size of the zone and the parameters selected in the previous steps.
Click Finish when the wizard indicates that the zone has been signed. The DNS Manager console will now indicate that the zone has been signed, and its Key Master will be shown in the appropriate column.
The zone will now contain a number of new records, as shown below, though these records may not appear immediately:
Quick Tips content is self-published by the Dell Support Professionals who resolve issues daily. In order to achieve a speedy publication, Quick Tips may represent only partial solutions or work-arounds that are still in development or pending further proof of successfully resolving an issue. As such Quick Tips have not been reviewed, validated or approved by Dell and should be used with appropriate caution. Dell shall not be liable for any loss, including but not limited to loss of data, loss of profit or loss of revenue, which customers may incur by following any procedure or advice set out in the Quick Tips.