神明達哉 <jin...@wide.ad.jp> writes:
> 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.
Here's a summary of your comments and what I've done to address them.
My comments/actions are prefixed by "WJH:"
* DONE Section 1 (introduction), the first paragraph:
This document specifies how a child zone in the DNS ([RFC1034],
[RFC1035]) can publish a record to indicate to a parental agent that
it may copy and process certain records from the child zone. The
existence of and value change of the record may be monitored by a
parental agent and acted on as appropriate.
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. One easy way to
address this would be to add a forward reference to Section 1.1 at
the first occurrence of the term. If possible, it would be even
nicer if we can avoid using this term until the definition is given
in Section 1.1. For the same reason, it would be safer to avoid
using it in the abstract.
WJH: I've put in a forward reference in the introduction. I'm
not worried about the abstract as much, as any serious reader
will likely read on anyway. And the point of the term was to
make sure we don't say something confusing like "parent" when
there is more than one. There is no standard term, and the best
that the WG came up with (thanks to Olafur) is the new term.
But a forward reference in the introduction definitely makes
sense.
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.
* 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?
draft-ietf-dnsop-delegation-trust-maintainance has a way to avoid
that by removing CDS/CDNSKEY once all parent name servers are
updated.
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.
* 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. We might say such cases are out of scope of this
mechanism, but I personally think such an environment is not so
deviant that a standard-track protocol can casually ignore. At the
very least I would like to see some explicit consideration text on
the expected limitation (if any) regarding this point
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.
* 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.
Anyone else have an opinion here?
* 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:
NS records found within the child's zone should be copied
verbatim (with the exception of the TTL field, for which the
parent MAY want to select a different value) and the result
published within the parent zone should be an exact matching
set of NS records.
...
The A and AAAA type flags indicates that the A and AAAA
address glue records for in-bailiwick NS records within the
child zone should be copied verbatim (with the exception of
the TTL field, for which the parent MAY want to select a
different value) into the parent's delegation information.
* DUP Section 3.2: what if the followup NS query results in 'no data'? Of
course, this means the child zone is broken, but if the parent also
removes the NS RRsets, subsequent resolution for the zone will
immediately fail at the parent zone; on the other hand, if the
parent just ignores such result and keeps the NS RRset (and if it's
actually still usable), subsequent resolution will still somehow
work in many cases in practice. I don't know if that's the desired
scenario, and we might rather make it fail sooner rather than
leaving the half-broken state longer. In any case, I think it would
be nicer to mention this case (and what the parent should do) in
this document.
WJH: I think this was addressed based on concerns by the IESG
as well. Specifically: "Parental agents MUST NOT perform NS
updates if there are no NS records returned in a query, as
verified by DNSSEC denial of existence protection."
* 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. That is, this should essentially come from
the NS and AAAA/A records at the parent zone, and some of these may
be obsolete or even unusable at the time of query (in fact,
reflecting such changes is exactly the purpose of these queries).
This also means the child cannot simply update all NS (or AAAA or A)
records at once, making the old ones unworkable, and expect the
parent will catch up with it. This may be obvious in some sense,
but may still be worth noting.
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.
* 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:
parent: example.com.
child: child.example.com.
child.example.com. NS ns.grand.child.example.com.
grand.child.example.com. NS ns.grand.child.example.com.
ns.grand.child.example.com. AAAA 2001:db8::1
grand child: grand.child.example.com.
ns.grand.child.example.com. AAAA 2001:db8::1
If the AAAA record is changed, the child will update its CSYNC record
with setting the bit for AAAA. According to Section 3.1, the parental
agent will send a query for the AAAA record to the child's name
server, but it will return a delegation to the grandchild, not the
requested AAAA itself, let alone its RRSIG. The parental agent
could then resolve and verify the AAAA separately, but it breaks the
"atomicity" of the operation that this section seems to seek by
enclosing the whole set of queries with two SOA queries.
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:
+4.6. Parent/Child/Grandchild Glue Synchronization
+
+ When a child needs to publish a CSYNC record that synchronizes NS and
+ A/AAAA glue records and the NS record is actually pointing to a child
+ of the child (a grandchild of the parent), then it is critical that
+ the glue records in the child point to the proper real addresses
+ records published by the grandchild. It is assumed that if a child
+ is using a grandchild's nameserver that they must be in careful
+ synchronization. Specifically, this specification requires this to
+ be the case.
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.
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.
* DUP Section 6: unfortunately code 61 was already registered for OPENPGPKEY.
[ To be removed prior to publication: The CDS (59), CDNSKEY (60) and
the CSYNC records are all conceptually similar - if the code-point 61
happens to still be Unassigned when the IANA processes this, it would
be nice if that could be used for this.]
Yep, this is already been taken care of due to an IANA comment.
* DONE Editorial nits
- Section 2: s/these/three/
The CSYNC RRType contains, in its RDATA component, these parts: an
WJH: caught already
- Section 2: s/Section Section/Section/ (there are several instances
of this error)
data is processed is described in Section Section 3.
WJH: caught already
- Section 2: s/any anything/anything/ (?)
if any of the validation results indicate any anything other than
WJH: new catch, thank you!
--
Wes Hardaker
Parsons
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
