DNSSEC Terminology
Updated: October 7, 2009
Applies To: Windows Server 2008 R2
Tip
This topic applies to DNSSEC in Windows Server 2008 R2. DNSSEC support is greatly enhanced in Windows Server 2012. For more information, see DNSSEC in Windows Server 2012.
The following table displays a list of DNSSEC-related terms used in this guide.
Term |
Definition |
Reference |
Authentication chain |
A chain of signed and validated DNS records starting from a preconfigured trust anchor to some child zone in the DNS tree. |
RFC 4035 [7] Section 5 |
Delegation Signer (DS) record |
A DNSSEC record type used to secure a delegation. |
RFC 4034 [6] Section 5 |
DNS Extension (EDNS0) |
A DNS record that carries extended DNS header information, such as the DO bit and maximum UDP packet size. |
RFC 2671 [3] |
DNS Security Extensions (DNSSEC) |
Extensions to the DNS service that provide mechanisms for signing and securely resolving DNS data. |
RFCs 4033 [5], 4034 [6], and 4035 [7] |
DNSKEY record |
A DNSSEC record type used to store a public key. |
RFC 4034 [6] Section 2 |
DNSSEC OK (DO) bit |
A bit in the EDNS0 portion of a DNS request that signals that the client is DNSSEC-aware. |
RFC 4035 [7] Section 3.2.1 |
Double signature |
Double signature is a key rollover method where a future key and signatures generated using it are published into the DNS zone before the existing key and its signatures are deleted, thus leaving two sets of keys and associated signatures in the zone at any given time. |
RFC 4641 |
Island of Security |
A signed zone that does not have an authentication chain from its delegating parent zone. |
RFC 4033 [5] Section 2 |
Key Signing Key (KSK) |
The KSK is an authentication key that corresponds to a private key used to sign one or more other signing keys for a given zone. Typically, the private key corresponding to a KSK will sign a ZSK, which in turn has a corresponding private key that will sign other zone data. Local policy may require that the ZSK be changed frequently, while the KSK may have a longer validity period in order to provide a more stable secure entry point into the zone. Designating an authentication key as a KSK is purely an operational issue: DNSSEC validation does not distinguish between KSKs and other DNSSEC authentication keys, and it is possible to use a single key as both a KSK and a ZSK. |
RFC 4033 section 2 |
Next Secure (NSEC) record |
A DNSSEC record type used to prove non-existence of a DNS name. |
RFC 4034 [6] Section 4 RFC 5155 (NSEC3) |
Non-validating security-aware stub resolver |
A security-aware stub resolver that trusts one or more security-aware DNS servers to perform DNSSEC validation on its behalf. |
RFC 4033 [5] Section 2 |
Offline zone signing |
The process of signing or re-signing a file that contains the DNS data for a zone on a machine that is not an authoritative DNS server for the zone. Ideally the machine on which zone signing is performed is not network-connected. The signed zone file created by this process can then be transferred to an authoritative DNS server and loaded. |
RFC 4035 [7] Section 2 |
Online zone signing |
The process of signing or incrementally re-signing a zone while it is loaded by the DNS server. This requires that private keys be accessible to the DNS server process, and hence is less secure than offline zone signing. |
RFC 4035 [7] Section 2 |
Pre-publication |
Pre-publication is a key rollover method where a key for future use is added and published in the DNS zone without generating any signatures. |
RFC 4641 |
Resource Record Set (RRSet) |
Each DNS Resource Record (RR) has a label, class, type, and data. It is meaningless for two records to ever have label, class, type and data all equal - servers should suppress such duplicates if encountered. It is however possible for most record types to exist with the same label, class and type, but with different data. Such a group of records is hereby defined to be a Resource Record Set (RRSet). |
RFC 2181 |
Resource Record Signature (RRSIG) record |
A DNSSEC record type used to hold a signature which covers a set of DNS records for a particular name and type. |
See RFC 4034 [6] Section 3 |
Secure entry point (SEP) key |
SEP keys are a subset of public keys within the DNSKEY RRset. A SEP key is used either to generate a DS RR or is distributed to resolvers that use the key as a trust anchor. |
RFC 3757 |
Security-aware DNS server |
A DNS server that understands the DNS security extensions defined in RFCs 4033 [5], 4034 [6], and 4035 [7]. In particular, a security-aware DNS server is an entity that receives DNS queries, sends DNS responses, supports the EDNS0 [3] message size extension and the DO bit, and supports the DNSSEC record types and message header bits. |
RFCs 4033 [5], 4034 [6], and 4035 [7] |
Security-aware resolver |
A resolver that understands the DNS security extensions defined in RFCs 4033 [5], 4034 [6], and 4035 [7]. In particular, a security-aware resolver is an entity that sends DNS queries, receives DNS responses, supports the EDNS0 [3] message size extension and the DO bit, and supports the DNSSEC record types and message header bits. |
RFC 4033 [5] Section 2 |
Signed zone |
A zone whose records are signed as defined by RFC 4035 [7] Section 2. A signed zone contains DNSKEY, NSEC, RRSIG, and DS records. These records allow DNS data to be validated by resolvers. |
RFC 4035 [7] Section 2 |
Trust anchor |
A preconfigured public key associated with a particular zone. A trust anchor allows a DNS resolver to validate signed DNSSEC records for that zone and to build authentication chains to child zones |
RFC 4033 [5] Section 2 |
Unsigned zone |
Any DNS zone that has not been signed as defined by RFC 4035 [7] Section 2. |
RFC 4035 [7] Section 2 |
Zone Signing Key (ZSK) |
An authentication key that corresponds to a private key used to sign a zone. Typically, a zone signing key will be part of the same DNSKEY RRset as the key signing key whose corresponding private key signs this DNSKEY RRset, but the zone signing key is used for a slightly different purpose and may differ from the key signing key in other ways, such as validity lifetime. Designating an authentication key as a zone signing key is purely an operational issue; DNSSEC validation does not distinguish between zone signing keys and other DNSSEC authentication keys, and it is possible to use a single key as both a key signing key and a zone signing key. |
RFC 4033 section 2 |
For more information about DNSSEC key concepts, see Appendix A: Reviewing Key DNSSEC Concepts.
See Also
Concepts
Introduction to DNSSEC
Appendix B: The Name Resolution Policy Table (NRPT)