Trust Anchors


Updated: February 11, 2014

Applies To: Windows Server 2012 R2, Windows Server 2012

A trust anchor (or trust “point”) is a public cryptographic key for a signed zone. Trust anchors must be configured on every non-authoritative DNS server that will attempt to validate DNS data. This section discusses some key concepts about trust anchors.

Trust anchors can be of two types: DNSKEY or DS. Only DNSKEY trust anchors were supported in Windows Server 2008 R2. Both DNSKEY and DS trust anchors are supported in Windows Server 2012 and Windows Server 2012 R2. For more information about DNSKEY, DS, other DNSSEC-related resource records, and how to view them, see DNSSEC-related resource records.

A DNSKEY trust anchor is a public key from a DNSKEY resource record. It is typically larger in size than a DS trust anchor. A DS trust anchor is a hash of a public key. Because it is only a hash, DS trust anchors are typically smaller. The following are examples of DS and DNSKEY trust anchors, respectively:      DS   32801 8 1 (
                        D246 )
                        DS   32801 8 2 (
                        8D8091A700278D9DC5244F973D88 )
                        DS   53750 8 1 (
                        3275 )
                        DS   53750 8 2 (
                        63A08CE5E820C511A48220067A2F )   1546847232   DNSKEY   257   3   7   (
                        ) ; key tag = 37458
                    1546847232   DNSKEY   257   3   7   (
                        ) ; key tag = 9468

For information about the components of a trust anchor, see Working with trust anchors in this topic.

A validating DNS server that uses a DS trust anchor must query the authoritative DNS server to obtain the full DNSKEY resource record set (RRSet). This process is called "priming" of the trust anchor and can be an advantage because it forces the validating server to acquire up-to-date information.

You can install one or both types of trust anchors on a validating DNS server. Active Directory-integrated DNS servers store trust anchors in Active Directory. If a DNS server is not Active Directory-integrated, trust anchors are stored in the text file: %windir%\system32\dns\TrustAnchors.dns.

DNSSEC validation is enabled by default on the Advanced tab of DNS server properties. You can modify and check the status of this setting with dnscmd.exe. See the following example.

PS C:\> dnscmd /info /enablednssec
Query result:
Dword:  0 (00000000)
Command completed successfully.

In the previous example, DNSSEC validation is disabled. To enable DNSSEC validation, you must configure the value to 1.

PS C:\> dnscmd /config /enablednssec 1
Registry property enablednssec successfully reset.
Command completed successfully.

PS C:\> dnscmd /info /enablednssec
Query result:
Dword:  1 (00000001)
Command completed successfully.

You can modify this setting in DNS Manager or by using the dnscmd.exe tool.

A delegation is a referral of authority from one DNS server to a different DNS server for a specific namespace. Delegations are commonly used to assign authority for child zones.

For example, the Internet root DNS servers delegate DNS authority for .com to generic top-level domain (gTLD) servers. See the following example using nslookup.exe.

PS C:\> nslookup -q=NS
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =
com   nameserver =

In turn, the gTLD servers delegate authority for to authoritative DNS servers. See the following example.

PS C:\> nslookup -q=NS   nameserver =   nameserver =   nameserver =   nameserver =   nameserver =

The following example uses the Get-DnsServerZoneDelegation cmdlet to verify delegation for and

PS C:\> Get-DnsServerZoneDelegation -Name -ChildZoneName corp -ComputerName

ZoneName                           ChildZoneName                      NameServer                         IPAddress
--------                           -------------                      ----------                         ---------                                 

PS C:\> Get-DnsServerZoneDelegation -Name -ChildZoneName finance -ComputerName

ZoneName                           ChildZoneName                      NameServer                         IPAddress
--------                           -------------                      ----------                         ---------                    

Delegations are important because they establish a chain of authentication for child zones. If all zones in the chain are signed with DNSSEC, resolving DNS servers can have only a single delegation signer (DS) trust anchor installed, provided that appropriate DS records are available in the parent zone.

With delegations, it is not always necessary to install a trust anchor for every zone that a caching DNS server can validate. Under certain conditions, you can build a chain of authentication (a chain of trust) where it is sufficient for the DNS server to have only a DS trust anchor installed for the parent zone.

However, if the chain of trust is broken, then a child zone must have its own trust anchor installed. For example, DNS responses for the signed zone can be validated using a trust anchor for the signed zone, provided that is also signed. If is not signed, then becomes an island of trust and requires its own trust anchor. The following diagram shows this scenario.

Validation Tree

In scenarios where islands of trust are present, a trust anchor must be configured for the root of each island. In the preceding diagram, zones that are shown in blue are signed while those in white are not. The right side of the tree is completely signed; the left side of the tree is intermittently signed. In order for a DNS server to be able to perform DNSSEC validation for all the signed zones, you must configure trust anchors for the zones in yellow.

Additional trust anchors for the other signed zones can be added to a DNS server, but the trust anchors for the zones in yellow are sufficient for full validation of all signed zones.

