Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-01.txt

From: [email-masked]
Date: Wed, 09 Mar 2016 16:58:27 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : The EDNS Key Tag Option
        Authors         : Duane Wessels
                          Warren Kumari
	Filename        : draft-ietf-dnsop-edns-key-tag-01.txt
	Pages           : 10
	Date            : 2016-03-09

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 a way for
   validating end-system resolvers to signal to a server which keys are
   referenced in their chain-of-trust.  The extensions allow zone
   administrators to monitor the progress of rollovers in a DNSSEC-
   signed zone.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-key-tag-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-key-tag-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 10 Mar 2016 21:42:44 +0000

> On Mar 9, 2016, at 4:58 PM, [email-masked] wrote:
> 
> 

For this draft the only significant change since -00 is
in the way that a recursive server combines a client's key tags with
its own.  Previously it was suggested to take a union of the values.
Now it is to repeat the option code:

  In addition, the clients of a validating recursive resolver might be	
  configured to do their own validation, with their own trust	
  anchor(s). When a validating recursive resolver receives a query	
  that includes the edns-key-tag option with a Key Tag list that	
  differs from its own, it SHOULD forward both the client's Key Tag	
  list as well as its own. When doing so, the recursive resolver	
  SHOULD transmit the two Key Tag lists using separate instances of the	
  edns-key-tag option code in the OPT meta-RR. For example, if the	
  recursive resolver's Key Tag list is (19036, 12345) and the stub/	
  client's list is (19036, 34567), the recursive would include the	
  edns-key-tag option twice: Once with values (19036, 12345) and once	
  with values (19036, 34567).

DW