|
|
| DNSSEC Protocol RFC (IETF)
|
 Related Reading
 Show all DNS RFCs
Note: Core DNSSEC RFCs are RFC 4033, RFC 4034, and RFC 4035 (old DNSSEC RFC 2535 is now obsolete).
| RFC 4986 |  Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover | | |  Show complete RFC 4986 (Aug 2007) Show all RFCs that refer to RFC 4986
Every DNS security-aware resolver must have at least one Trust Anchor to use as the basis for validating responses from DNS signed zones. For various reasons, most DNS security-aware resolvers are expected to have several Trust Anchors. For some operations, manual monitoring and updating of Trust Anchors may be feasible, but many operations will require automated methods for updating Trust Anchors in their security-aware resolvers. This document identifies the requirements that must be met by an automated DNS Trust Anchor rollover solution for security-aware DNS resolvers. |
| RFC 4641 | DNSSEC Operational Practices | | | Show complete RFC 4641 (Sep 2006) Show all RFCs that refer to RFC 4641
This document describes a set of practices for operating the DNS with security extensions (DNSSEC). The target audience is zone administrators deploying DNSSEC. The document discusses operational aspects of using keys and signatures in the DNS. It discusses issues of key generation, key storage, signature generation, key rollover, and related policies. This document obsoletes RFC 2541, as it covers more operational ground and gives more up-to-date requirements with respect to key sizes and the new DNSSEC specification. |
| RFC 4635 | HMAC SHA TSIG Algorithm Identifiers | | | Show complete RFC 4635 (Aug 2006) Show all RFCs that refer to RFC 4635
Use of the Domain Name System TSIG resource record requires specification of a cryptographic message authentication code. Currently, identifiers have been specified only for HMAC MD5 (Hashed Message Authentication Code, Message Digest 5) and GSS (Generic Security Service) TSIG algorithms. This document standardizes identifiers and implementation requirements for additional HMAC SHA (Secure Hash Algorithm) TSIG algorithms and standardizes how to specify and handle the truncation of HMAC values in TSIG. |
| RFC 4035 | Protocol Modifications for the DNS Security Extensions | | | Show complete RFC 4035 (Mar 2005) Show all RFCs that refer to RFC 4035
This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of new resource records and protocol modifications that add data origin authentication and data integrity to the DNS. This document describes the DNSSEC protocol modifications. This document defines the concept of a signed zone, along with the requirements for serving and resolving by using DNSSEC. These techniques allow a security-aware resolver to authenticate both DNS resource records and authoritative DNS error indications. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. |
| RFC 4034 | Resource Records for the DNS Security Extensions | | | Show complete RFC 4034 (Mar 2005) Show all RFCs that refer to RFC 4034
This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. |
| RFC 4033 | DNS Security Introduction and Requirements | | | Show complete RFC 4033 (Mar 2005) Show all RFCs that refer to RFC 4033
The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. |
| RFC 3833 | Threat Analysis of the Domain Name System (DNS) | | | Show complete RFC 3833 (Aug 2004) Show all RFCs that refer to RFC 3833
Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. |
| RFC 3110 | RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) | | | Show complete RFC 3110 (May 2001) Show all RFCs that refer to RFC 3110
This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC-2537, describes how to produce RSA KEY RRs in Section 2. Since the adoption of a Proposed Standard for RSA signatures in the DNS (Domain Name Space), advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG RRs. The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security. |
| RFC 2870 | Root Name Server Operational Requirements | | | Show complete RFC 2870 (Jun 2000) Show all RFCs that refer to RFC 2870
As the internet becomes increasingly critical to the world's social and economic infrastructure, attention has rightly focused on the correct, safe, reliable, and secure operation of the internet infrastructure itself. The root domain name servers are seen as a crucial part of that technical infrastructure. The primary focus of this document is to provide guidelines for operation of the root name servers. Other major zone server operators (gTLDs, ccTLDs, major zones) may also find it useful. These guidelines are intended to meet the perceived societal needs without overly prescribing technical details. |
| RFC 2845 | Secret Key Transaction Authentication for DNS (TSIG) | | | Show complete RFC 2845 (May 2000) Show all RFCs that refer to RFC 2845
This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved recursive name server. No provision has been made here for distributing the shared secrets; it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism such as sneaker-net until a secure automated mechanism for key distribution is available. |
| RFC 2181 | Clarifications to the DNS Specification | | | Show complete RFC 2181 (Jul 1997) Show all RFCs that refer to RFC 2181
This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. Eight separate issues are considered: IP packet header address usage from multi-homed servers, TTLs in sets of records with the same name, class, and type, correct handling of zone cuts, three minor issues concerning SOA records and their use, the precise definition of the Time to Live (TTL), Use of the TC (truncated) header bit, the issue of what is an authoritative, or canonical, name, and the issue of what makes a valid DNS label. The first six of these are areas where the correct behaviour has been somewhat unclear, we seek to rectify that. The other two are already adequately specified, however the specifications seem to be sometimes ignored. We seek to reinforce the existing specifications. |
|
