On Fri, Jul 8, 2016 at 6:36 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> Greetings again; I'm the new co-author on this draft. Based on the WG > discussion where a bunch of us wanted to use EDNS0 and a bunch of us wanted > to use queries, the authors tentatively decided that the best way to go > forwards is to put both methods in the draft. After all, a motivated > observer of the signals will not have much problem watching both types of > signals, and end systems can decide which of the two they want to use. > > We understand that "specify more than one" is often an unpopular choice in > the IETF, about as unpopular as "don't get consensus on one". This is a WG > document so we need consensus even to go with two ways. We look forward to > hearing from you about this choice and how we can move forwards. > > --Paul Hoffman > > > > On 8 Jul 2016, at 15:30, 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 of the >> IETF. >> >> Title : Signaling Trust Anchor Knowledge in DNS >> Security Extensions (DNSSEC) >> Authors : Duane Wessels >> Warren Kumari >> Paul Hoffman >> Filename : draft-ietf-dnsop-edns-key-tag-02.txt >> Pages : 13 >> Date : 2016-07-08 >> >> 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 >> differnt 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 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-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-key-tag-02 >> >> Abstract, second paragraph "differnt" -> "different" 5.1. Query Format What if the key tag is less than 0x1000 hex or 4096 decimal - Should the resulting hex have leading zeros (always 4 characters?) or not? For example, would 4095 decimal be _ta-0fff or _ta-fff ? (I prefer always 4 characters hex, but it is your doc.) 5.3.1. Interaction With Aggressive Negative Caching I would prefer that the tags always be sorted. No big deal for two tags, but if there was a compromise or mistake during a rollover, there might be three keys and the savings in records might be significant. If you decide to specify sorting, I think it would go in section 5.1 and not in 5.3.1. -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
