On Wed, Dec 9, 2015 at 3:27 PM, <internet-dra...@ietf.org> 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 Working > Group of the IETF. > > Title : The EDNS Key Tag Option > Author : Duane Wessels > Filename : draft-ietf-dnsop-edns-key-tag-00.txt > Pages : 9 > Date : 2015-12-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-00 > > > 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/
5.2.1 <https://tools.ietf.org/html/draft-ietf-dnsop-edns-key-tag-00#section-5.2.1>. Validating Recursive Resolvers This sentence concerns me: "When the recursive server receives a query with the option set, the recursive server SHOULD set the edns-key-tag list for any outgoing iterative queries for that resolution chain to a union of the stub client's Key Tag(s) and the validating recursive resolver's Key Tag(s)." That approach hides the fact that the stub client's Key Tag(s) might be missing the latest tags, which is precisely the information that we are trying to gather. The intersection (only tags in all lists) would be a better indicator of what tags everyone can use to validate. Better yet would be to forward multiple lists of keytags (either encoded in one option, or repeated options) so that the receiver gets a better picture of all the resolvers and their state. I would suggest that the recursive server's tag list be the last list, since that information might be useful to the receiver.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