After a zone is DNSSEC-signed, and if the parent of the zone is also DNSSEC-signed, the signed delegation records must be added to the parent zone, and the parent zone must be re-signed. This process must be performed every time a new child zone is signed for the first time, or if a child zone is re-signed with a new key signing key. If you own a signed zone but do not own the children of the zone, and if the children zones are in the process of being DNSSEC-signed one at a time, you must re-sign your zone after adding the delegation records each time a new child zone is signed. However, the process of signing multiple zones can be optimized if you own the parent as well as the children zones that are to be signed.

Like the DNSKEY resource record, the delegation signer (DS) resource record can be used to create a trust anchor for a signed zone. The DS record is smaller in size than a DNSKEY record because it contains only a hash of the public key.

The DS record is not added to a zone during the signing process like some DNSSEC-related resource records, even if a delegation already exists in the zone. To add a DS record, you must manually add or import it. Fortunately, the DS resource record set (DSSET) is automatically added as a file to the Key Master when a zone is signed. You can use this file with the Import-DnsServerResourceRecordDS cmdlet to import DS records to the parent zone. See the following example.

PS C:\> Import-DnsServerResourceRecordDS -ZoneName -DSSetFile "c:\windows\system32\dns\"
PS C:\> Get-DnsServerResourceRecord -ZoneName -RRType DS

HostName                  RecordType Timestamp            TimeToLive      RecordData
--------                  ---------- ---------            ----------      ----------
corp                      DS         0                    01:00:00        [58555][Sha1][RsaSha1NSec3]
corp                      DS         0                    01:00:00        [58555][Sha256][RsaSha1NSec3]
corp                      DS         0                    01:00:00        [63513][Sha1][RsaSha1NSec3]
corp                      DS         0                    01:00:00        [63513][Sha256][RsaSha1NSec3]

In the previous example, DS records for the child zone,, were imported into the parent zone,, by using the DSSET file that is located in the c:\windows\system32\dns directory. The DSSET file was located in this directory because the local DNS server is the Key Master for the child zone. If the Key Master DNS server for a child zone is not the same computer as the primary authoritative DNS server for the parent zone where you are adding the DS record, you must obtain the DSSET file for the child zone and make it available to the primary authoritative server for the parent zone. Alternatively, you can manually add DS records.

DS records must be added to each parent zone in a chain of authentication. For example, DS records for must be added to to complete a chain of authentication from to See the following example.

PS C:\> Import-DnsServerResourceRecordDS -ZoneName -DSSetFile "c:\windows\system32\dns\"
PS C:\> Get-DnsServerResourceRecord -ZoneName -RRType DS

HostName                  RecordType Timestamp            TimeToLive      RecordData
--------                  ---------- ---------            ----------      ----------
finance                   DS         0                    01:00:00        [58990][Sha1][RsaSha256]
finance                   DS         0                    01:00:00        [58990][Sha256][RsaSha256]
finance                   DS         0                    01:00:00        [40231][Sha1][RsaSha256]
finance                   DS         0                    01:00:00        [40231][Sha256][RsaSha256]

If the chain of authentication is completed with proper delegations in each zone and DS records added to the parent, a recursive DNS server can have a trust anchor present for only the parent zone and provide validation for all child zones. In the following example, a DNS client requires validation for the namespace.

PS C:\> Get-DnsClientNrptPolicy -Effective

Namespace                        :
QueryPolicy                      : QueryIPv6Only
SecureNameQueryFallback          : FallbackPrivate
DirectAccessIPsecCARestriction   :
DirectAccessProxyName            :
DirectAccessDnsServers           :
DirectAccessEnabled              : False
DirectAccessProxyType            :
DirectAccessQueryIPsecEncryption :
DirectAccessQueryIPsecRequired   :
NameServers                      :
DnsSecIPsecCARestriction         :
DnsSecQueryIPsecEncryption       :
DnsSecQueryIPsecRequired         : False
DnsSecValidationRequired         : True
NameEncoding                     :

A resolving DNS server with IP address of has a trust anchor for

PS C:\> Get-DnsServerTrustPoint -ComputerName

TrustPointName                           TrustPointState      LastActiveRefreshTime     NextActiveRefreshTime
--------------                           ---------------      ---------------------     ---------------------                              Active               1/22/2014 2:05:50 PM      1/22/2014 2:06:06 PM

DNSSEC validation is successful for DNS queries in the zone because this zone and have the appropriate delegations and DS records.

PS C:\> Resolve-DnsName -Name -Type A -Server -dnssecok

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------                   A      3599  Answer

Name        :
QueryType   : RRSIG
TTL         : 3599
Section     : Answer
TypeCovered : A
Algorithm   : 8
LabelCount  : 5
OriginalTtl : 3600
Expiration  : 1/31/2014 10:03:18 PM
Signed      : 1/21/2014 9:03:18 PM
Signer      :
Signature   : {80, 88, 162, 208...}


Because trust anchors represent public keys for corresponding zones, trust anchors must be updated if the public keys for a zone change, such as when a zone is re-signed. Additionally, if trust anchors are distributed after a zone is signed and the zone becomes unsigned at a later date, trust anchors for the zone must be removed. If trust anchors are not removed when a zone is unsigned, DNS servers will continue to attempt validation of DNS responses for the zone, but this validation will fail and therefore DNS resolution for the zone will fail.

