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:

secure.contoso.com      DS   32801 8 1 (
                        4E1FD2F988BC942E666132250395123B0A54
                        D246 )
                        DS   32801 8 2 (
                        92838CE772067BF04FA942C44C952384267C
                        8D8091A700278D9DC5244F973D88 )
                        DS   53750 8 1 (
                        1D423EBD2C45D7CD7B957C7D7E7795C1C726
                        3275 )
                        DS   53750 8 2 (
                        1073224EBC9ECFEF5C335A4AD10721EA2894
                        63A08CE5E820C511A48220067A2F )


secure.contoso.com   1546847232   DNSKEY   257   3   7   (
                        AwEAAb4v+rZFLosf4qV1/0KZrRcPdj/ljk+Y
                        56XQtuIjGzZG+HH3ys8zhGwJ2WRH3AyRlzLQ
                        5ebMVP12Fmacx5UjhLAydT3rrCbqmHvrrLq9
                        7yJa9Sgeakb/0bwUIE2K2n/g73RFAu8eM0Ut
                        geLZAGkRxdvS8tTAHgoeVCmwbZitxwjVSsZ1
                        cEK7yQJKspwghszXBfonC202GvgCp6F30J4E
                        1LjVJsqPo9ZrccFpFZS4kSEfEz45YXPP/VBx
                        IFRgejdtBL9j6yqf4qo/GynjPSWJY3KOLn/r
                        2wWzujxTLIdpXUdowXGPa8jJU/tDi9avo7+M
                        XIF3LBpvF9derokq/3L6AmE=
                        ) ; key tag = 37458
                    1546847232   DNSKEY   257   3   7   (
                        AwEAAdwL+faFmv/JToQFA94PnqfXI/ZCYvEq
                        S5jxmLeZKjl5/xMA2hhaGeKtmS8yTMqeYWm5
                        p0MkzDKFMyisjF03N7aBsgLy33GVAea2ipxt
                        hjec14q/M37KTgAFh2OyjM4z+Rf+osip0dsv
                        KVl5vXgYYFXqf52aEoYiYe2PfWM0mJtl1NlA
                        uYAu4h3140AHynIIJYJkCV+ptHuSECEFYNBf
                        aO1Qg9KKVvH7sH9Crfz2sHb0+sVsi2+IgBjD
                        ILXCW8af7bowl0yhL1qB+njegKxzI8IpnOA+
                        MDWZvaJCtTQGPUjTwG0qjWBzO4bONHTLqkyR
                        /jvPTciJ+Qah3h5apITtwL8=
                        ) ; 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 microsoft.com. a.root-servers.net
com   nameserver = m.gtld-servers.net
com   nameserver = l.gtld-servers.net
com   nameserver = k.gtld-servers.net
com   nameserver = j.gtld-servers.net
com   nameserver = i.gtld-servers.net
com   nameserver = h.gtld-servers.net
com   nameserver = g.gtld-servers.net
com   nameserver = f.gtld-servers.net
com   nameserver = e.gtld-servers.net
com   nameserver = d.gtld-servers.net
com   nameserver = c.gtld-servers.net
com   nameserver = b.gtld-servers.net
com   nameserver = a.gtld-servers.net
…

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

PS C:\> nslookup -q=NS microsoft.com. a.gtld-servers.net
microsoft.com   nameserver = ns3.msft.net
microsoft.com   nameserver = ns1.msft.net
microsoft.com   nameserver = ns5.msft.net
microsoft.com   nameserver = ns2.msft.net
microsoft.com   nameserver = ns4.msft.net
…

The following example uses the Get-DnsServerZoneDelegation cmdlet to verify delegation for corp.adatum.com and finance.corp.adatum.com.

PS C:\> Get-DnsServerZoneDelegation -Name adatum.com -ChildZoneName corp -ComputerName dc2.contoso.com

ZoneName                           ChildZoneName                      NameServer                         IPAddress
--------                           -------------                      ----------                         ---------
adatum.com                         corp.adatum.com.                   dc2.contoso.com.                   192.168.0.2


PS C:\> Get-DnsServerZoneDelegation -Name corp.adatum.com -ChildZoneName finance -ComputerName dc2.contoso.com

ZoneName                           ChildZoneName                      NameServer                         IPAddress
--------                           -------------                      ----------                         ---------
corp.adatum.com                    finance.corp.adatum.com.           dc2.contoso.com.                   192.168.0.2

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 A.B.C.com can be validated using a trust anchor for the signed zone C.com, provided that B.C.com is also signed. If B.C.com is not signed, then C.com 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 adatum.com -DSSetFile "c:\windows\system32\dns\dsset-corp.adatum.com"
PS C:\> Get-DnsServerResourceRecord -ZoneName adatum.com -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, corp.adatum.com, were imported into the parent zone, adatum.com, 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 finance.corp.adatum.com must be added to corp.adatum.com to complete a chain of authentication from finance.corp.adatum.com to adatum.com. See the following example.

