DNSSEC Papers, Articles
DNSSEC Presentations
DNSSEC Research
DNS Threats & Weaknesses
DNSSEC News, Mailinglists
DNSSEC Software & Practical
| DNSSEC Software & Tools
DNSSEC Projects, Testbeds
DNSSEC Deployment
DNSSEC Training, Workshops
IETF Protocol Reference (RFC)
| DNSSEC related RFCs (IETF)
DNSSEC related Drafts (IETF)
Home - About - Contact
Always handy:
DNSSEC Intro RFC (RFC 4033)
DNSSEC Records RFC (RFC 4034)
DNSSEC Protocol RFC (RFC 4035)
DNSSEC + EPP RFC (RFC 4310)
DNSSEC Operational Practices
DNSSEC Training Course 
DNSSEC Key Management Tools
DNSSEC Howto
BIND 9 Manual
RFC Archive
 |
Pro DNS and BIND
Ronald G.F. Aitchison
Pro DNS and BIND is the first book describing the new DNSSEC-bis standard (2005) in great detail.
Chapter 11 (DNSSEC) is a dedicated chapter on DNSSEC that deals exclusively with the latest DNSSEC.bis security standards and covers both the theory and implementation. Zone signing, chains of trust, Zone Signing Keys and Key Signing Keys, DNSSEC Lookaside Validation (DLV), and key-rollover procedures are all covered with practical examples.
Readers will learn not only about key DNS concepts, but also how to effectively install, configure, deploy and manage BIND in enterprise environments. The book is based on BIND 9.3.0, the first stable release that includes support for the latest DNSSEC (DNSSEC.bis) standards and a major functional upgrade from previous BIND 9 releases.
Chapter index: 1. An Introduction to DNS, 2. Zone Files and Resource Records, 3. DNS Operations, 4. DNS Types, 5. DNS and IPv6, 6. Installing BIND, 7. BIND Type Samples, 8. Common DNS Tasks, 9. DNS Diagnostics and Tools, 10. DNS Secure Configurations, 11. DNSSEC, 12. BIND Configuration Reference, 13. Zone File Reference, 14. BIND APIs and Resolver Libraries, 15. DNS Messages and Records, A. Appendix.
|
|
| DNSSEC RFC - DNS Security Extensions RFC's (IETF)
|
 DNSSEC Drafts
All DNS RFCs
The new DNSSEC-bis RFCs are 4033, 4034, and 4035 (old DNSSEC RFC 2535 is now obsolete).
RFC 4471
Sep 2006 | Derivation of DNS Name Predecessor and Successor
This document describes two methods for deriving the canonically-ordered predecessor and successor of a DNS name. These methods may be used for dynamic NSEC resource record synthesis, enabling security-aware name servers to provide authenticated denial of existence without disclosing other owner names in a DNSSEC secured zone. |
RFC 4641
Sep 2006 | DNSSEC Operational Practices
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
Aug 2006 | HMAC SHA TSIG Algorithm Identifiers
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 4470
Apr 2006 | Minimally Covering NSEC Records and DNSSEC On-line Signing
This document describes how to construct DNSSEC NSEC resource records that cover a smaller range of names than called for by RFC 4034. By generating and signing these records on demand, authoritative name servers can effectively stop the disclosure of zone contents otherwise made possible by walking the chain of NSEC records in a signed zone. |
RFC 4398
Mar 2006 | Storing Certificates in the Domain Name System (DNS)
Cryptographic public keys are frequently published, and their authenticity is demonstrated by certificates. A CERT resource record (RR) is defined so that such certificates and related certificate revocation lists can be stored in the Domain Name System (DNS). This document obsoletes RFC 2538. |
RFC 4035
Mar 2005 | Protocol Modifications for the DNS Security Extensions
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
Mar 2005 | Resource Records for the DNS Security Extensions
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
Mar 2005 | DNS Security Introduction and Requirements
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 4025
Feb 2005 | A Method for Storing IPsec Keying Material in DNS
This document describes a new resource record for the Domain Name System (DNS). This record may be used to store public keys for use in IP security (IPsec) systems. The record also includes provisions for indicating what system should be contacted when an IPsec tunnel is established with the entity in question. This record replaces the functionality of the sub-type #4 of the KEY Resource Record, which has been obsoleted by RFC 3445. |
RFC 3833
Aug 2004 | Threat Analysis of the Domain Name System (DNS)
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 3597
Sep 2003 | Handling of Unknown DNS Resource Record (RR) Types
Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently. |
RFC 3226
Dec 2001 | DNSSEC and IPv6 A6 aware server/resolver message size requirements
This document mandates support for EDNS0 (Extension Mechanisms for DNS) in DNS entities claiming to support either DNS Security Extensions or A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fall back to TCP will happen, having a detrimental impact on query latency and DNS server load. This document updates RFC-2535 and RFC RFC-2874, by adding new requirements. |
RFC 3225
Dec 2001 | Indicating Resolver Support of DNSSEC
In order to deploy DNSSEC (Domain Name System Security Extensions) operationally, DNSSEC aware servers should only perform automatic inclusion of DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. |
RFC 3110
May 2001 | RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
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 3007
Nov 2000 | Secure Domain Name System (DNS) Dynamic Update
This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization. |
RFC 2931
Sep 2000 | DNS Request and Transaction Signatures ( SIG(0)s )
Extensions to the Domain Name System (DNS) are described in [RFC-2535] that can provide data origin and transaction integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Implementation experience has indicated the need for minor but non- interoperable changes in Request and Transaction signature resource records ( SIG(0)s ). These changes are documented herein. |
RFC 2930
Sep 2000 | Secret Key Establishment for DNS (TKEY RR)
[RFC-2845] provides a means of authenticating Domain Name System (DNS) queries and responses using shared secret keys via the Transaction Signature (TSIG) resource record (RR). However, it provides no mechanism for setting up such keys other than manual exchange. This document describes a Transaction Key (TKEY) RR that can be used in a number of different modes to establish shared secret keys between a DNS resolver and server. |
RFC 2929
Sep 2000 | Domain Name System (DNS) IANA Considerations
Internet Assigned Number Authority (IANA) parameter assignment considerations are given for the allocation of Domain Name System (DNS) classes, Resource Record (RR) types, operation codes, error codes, etc. |
RFC 2870
Jun 2000 | Root Name Server Operational Requirements
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
May 2000 | Secret Key Transaction Authentication for DNS (TSIG)
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 2540
Mar 1999 | Detached Domain Name System (DNS) Information
A standard format is defined for representing detached DNS information. This is anticipated to be of use for storing information retrieved from the Domain Name System (DNS), including security information, in archival contexts or contexts not connected to the Internet. |
RFC 2181
Jul 1997 | Clarifications to the DNS Specification
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. |
|
Buy from Amazon