DNS Security Introduction and Requirements
RFC 4033

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    dnsext mailing list <namedroppers@ops.ietf.org>, 
    dnsext chair <dnsext-chairs@tools.ietf.org>
Subject: Protocol Action: 'DNS Security Introduction and 
         Requirements' to Proposed Standard 

The IESG has approved the following documents:

- 'DNS Security Introduction and Requirements '
   <draft-ietf-dnsext-dnssec-intro-14.txt> as a Proposed Standard
- 'Protocol Modifications for the DNS Security Extensions '
   <draft-ietf-dnsext-dnssec-protocol-10.txt> as a Proposed Standard
- 'Resource Records for the DNS Security Extensions '
   <draft-ietf-dnsext-dnssec-records-12.txt> as a Proposed Standard

These documents are products of the DNS Extensions Working Group. 

The IESG contact persons are Thomas Narten and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-intro-14.txt

Technical Summary

   This document is part of a family of documents that describes 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.  
   
   The document series consists out of 3 documents:
    +  DNS Security Introduction and Requirements ([dnssec-intro])
    +  Protocol Modifications for the DNS Security Extensions ([dnssec-proto])
    +  Resource Records for the DNS Security Extensions ([dnssec-records])

   [dnssec-intro] introduces the DNS security extensions, and describes their
   capabilities and limitations. [dnssec-intro] also discusses the services
   that the DNS security extensions do and do not provide.  [dnssec-intro]
   describes the interrelationships between the group of documents
   that collectively describe DNSSEC.

   [dnssec-proto] describes the DNSSEC protocol modifications.
   [dnssec-proto] defines the concept of a signed zone, along with the
   requirements for serving and resolving using DNSSEC.  These
   techniques allow a security-aware resolver to authenticate both DNS
   resource records and authoritative DNS error indications.

   [dnssec-records] 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.

Working Group Summary

   There was consensus within the working group to publish the
   document as Proposed Standard.

Protocol Quality

   The following quote from  draft-ietf-dnsext-dnssec-intro-11.txt
   is relevant:

   "The specification in the DNSSEC document set defines the behavior
   for zone signers and security-aware name servers and resolvers in
   such a way that the validating entities can unambiguously determine
   the state of the data.
   
   (...) 

   A method for signaling advanced error codes and policy between a
   security aware stub resolver and security aware recursive nameservers
   is a topic for future work, as is the interface between a security
   aware resolver and the applications that use it.  Note, however, that
   the lack of the specification of such communication does not prohibit
   deployment of signed zones or the deployment of security aware
   recursive name servers that prohibit propagation of bogus data to the
   applications."

   (end quote)
   
   Various parts of the specification have been implemented.

   There are (at least) 2 signer implementations
   There are (at least) 2 authoritative server implementations
   There is (at least) 1 verifying recursive nameserver (hence a verifying
   resolver) implementation.
   There are various troubleshooting tools that have partial or full
   verification capabilities.

   These implementations have been used in several workshops and have
   been found to inter-operate.

   This document has been reviewed for the IESG by Thomas Narten.