At Mon, 01 Dec 2014 13:31:23 -0800, Wes Hardaker <wjh...@hardakers.net> wrote:
> > From a quick check some of them still seem to be open. And, as far as > > I remember there has been no response to my comments, so I'm not sure > > if they were considered/discussed but dismissed or simply overlooked. > > First, apologies again for missing these comments during last call. > Multiple people missed it for some reason. No problem, I know it happens. Thanks for the prompt response to my second call:-) > * DONE Section 1 (introduction), the first paragraph: [...] > I vaguely remember someone already pointed this out, but anyway: I'm > afraid the term "parental agent" is not so widely shared that we can > safely use it without first giving the definition. [...] > > WJH: I've put in a forward reference in the introduction. [...] > > This document specifies how a child zone in the DNS ([RFC1034], > - [RFC1035]) can publish a record to indicate to a parental agent that > - it can copy and process certain records from the child zone. The > - existence of the record and any change in its value can be monitored > - by a parental agent and acted on depending on local policy. > + [RFC1035]) can publish a record to indicate to a parental agent (see > + section Section 2 for a definition of "parental agent") that it can > + copy and process certain records from the child zone. The existence > + of the record and any change in its value can be monitored by a > + parental agent and acted on depending on local policy. I'm okay with this. We might also refer to RFC7344 explicitly from where this document defines the term, but I'd leave it to you. > * DONE Section 3 (in general) > Do we need some way to avoid making the parental agent keep fetching > RRsets specified in CSYNC only to confirm they are still the latest? [...] > WJH: good point; I've added this to the operational > considerations section: > > 4.5. Removal of the CSYNC records > > Children MAY remove the CSYNC record upon noticing that the parent > zone has published the required records, thus eliminating the need > for the parent to continually query for the CSYNC record and all > corresponding records. By removing the CSYNC record from the child > zone, the parental agent will only need to perform the query for the > CSYNC record and can stop processing when it finds it missing. This > will reduce resource usage by both the child and the parental agent. Works for me. > * DONE In Section 3.1, it suggests a sequence of CSYNC and other followup > queries enclosed by SOA queries, and requires serials of the SOAs be > identical (with a MUST). I wonder if this is reliable enough for a > rapidly changing zone, such as those accepting dynamic updates at a > very high rate. [...] > > WJH: That's a valid concern. I don't think we need to address > the exact way this should be handled, as that can be > implementation dependent. So I've changed it to a SHOULD and > added the following bit of text as well: > > If the SOA records from the first and last steps have different > serial numbers (for example, because the zone was edited and > republished during the interval between steps 1 and 4), then the > - CSYNC record obtained in the second set MUST NOT be processed. The > - operation MAY be restarted or retried in the future. > + CSYNC record obtained in the second set SHOULD NOT be processed > + (rapidly changing child zones may need special consideration or > + processing). The operation MAY be restarted or retried in the > + future. Okay with me. > * NOFIX Section 3.1 > > [...] If > state is being kept by the parental agent and the SOA serial number > is less than the last time a CSYNC record was processed, this CSYNC > record SHOULD NOT be processed. Similarly, if state is being kept by > the parental agent and the SOA Serial Field of the CSYNC record is > less than the SOA Serial Field of the CSYNC record from last time, > then this CSYNC record SHOULD NOT be processed. > > I'm not sure about the point of these "SHOULD NOT"s. If it's okay > with ignoring mismatches with stored state, why would the parental > agent bother to keep the state in the first place? Since keeping > the state itself is optional, it seems to make more sense to use > "MUST NOT" here. > > WJH: I'm sort of on the fence with this one. But in the end, > since keeping state itself isn't a requirement (and arguably > shouldn't be), then force a MUST there doesn't make a whole lot > of sense since one solution for ensuring compliance is not to > keep state! It seems to me, just like some of the other issues > above, that operational considerations may insert some > restrictions we haven't thought of yet. I wouldn't be opposed to that. > * DONE Section 3.2 > > NS records found within the child's zone should be copied verbatim > and the result published within the parent zone should be an exact > matching set of NS records. > > Does "verbatim" indicate that the TTL should also be copied? The > same question applies to Section 3.2.2, although "verbatim" isn't > used in that section. > > WJH: good point; no it should just be the RDATA section. > > Here's the new sentences in question: [...] Works for me. > * NOFIX Section 4.2 > We may want to be clearer about how the child name servers and their > addresses are determined to send CSYNC queries if they are not > manually configured. [...] > > WJH: The level of dedication of the parental agent certainly > comes into play. If the parental agent is choosing a random NS > to query, and that NS is out of date then a problem certainly > will occur (specifically: a timing issue will arise until the > parental agent eventually queries an up to date one). However, > note that the draft is not implementing a push mechanism anyway > so timeliness is probably not going to be fast in the first > place. > > Section 4.2 already covers this the best we can, I think. Works for me. > * DONE Section 4.3 > > Children deploying NS records pointing to domain-names within their > own children (the "grandchildren") SHOULD ensure the grandchildren's > associated glue records are properly set before publishing the CSYNC > record. I.e., it is imperative that proper communication and > synchronization exist between the child and the grandchild. > > I'm afraid this setup requires more discussion. In the following > configuration: [...] > WJH: There are really two separate problems here: > > 1) the operational issues of a child using a nameserver in the > control of a grandchild. To address this, I've added a new > section in the operational considerations section: [...] I'm fine with that text. > 2) And the harder problem of how to handle the SOA transaction > synchronization across multiple domains. > > I think to address this, we need to add a similar SOA > transaction query for the grandchild inside the greater one > of the child. > > The only other option is to not support this case at all > (all records must be in the child solely). So, how about > the following replacement text: > > 1. Query for the child zone's SOA record > > 2. Query for the child zone's CSYNC record > > 3. Query for the child zone's data records, as required by the CSYNC > record's Type Bit Map field > > * Note: if any of the resulting records being queried are not > authoritative within the child zone but rather in a grandchild > or deeper, SOA record queries must be made for the > grandchildren as well. The parental agent will first need to identify the name of the grandchild zone and its server addresses to send this second SOA query by sending some additional queries, since these addresses (records) may not be in the parent zone as glue. This might be obvious from the context, but I think it's worth noting explicitly. We might also say the parental agent may (MAY?) just give up the synchronization attempt if it detects the need for the search in grandchildren due to the operational complexity. But that's not a strong opinion; I'd leave it to you. > 4. Query for the collected SOA records again, starting with the > deepest and ending with the SOA of the child's. > > If the SOA records from the first, middle and last steps for a given > zone have different serial numbers (for example, because the zone was > edited and republished during the interval between steps 1 and 4), > then the CSYNC record obtained in the second set SHOULD NOT be > processed (rapidly changing child zones may need special > consideration or processing). The operation MAY be restarted or > retried in the future. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
