Masataka Ohta <[email protected]> writes: Sorry for the delay in getting to this discussion, it's been a busy few weeks and I'm just catching up.
> The following paragraph: > > Some resource records (RRs) in a parent zone are typically expected > to be in-sync with the source data in the child's zone. The most > common records, to date, that should match are the nameserver (NS) > records and any necessary associated address "glue" records (A and > AAAA). These records are referred to as "delegation records". > > does not make much sense, because parent zone, today, is already > free to update glue by itself. That is, if multiple child zones > sharing an NS report different glues, the parent zone must check > the current most information. Sure, the parent zone is in control of what it publishes so it can. But there is no indication to a separated parent and child that the parent *should* be updating the records. I'm not sure why you're saying the paragraph doesn't make sense because the parent "is already free to update glue by itself". I didn't say it wasn't, but generally that most parent/child relationships today don't make the assumption that the data in the child should be copied to the parent (let alone, making sure it's signed and correct). The CSYNC record is simply a signaling mechanism saying "yep, these (signature-verified) records are for production use; please copy upward". > The problem is a little more serious. That is, in case when a > child zone do not provide glue and another provide false glue, > the parent zone MUST always check and provide the current most > glue information. The CSYNC record should only be copying glue from in-zone glue records. Updating glue that falls outside the child zone is not something that is under the perview of current parent/child relationships today and this document doesn't propose to change that. > Moreover, though the draft says: > > Clients deploying > CSYNC MUST ensure their zones are signed, current and properly linked > to the parent zone with a DS record that points to an appropriate > DNSKEY of the child's zone. > > it is more difficult than making referral NSes and glues up to date. Right, but it's a bootstrap requirement. The zone must be secure for CSYNC to operate properly in a protected fashion. The CDS record should be used to update the DS record. > I feel terminology of "agent" in the draft is annoying. "parent > zone" or "parent zone administrator" should be more consistent > with the terminology of rfc1034. That wording is actually borrowed from the CDS document (draft-ietf-dnsop-delegation-trust-maintainance), and I understand it's a new term it is important to note that the entity updating the zone records for the child may not be the parent zone itself. In the RRR model it is the registrar, and the parent zone administrator is the registry. So "parental agent" refers to "whomever is handling the data updates for the parent zone", which may or may not be the zone administrator. -- Wes Hardaker Parsons _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
