This document seems clear and reasonable. The author has done a good job of clearing up issues from earlier drafts.
FWIW, I disagree strongly with Ed Lewis' skepticism. See below. On Apr 4, 2014, at 9:12 AM, Edward Lewis <[email protected]> wrote: > Not that this matters, but this is the first look I have had at this document. > > I’ll start with a heavy dose of skepticism as this is intended for the > standards track. > > This is “impossible to implement”: > > 2.3.2. Child Nameserver Selection > > Parental agents will need to poll child nameservers in search of > CSYNC records and related data records. > > One word - any cast. (Okay, the spell checker says it is two words.) A > casual observer can estimate the rest of the elided comment. That does not make the document "impossible to implement", it makes it unreliable when the child's nameserver is anycast. That's why the document says not to do that in Section 2.2.1 > But, truth be told, “polling” as described here is not necessary for this > proposal. > > I do have a more serious concern about where the parental agent gets it’s > information. I accept that a properly DNSSEC-signed CSYNC record is > sufficient to indicate a child has a configuration that it wants to see > replicated in the parent. Tying this to serial numbers makes the CSYNC > independent of the copy-on-the-server, meaning, this depends on the data > space and not the server space. > > Getting the NS set has one challenge, making sure the NS set comes from the > same serial number version as the CSYNC. When I issue “zone/IN/NS” I don’t > see the serial number though. I’d have to use the ANY query type to capture > the SOA and NS set resident in the answering server (and hopefully we’ll > assume an authoritative server). Given: > Parental agents MAY offer a configuration interface to allow child > operators to specify which nameserver should be considered the master > to send data queries too. This master may not be one of the > publically listed nameservers in the NS set (i.e., it may be a > "hidden master"). > > this issue is not a show stopper, but the “protocol implication” of not > getting the SOA and NS in the same response is probably a significant note to > add. Again: isn't your concern covered by the four steps in Section 2.2.1? --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
