https://DevOpsCloud.io -- Cloud Monk Losang Jinpa, Ph.D., MCSE/MCT, GitOps DevOps Engineer

Return to Security-Related RFCs, Network Security, Container Security - Kubernetes Security, Cloud Security, Web Security, DevSecOps

See: 4034 on datatracker.ietf.org

RFC 4034 is a core document that specifies the DNS resource record types used by DNSSEC (Domain Name System Security Extensions), enabling DNS to be secured through the addition of cryptographic signatures. Published in March 2005, RFC 4034 works in conjunction with RFC 4033 and RFC 4035 to define how DNSSEC adds security to the existing DNS infrastructure, providing authenticity and integrity for DNS data. DNSSEC does not add confidentiality but ensures that DNS responses have not been altered in transit and come from the correct authoritative source.

RFC 4034 focuses specifically on the definition and use of several critical resource record types for DNSSEC. These include the DNSKEY (DNS Public Key), RRSIG (Resource Record Signature), NSEC (Next Secure), and DS (Delegation Signer) records. These records form the basis of the DNSSEC trust model, allowing resolvers to verify DNS responses and build a chain of trust from the root zone down to the queried domain. The DNSKEY record stores the public key for a zone, which is used to validate the digital signatures in the RRSIG records.

One of the major components of RFC 4034 is the introduction of the RRSIG record, which contains cryptographic signatures over other DNS records. For each RRset (a set of DNS records with the same name, type, and class), the RRSIG is generated using the zone’s private key and can be verified by the resolver using the corresponding public key in the DNSKEY record. This signature ensures that the data has not been altered and is authentic.

The DNSKEY record defined in RFC 4034 holds the public keys used to sign DNS data. A zone may have multiple DNSKEY records, each corresponding to a different key. Some keys are used for signing the zone’s data (ZSK or Zone Signing Key), while others are used for signing the DNSKEY records themselves (KSK or Key Signing Key). The separation of keys allows for more flexible key management and the ability to perform key rollovers without disrupting the entire zone’s signing process.

RFC 4034 also introduces the NSEC record, which provides proof of non-existence of a DNS name. When a resolver queries for a domain that does not exist, the authoritative server returns an NSEC record, which indicates the next domain in the zone, effectively showing that the queried name falls between two existing domain names. This method prevents attackers from injecting false negative responses. The NSEC record also helps prevent zone enumeration by revealing the next existing domain in the zone, although later RFCs like RFC 5155 introduced NSEC3 to mitigate this.

The DS (Delegation Signer) record, also described in RFC 4034, is used to establish the chain of trust between a parent zone and a child zone in DNSSEC. When a child zone is signed, a DS record is placed in the parent zone, pointing to the child zone’s DNSKEY record. This DS record contains a hash of the child zone’s DNSKEY and acts as a reference for validating the child zone’s signatures. This delegation of trust enables the recursive validation of DNS records from the root zone downward.

One of the primary goals of RFC 4034 is to enable secure, hierarchical validation of DNS data. This is accomplished by ensuring that every DNSSEC-protected zone has a public key available in its DNSKEY record, and that this key is validated by a DS record in its parent zone. This chain of trust starts at the root of the DNS and works down through each zone, ensuring that the data returned by the DNS server is trustworthy.

RFC 4034 also defines how DNSSEC-enabled resolvers handle the validation process. When a resolver queries a domain protected by DNSSEC, it retrieves the DNSKEY and RRSIG records for the zone and verifies the signatures using the public key. If the signatures are valid, the resolver knows that the data is authentic and has not been tampered with. If the validation fails, the resolver treats the data as potentially compromised and may return an error to the user.

The introduction of DNSSEC as defined by RFC 4034 significantly improves the security of the DNS, which was originally designed without strong protections against tampering or spoofing. Attacks such as DNS cache poisoning, where attackers inject false DNS responses into a resolver’s cache, can be effectively mitigated with DNSSEC. By providing a mechanism to verify the integrity and origin of DNS data, DNSSEC reduces the risk of these types of attacks.

One of the challenges addressed by RFC 4034 is the need for efficient key management. The separation of the ZSK and KSK allows for more frequent rollovers of the ZSK without requiring changes to the KSK or the DS record in the parent zone. This separation of responsibilities simplifies the key rollover process and reduces the risk of operational errors during key management.

RFC 4034 is a fundamental part of the DNSSEC specification, defining the resource records necessary for securing DNS data with cryptographic signatures. Through the use of DNSKEY, RRSIG, NSEC, and DS records, RFC 4034 establishes the mechanisms for creating a chain of trust from the root zone to individual DNS zones. This ensures that DNS responses are authentic and have not been altered in transit. The deployment of DNSSEC based on RFC 4034 has significantly enhanced the security of the global DNS infrastructure, providing robust protection against tampering and spoofing attacks.