You can update trust anchors manually, or you can use the automated update mechanism as described in RFC 5011 (


Windows Server 2012 and Windows Server 2012 R2 fully support RFC 5011. Support for RFC 5011 is enabled on the authoritative DNS server on a zone-by-zone basis. However, trust anchor updates are only supported for automated key rollover. If you manually re-sign or unsign a zone, or manually roll zone signing keys, trust anchors on validating DNS servers are not automatically updated.

Trust anchors that have been enabled for RFC 5011 automatic updates have information that is stored in the file %windir%\system32\dns\RFC5011.csv on the DNS server where the trust anchor is installed.

When you sign a zone on a DNS server running Windows Server 2012 or later, the public DNSKEY and DS resource record sets (the set of all resource records of that type, also known as the RRSET) are stored as text files in the %windir%\system32\dns directory on the Key Master. The DNSKEY RRSET (or KEYSET) is stored as a file with the name keyset-<zone name> and the DS RRSET (or DSSET) is stored as a file with the name dsset-<zone name>.

For example, after signing the zone, the following files are created on the Key Master.

Key type

File name



During zone signing, DNSKEY resource records are also added to the zone along with RRSIG, NSEC, and other records. DS records are not automatically added to a zone.

These KEYSET and DSSET files can be used to export trust anchors for the zone and to manually add a trust anchor. For more information, see Procedure: Export a Trust Point and Procedure: Add a Trust Point.

The KEYSET (DNSKEY) file has the following format: <zone name> <TTL> IN DNSKEY <flags> <protocol> <algorithm> <Base64Data>; key tag = <key tag>. See the following example.   3600   IN   DNSKEY   257 3 8 (
                        ) ; key tag = 62111
                       3600   IN   DNSKEY   257 3 8 (
                        ) ; key tag = 8000

Two keys are present in the file. If the flag field is an odd number, the key represents a KSK (secure entry point). If the flag field is an even number, the key is a ZSK. In the previous example, both keys are KSKs because the flag field is 257. The protocol is always DNSSEC, which is represented by the number 3, and the algorithm is RSA/SHA-256 that corresponds to the number 8.

The DSSET (DS) file has the following format: <zone name> <TTL> IN DS <key tag> <algorithm> <type> ( digest ). See the following example.   3600   IN   DS   16945 8 1 (
                        3ED8 )
                     3600   IN    DS   16945 8 2 (
                        4082059FBC5D689DFD6B0290310E )
                     3600   IN    DS   39301 8 1 (
                        8008 )
                     3600   IN    DS   39301 8 2 (
                        CF7170E849303B9357B52D18F9D3 )

If you add a DS trust anchor to a DNS server and the DS record is present in the DNS zone—remember that DS records are not automatically added during zone signing—the DNS server uses the digest in the DS record to acquire a DNSKEY for the zone.

To view the status of a trust anchor on a DNS server, you can use the DNS Manager console or Windows PowerShell. Trust anchors are organized and displayed in the DNS Manager console tree under Trust Points. The Windows PowerShell cmdlets Get-DnsServerTrustAnchor and Get-DnsServerTrustPoint can also provide status of trust anchors. The Get-DnsServerTrustAnchor cmdlet requires that you specify a namespace, whereas Get-DnsServerTrustPoint displays all configured trust anchors on the DNS server if a name is not specified. See the following examples.

PS C:\> Get-DnsServerTrustAnchor -Name

TrustAnchorName                TrustAnchorType      TrustAnchorState     TrustAnchorData
---------------                ---------------      ----------------     ---------------                    DNSKEY               Valid                [48955][DnsSec][RsaSha256][AwEAAcTxpB/tf4DA...                    DNSKEY               Valid                [2504][DnsSec][RsaSha256][AwEAAYkCDUmGSkh+y...

PS C:\> Get-DnsServerTrustPoint

TrustPointName                           TrustPointState      LastActiveRefreshTime     NextActiveRefreshTime
--------------                           ---------------      ---------------------     ---------------------
.                                        DSPending            1/24/2014 1:02:28 PM      1/24/2014 1:02:44 PM                              Active               1/24/2014 1:02:28 PM      1/24/2014 1:02:44 PM                         Active               1/24/2014 1:02:28 PM      1/24/2014 1:02:44 PM

In the previous example, the root (.) trust anchor is not active; instead, it displays a status of DSPending. The following table shows the trust anchor states that are possible.



Valid or Active

Trusted for DNSSEC validation

Add Pending

Not yet trusted for DNSSEC validation, but becomes valid after an add hold-down period.


Trusted for DNSSEC validation, but was not found during the last active refresh cycle.


Revoked by an administrator and no longer valid for DNSSEC validation.

DS Pending

Waiting for a matching DNSKEY, which then becomes a valid trust anchor.

DS Invalid

Matched with a DNSKEY that cannot be a valid trust anchor.

In the previous example, the DS trust anchor for the root (.) zone is in a DS Pending state because access to the root DNSKEY record is currently blocked.