Knowledge Base

DNS Records Associated with DNSSEC



This article provides information on the DNS resource records used in DNS Security Extensions (DNSSEC)



As mentioned in Introduction to DNS Security Extensions, DNSSEC is a set of extensions to DNS which provide a measure of security for it. Specifically, responses to DNS queries can be validated - verified as being genuine - when DNSSEC is implemented properly. In order to accomplish this, several new types of DNS records are needed. This article lists them and provides a brief description of each.


DNS Record Types Specific to DNSSEC:

  • DNSKEY: A DNSKEY record contains the public key of a signed DNS zone. Therefore, a validating server must obtain the DNSKEY record for a particular zone in order to validate responses to queries for that zone. A zone's DNSKEY record may be manually added to a validating server in the form of a trust anchor, or it can be retrieved during validation using a standard DNS query. More than one DNSKEY record may exist for a particular zone, as a zone may be signed multiple times.
  • DS (Delegation Signer): This record is used to secure a delegation to a child zone from its parent, creating a chain of trust. Unlike a DNSKEY record, a DS record contains only a hash of a public key (the key for the child zone). Each child zone should have a corresponding DS record in its parent zone. In Windows Server, DS records are not created automatically; they must be created manually whenever a child zone is signed. The parent zone must then be re-signed. As long as the delegations and DS records are created properly, a DNS server with only a single trust anchor for a parent zone can perform validation for all of its signed child zones (and the signed child zones of those child zones, and so on).
  • RRSIG (Resource Record Signature): When a zone is signed, an RRSIG record is created for each existing resource record set (RRset) in the zone. An RRset is defined as the set of records in a zone with the same name, class, and type - for example, every host record named www in the example.com zone. Many RRsets only contain a single record. Each RRSIG record contains a digital signature for its corresponding RRset. Although each RRset typically has only one RRSIG record associated with it, this is not always the case; as mentioned above, a zone may be signed multiple times using multiple keys. In this case, each RRset would have an RRSIG record for each key. When a DNS server receives a query requesting DNSSEC data, it sends a response consisting of the requested RRset and any corresponding RRSIG records.
  • NSEC (Next Secure): This record is used to provide authenticated denial of existence - in other words, to authoritatively assert that a particular DNS name does not exist in a zone. An NSEC record does this by asserting the names of the two records that do exist on either side of the queried name when the zone's records are arranged in a particular order. Essentially, NSEC records represent "gaps" in the namespace. This type of record introduces a potential security issue by making it relatively easy for an attacker to enumerate all records in a zone, a task that is quite a bit more difficult on an unsigned zone. NSEC3 (see below) was introduced to remedy this, and NSEC records should not be used on systems that support NSEC3.
  • NSEC3: This record performs the same function as an NSEC record but fixes the "zone walking" security issue inherent in NSEC records by hashing the names of the two records on either side of the queried record. These names may be hashed a number of times, with cryptographic salt optionally appended prior to each hash.
  • NSEC3PARAM: This record contains the set of parameters (hashing algorithm, number of iterations, and salt) used to generate the set of NSEC3 records in a signed zone. NSEC3PARAM records are not used by resolvers or validating servers but are used by secondary servers to determine the correct set of NSEC3 records to use in negative responses to queries.

DS, NSEC3, and NSEC3PARAM records are only supported in Windows Server 2012 and later versions.




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.

Article ID: SLN290749

Last Date Modified: 10/01/2014 08:43 AM


Rate this article

Accurate
Useful
Easy to understand
Was this article helpful?
Yes No
Send us feedback
Comments cannot contain these special characters: <>()\
Sorry, our feedback system is currently down. Please try again later.

Thank you for your feedback.