Paul, On Mon, 19 Oct 2015 19:51:36 -0400 (EDT) Paul Wouters <[email protected]> wrote:
> On Tue, 6 Oct 2015, Shane Kerr 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 : Chain Query requests in DNS > >> Author : Paul Wouters > >> Filename : draft-ietf-dnsop-edns-chain-query-03.txt > >> Pages : 15 > >> Date : 2015-10-03 > > I've updated the draft based on your review and that of Evan Hunt. Cool! Noticed a typo: s/partian/partial/ > > * There doesn't seem to be advice for a resolver when support for Chain > > Query is disabled when it was previously working. Probably something > > like "A resolver MUST handle the case where a Chain Query does not > > return the full chain. It MAY change resolvers in this case. It MAY > > periodically attempt to try getting a Chain Query at that server." > > I didn't address this yet. Isn't this more of a local implementation > kind of thing? I guess? I'm not opposed to helping implementors by dropping some MAY statements in the RFC. "Here's some stuff you're going to need to deal with." But I certainly won't push for this. > > * A comment: It is possible for DNSKEY and RRSIG to time out at > > different intervals (and DS, I suppose), right?. It seems that this > > will result in a bit of extra data now and then, the resolver needs to > > specify an entire "last known query name". I think this is okay, but > > it might be possible to avoid this by specifying which particular > > records are needed. Probably that is unneeded complication for this > > case. > > Evan suggested I define the Trust Point as the lowest FQDN for which you > have both DS and DNSKEY records, so that case should be covered now. > I don't think DNSKEY and RRSIGs can have a different TTL? But if they do, > then I guess the resolver will define that as "not having a validated > copy". Okay, seems clear enough. Over all it looks quite excellent! :) Cheers, -- Shane _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
