Information on DNSSEC trust anchors

This article provides general information on DNSSEC trust anchors in Windows Server 2012

In order for a server to perform DNSSEC validation of DNS responses, the server must have at least one trust anchor installed. A trust anchor corresponds to a DNS zone (domain) and provides a starting point for a chain of trust: as long as the trust anchor is validated when it is installed and hasn't expired since then, responses for that zone can be validated as well. Further, if there are secure delegations present between that zone and a child zone, responses for the child zone can also be validated.

There are two types of trust anchors:

  • DNSKEY: A DNSKEY trust anchor contains a public key for a signed DNS zone. It is used to decrypt the signatures of DNSSEC data for the zone. A given zone may have multiple DNSKEY records. This increases the time required to perform validation for that zone, as the validating server will attempt to validate using each DNSKEY record until it finds a match or runs out of DNSKEY records.
  • DS: A DS (Delegation Signer) trust anchor contains the hash of a public key for a child zone of the zone where the DS key is stored. In other words, a parent zone will contain the DS records of all of its signed child zones. DS records represent secure delegations from the parent zone to the child zone. Since the DS trust anchor only contains a hash of a public key, it must be used to obtain the child zone's corresponding DNSKEY record before records in the child zone can be validated.

As long as a valid trust anchor for the root (.) zone has been installed (a process covered in How to Retrieve the DNSSEC Trust Anchor for the Root DNS Zone in Windows Server 2012), a security-aware DNS server can perform validation for all zones with an intact chain of trust from the root. A given zone has an intact chain of trust from the root if the following conditions are met:

  • The zone in question is signed.
  • Every zone between it and the root zone is also signed.
  • There are secure parent-child delegations in place in every zone from the root zone to the zone in question.

For example, the secure.testdomain.com zone's chain of trust is intact if the following are all true:

  • The secure.testdomain.com zone is signed and there is a secure delegation to it from testdomain.com.
  • The testdomain.com zone is signed and there is a secure delegation to it from com.
  • The com zone is signed and there is a secure delegation to it from the root zone. (This is demonstrably true as of this writing.)

If there is a break in a zone's chain of trust, a validating server must have a trust anchor manually configured in order to perform validation for the zone. In the example above, if the only thing missing were a secure delegation from the com zone to the testdomain.com zone (perhaps because an administrator neglected to create the corresponding DS record), a validating server could perform validation for the secure.testdomain.com zone if it had a trust anchor for either testdomain.com or secure.testdomain.com.

In Windows Server 2012, trust anchors can be imported from a file or manually created by obtaining and entering the relevant information. Importing from a file is the simpler method but is only possible when you have control over the server hosting the zone for which a trust anchor is needed, as you must first export that zone's trust anchor to a file before it can be imported on the validating server. This procedure is covered in How to Export a DNSSEC Trust Anchor in Windows Server 2012.

It is not possible to export a trust anchor from a server over which you have no control; in this case, the trust anchor must be created manually using data that can be retrieved from DNS: the name of the zone, its public key, and the algorithm used in the key's generation. This procedure is detailed in How to Add a DNSSEC Trust Anchor for a Remote Zone in Windows Server 2012.

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.

Artikel-ID: SLN290769

Senast ändrad: 10/07/2014 12:14 PM

Betygsätt den här artikeln

Lätt att förstå
Var den här artikeln till nytta?
Ja Nej
Skicka dina synpunkter
Kommentarer får inte innehålla följande specialtecken: <>()\
Vårt feedbacksystem är tyvärr ut funktion just nu. Försök igen senare.

Tack för dina synpunkter.