[DNSOP] Last Call: <draft-ietf-dnsop-edns-key-tag-03.txt> (Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)) to Proposed Standard

The IESG <iesg-secretary@ietf.org> Mon, 02 January 2017 17:48 UTC

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Auto-Submitted: auto-generated
Precedence: bulk
Sender: iesg-secretary@ietf.org
Message-ID: <148337930553.21885.17516942356657336528.idtracker@ietfa.amsl.com>
Date: Mon, 02 Jan 2017 09:48:25 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8rz7tTQFGgiI1MLYg9Grdqg9jac>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, draft-ietf-dnsop-edns-key-tag@ietf.org, joelja@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org
Subject: [DNSOP] Last Call: <draft-ietf-dnsop-edns-key-tag-03.txt> (Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)) to Proposed Standard
Reply-To: ietf@ietf.org

The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)'
  <draft-ietf-dnsop-edns-key-tag-03.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-01-16. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain-of-trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies two different
   ways for validating resolvers to signal to a server which keys are
   referenced in their chain-of-trust.  The data from such signaling
   allow zone administrators to monitor the progress of rollovers in a
   DNSSEC-signed zone.

   This document describes two independent methods for validating
   resolvers to publish their referenced keys: an EDNS option and a
   different DNS query.  The reason there are two methods instead of one
   is some people see significant problems with each method.  Having two
   methods is clearly worse than having just one, but it is probably
   better for the Internet than having no way to gain the information
   from the resolvers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/ballot/


No IPR declarations have been submitted directly on this I-D.

[DNSOP] Last Call: <draft-ietf-dnsop-edns-key-tag… The IESG