> On Mar 9, 2016, at 4:58 PM, [email protected] wrote:
> 
> 
> 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


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


_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to