Information on DNSSEC trust anchors

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 zone's chain of trust is intact if the following are all true:

  • The zone is signed and there is a secure delegation to it from
  • The 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 zone (perhaps because an administrator neglected to create the corresponding DS record), a validating server could perform validation for the zone if it had a trust anchor for either or

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.

ID de l'article : SLN290769

Date de la dernière modification : 10/07/2014 12:14 PM

Noter cet article

Facile à comprendre
Avez-vous trouvé cet article utile ?
Oui Non
Envoyez-nous vos commentaires
Les commentaires ne doivent pas contenir les caractères spéciaux : <>()\
Désolé, notre système de collecte des commentaires est actuellement indisponible. Veuillez réessayer ultérieurement.

Merci pour vos commentaires.