After *way* too long of a delay (entirely my fault), here are some
responses to the IESG about the comments and discusses on the document.
It's close to finalized I hope, and I did publish a -04 to reflect the
changes made below. Below is a list of the IESG member's and their
comments, as well as responses to them from me (starting with a marking
of "WJH:").
Notes from IESG review (of -03):
* DONE Alia Atlas
*** DONE First sentence in Sec 1 is missing an it:
:LOGBOOK:
- State "DONE" from "TODO" [2014-11-25 Tue 16:05]
:END:
"This document specifies how a child zone in the DNS ([RFC1034],
[RFC1035]) can publish a record to indicate to a parental agent that
can copy and process certain records from the child zone."
WJH: Added
*** DUP In Sec 2: What does unpunishable data mean in
:LOGBOOK:
- State "DONE" from "TODO" [2014-11-25 Tue 16:06]
:END:
"Errors due to unsupported Type Bit Map bits, or otherwise
nonpunishable data, SHALL result in no change to the parent zone's
delegation information for the Child."
WJH: It was a typo and already changed to "publishable"
*** DONE In Sec 3.1:
It says " If the SOA serial numbers are equal but less than the
CSYNC record's SOA Serial Field [RFC1982], the record MUST NOT be
processed." which seems to contradict what is stated in Sec
2.1.1.1 "If the soaminimum flag is not set, parental agents MUST
ignore the value in the SOA Serial Field. Clients can set the
field to any value if the soaminimum flag is unset, such as the
number zero."
Perhaps I'm missing a relevant DNS clue?
WJH: good catch! Changed to "If the soaminimum flag is set and the
SOA serial numbers are equal but less than the CSYNC record's SOA
Serial Field..."
* DONE Barry Leiba
*** DONE In the definition of the CSYNC Flags registry in the IANA
Considerations, you have two conflicting statements:
ONE:
Assignment of new flag values are subject to
"RFC Required" specifications [RFC5226].
TWO:
For new assignments to be made to this registry, a new RFC must be
published via a Standards Action.
Which is it: RFC Required, or Standards Action? They are
different (the former allows for Experimental or Informational
RFCs, and RFCs in the Independent or IRTF streams; the latter
requires a Standards Track RFC in the IETF stream). There's
also "IETF Review", which requires an IETF stream RFC, but
allows Informational or Experimental).
WJH: Changed to be standards-track
* DONE Pete Resnick
*** DONE Sections 4.2, 4.3, and 4.4:
The MAYs in there MAY be inappropriate. The ones about providing
interfaces sure don't seem like protocol options. On the others
it's hard to tell. Please review. The SHOULDs in 4.1 and 4.4 seems
also suspiciously wrong.
Pete: last time I responded with the following comment. Maybe it
wasn't read, as the same comment is being repeated without a
response to the following comment:
+ WJH: I changed a few of the MAYs, but most seemed appropriate.
The SHOULD on the documentation is somewhat important, as
without documentation from the parental agent stating they
support the CSYNC type, and how they're making use of it,
clients have no way to know whether the protocol can be
used. There is no discovery that you get something good
from your parent if you publish a CSYNC record. The parent
must document they're support for children to know they can
make use of it.
Since you added additional text addressing the API related concern,
I changed one MAY to a "may" in the following sentence:
- <t>Parental agents MAY offer a configuration interface to allow
+ <t>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.
The 4.3 section didn't have similar MAYs, so I didn't do
anything about them.
In 4.4, I made the following change:
- <t>The frequency with which they poll clients (which MAY
+ <t>The frequency with which they poll clients (which may
also be configurable by the client)</t>
For the SHOULD in 4.1, I downcased it as well:
- Parental agents SHOULD, at a
+ Parental agents should, at a
minimum, at least log errors encountered when processing CSYNC
records.
For the SHOULD in 4.4, I didn't change it. Because, as mentioned
previously, publicly documenting the parameters is fairly
important.
Maybe these address your concerns? Your previous comment was
rather vague in exactly what your issues were, so I'm guessing at
what you wanted done.
* DONE Richard Barnes
*** DONE Adding on to Ted's DISCUSS:
The Security Considerations need to make clear that this
mechanism MUST NOT be used to synchronize DS records between
child and parent (whether this is allowed through the base
protocol or some extension). This is because the DS records are
the only thing the parent has that allows it to validate all the
DNSSEC signatures that it is required to verify -- if an
attacker can change the DS record, then it can change any other
record it wants to.
WJH: Ok, I added the following two middle sentences, marked with
[new]. Do they seem sufficient?
... DNSSEC-secured operating environment in place.
Additionally, this specification was not designed to synchronize
DNSSEC security records, such as DS pointers. [new] Thus,
implementations of this protocol MUST NOT use it to synchronize
DS records or DNSKEY materials. [new] Similarly, future
documents extending this protocol MUST NOT offer the ability to
syncronize DS or DNSKEY materials. For such a solution, please
see the ...
[the document makes it pretty clear in a number of places this
must not be done, including the fact you aren't supposed to even
use bits that aren't documented and the DS bit wasn't defined,
but that being said: it's a good point that it should be well
stated in the security considerations; thanks]
* DONE Stephen Farrell
*** DONE
- general: Couldn't a child ask for its CSYNC record to be
published in the parent? (and so on up...) I think you should
say a parent MUST NOT take a child's CSYNC in the same way
that you say to not use CSYNC for DS RRs.
WJH: added a note mentioning that CSYNC, CDS, CDNSKEY records
MUST NOT be synchronized.
[note, however, that a parent publishing a CSYNC record at the
parent *for the child* would certainly be interesting and really
only affect broken resolvers that were willing to accept
non-authoratative answers; none the less, I don't mind
mentioning it]
*** DONE
- 2.1.1.2.1: Is the meaning of "blindly" sufficiently clear
that all implementers and deployers will get this right?
I'm willing to believe you if you say it is.
WJH: made the following change, which seems sufficient?:
- Specifically: a parental agent must not copy data blindly
+ Specifically: a parental agent must not just copy the data
* DONE Ted Lemon
*** DONE Point 1--
2.1.1.1 doesn't talk about SOA serial number overflow. It's not clear to me
that the security goal intended by this section is correctly addressed if
the
implementation assumes that the comparison operators defined in section 3.2
of
RFC 1982 are used, rather than doing a simple unsigned compare.
I don't think there's a clearly correct answer here, but the issue should be
documented and, ideally, a choice should be made. To clear this DISCUSS,
the
document needs to say which of the two sets of comparison operators apply,
and
needs to explain how serial number wrap events are accounted for (or that
they
are not accounted for, and this is an open issue with security
implications).
The easiest way to fix this would be to require a comparison for equality,
but
I realize that this would place an additional burden on implementations
which
may be impractical.
WJH: Of all the comments received this one confuses me the most.
Mostly because I think 1982 is quite clear about how to do the
comparison operator and there is only one, the "less than"
operation and it is discussed in 3.2 of 1982. So, I'm not
entirely clear what you're looking for. I can add some text to
explicitly mention wrapping, but that is exactly what 1982 is
about: how to do comparisons with wrapping. So, trying to add
something that at least more explicitly mentions what I think
you're looking for, I added this to the bottom 2.1.1.1:
<t>Although Section 3.2 of <xref target="RFC1982" />
describes how to properly implement a less-than comparison
operation with SOA serial numbers that may wrap beyond the
32-bit value in both the SOA record and the CSYNC record, it
is important than a child using the soaminimum flag must not
increment it's SOA serial number value more than 2^16
(including any 32-bit wrapping) within the period of time
that a parent might wait between polling the child for the
CSYNC record.</t>
It's actually not a security feature so much as a operational
feature to prevent a parent from toggling back and forth between
two values if one nameserver does not have the most recent data
set. But, the DNSSEC signature lifetimes could be long enough
to allow for replays if the serial numbers increased by more
than 2^16 within it. So... I added this:
<t>To ensure that an older CSYNC record making use of the
soaminimum flag can not be replayed to revert values, the SOA
serial number MUST NOT be incremented by more than 2^16
during the lifetime of the signature window of the associated
RRSIGs signing the SOA and CSYNC records. Note that this is
independent of whether or not the increment causes the 2^32 bit
serial number field to wrap.</t>
Is this (these) sufficient to address your concerns?
*** DONE Point 2--
In 3.2.1, you don't say what to do if the name server returns an NS record
listing names queries on which result in NXDOMAIN, or for which neither A
nor
AAAA records exist.
WJH: To the last paragraph of the NS section, I added two sentences:
- 2 NS records").</t>
+ 2 NS records"). 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. This situation should
+ never happen unless the child nameservers are misconfigured.</t>
WJH: and to the address section, added:
- records for the child should be an empty set.
+ records for the child should be an empty set. However, if the
+ end result of processing would leave no glue records present
+ in the parent zone for any of the of the in-bailiwick NS
+ records, then the parent MUST NOT update the glue address
+ records. I.E., if the result of the processing would leave no
+ in-bailiwick A or AAAA records when there are in-bailiwick NS
+ records, then processing of the address records can not happen
+ as it would leave the parent/child relationship without any
+ address linkage.
*** NOFIX Point 3--
I don't think you've specifically excluded RRtypes not mentioned in section
3.2. It's seems obvious to me based on what's stated in section 2 that the
intention of the document is to only support these two RRtypes, but I think
it
is necessary to say so explicitly, if that is in fact what is intended. If
something else is intended, text explaining what is intended should be
added.
E.g., if it's okay for cooperating child name servers to set bits not listed
here, and for cooperating parent name servers to process them, you should
say
so.
WJH: This is stated, and I think you missed it. Section
2.1.1.2.1 (about the type bit map field) states (slightly
different based on a comment from Stephen, who did see it):
Specifically: a parental agent must not just copy the data
and must understand the semantics associated with an bit in
the Type Bit Map field that has been set to 1.
Let me know if you think this is insufficient.
*** DONE In 2.1.2, why SHOULD and not MUST here?
Implementations that support parsing of presentation format
records SHOULD be able to read and understand these TYPE
representations as well.
WJH: Because parsers don't necessarily need to understand the
semantics of the record. They just need to be able to keep
reading and store the data. Storing the data in ascii text is
just fine if they're not going to process it in any other way.
It'd be better if they understood it, but I can see cases where
they don't full support everything (eg, new types listed even
though they know some of them).
*** DONE In 3.2.1, what happens if the parent queries a host, and that host no
longer
appears in the updated NS record? I think this is Mostly Harmless, but
might
be worth mentioning. Also, in principle if the old server is left running
but
no longer authoritative, this whole scheme would fail if, for example, it
had
been the master prior to the change, were not configured to no longer serve
the
zone, and were no longer being updated. This is probably worth mentioning
as
an operational consideration.
WJH: Added the following text updates to address these points:
To the bottom of section 3.2.1:
<t>Note that it is permissible for a child's nameserver to
return a CSYNC record that removes the queried nameserver
itself from the future NS or address set.</t>
To the bottom of section 4.2:
<t>Children that wish to phase out a nameserver will need to
publish the CSYNC record to the nameserver being removed and
wait for the parental agent to process the published record
before turning off the service. This is required because the
child can not control which nameserver in the existing NS set
the parental agent may choose to query when performing CSYNC
processing.</t>
--
Wes Hardaker
Parsons
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