PS C:\> Import-DnsServerResourceRecordDS -ZoneName corp.adatum.com -DSSetFile "c:\windows\system32\dns\dsset-finance.corp.adatum.com"
PS C:\> Get-DnsServerResourceRecord -ZoneName corp.adatum.com -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 adatum.com namespace.

PS C:\> Get-DnsClientNrptPolicy -Effective


Namespace                        : .adatum.com
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 192.168.0.4 has a trust anchor for adatum.com.

PS C:\> Get-DnsServerTrustPoint -ComputerName 192.168.0.4

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

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

PS C:\> Resolve-DnsName -Name mail.finance.corp.adatum.com -Type A -Server 192.168.0.4 -dnssecok

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
mail.finance.corp.adatum.com                   A      3599  Answer     192.168.0.150

Name        : mail.finance.corp.adatum.com
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      : finance.corp.adatum.com
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 (http://tools.ietf.org/search/rfc5011).

System_CAPS_importantImportant

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 secure.contoso.com zone, the following files are created on the Key Master.

Key type

File name

DNSKEY

keyset-secure.contoso.com

DS

dsset-secure.contoso.com

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.


secure.contoso.com.   3600   IN   DNSKEY   257 3 8 (
                        AwEAAbMK6im/lrLB546v9jl41p/g7/30X9Cn
                        k5anwOnQu8JBOYt0CUiXci1lxO/280NHB/Eu
                        1r7Nk0AQPwvZ7Dqbdd7eqvKX/WJgK85UtONR
                        PjhbCNe4vj7Qr8GmUW/aQdDIZqqdstLJINfE
                        k3GgOFslSUkoWpP+z9BwnuEnv6jFkguLikj6
                        X9aM1N0bjLMDvi34PlRKGxOA6WsDyN96abzz
                        Iuj00LjKBL4+0JBwuRB+tIOAMLLsXtLI4Dby
                        Zz6/ewZHI0FELbDnUDj5hqCWU+J2IBTbs4mW
                        WKRHpTdZtNYda8Oy9+SMQJh/pIepKAjrJkzM
                        wZWFgg0qqn5QXVIms3T/pZk=
                        ) ; key tag = 62111
                       3600   IN   DNSKEY   257 3 8 (
                        AwEAAY/kENeHkSmtdBzPhiHiDGPcbwA7nkau
                        MsASiXOMIM+2btAYq6GczO45kuemvXmJU1o6
                        eyeJmphDGm649UOjOiebIokJ31m3K1mymrpF
                        R6DfY2WTwLMtnPuiiyvif9qcF5yKoVthownG
                        kG3/vJbDyRGONteTtJFOZZDtDHLOh624jz73
                        KUds4uq6VWZ+UhCZFneNNtz2e4NyjxGSf5ZK
                        kKOpmj/Q2veAbV8Ck5fieydOMvOi2HM6oop9
                        YrAGRUvmwH2Bg/enDiWr7+FDCEzem4bP4QDT
                        ng6qjSvNGfRTtq6x4zySPcd7BMv1Q5nBpdjU
                        UCNXRU37nTXB7/sSKQCmFic=
                        ) ; 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.

secure.contoso.com.   3600   IN   DS   16945 8 1 (
                        86A50FB9A986CB32BF878FFFEF3DC00D5732
                        3ED8 )
                     3600   IN    DS   16945 8 2 (
                        59FFBE7F9C06FC939C772DDAA8D7A5F3B316
                        4082059FBC5D689DFD6B0290310E )
                     3600   IN    DS   39301 8 1 (
                        565B5B1FC1616CF84514D28814D34A1C2397
                        8008 )
                     3600   IN    DS   39301 8 2 (
                        6A634D28ABF17E723EDBCD981120DC736A08
                        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 adatum.com

TrustAnchorName                TrustAnchorType      TrustAnchorState     TrustAnchorData
---------------                ---------------      ----------------     ---------------
adatum.com.                    DNSKEY               Valid                [48955][DnsSec][RsaSha256][AwEAAcTxpB/tf4DA...
adatum.com.                    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
adatum.com.                              Active               1/24/2014 1:02:28 PM      1/24/2014 1:02:44 PM
corp.adatum.com.                         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.

Status

Description

Valid or Active

Trusted for DNSSEC validation

Add Pending

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

Missing

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

Revoked

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.

Show: