神明達哉 <[email protected]> wrote:
> I have one quick question about CDS/CDNSKEY: what's the (or "an")
> expected operation for the parent to remove a DS RR of a child that
> was obsolete and is now removed from the child zone?
>
> This point is not clear to me on a quick rescan of
> draft-ietf-dnsop-delegation-trust-maintainance-02.
>
> According to Section 3:
>
> The CDS / CDNSKEY record is published in the child zone and gives the
> child control of what is published for it in the parental zone. The
> CDS / CDNSKEY RRset expresses what the child would like the DS RRset
> to look like after the change; [...]
>
> it could read the child would remove the CDS or CDSKEY for the
> now-removed DNSKEY, but it may contradict Section 4.1:
>
> Absence of CDS / CDNSKEY in child signals "No change" to the current
> DS set.
>
> (BTW: this sentence is a bit ambiguous to me. Does this mean there's
> no CDS/CDNSKEY RR for the apex name, or the absence of CDS/CDNSKEY for
> a specific DNSKEY?)
I think this second quote from the draft is supposed to mean: absence of
any CDS or CDNSKEY RRsets signals no change.
If there is a CDS or CDNSKEY RRset then the DS RRset should be changed to
match (provided the other acceptance rules are satisfied).
I believe the intent of the draft is that this mechanism cannot be used to
go insecure - though I cannot immediately find text which explicitly says
that. So for a CDS or CDNSKEY RRset to have any effect, it must exist,
which implies there must be at least one DS in the parent zone, which
implies you cannot go insecure.
> and also Section 5:
>
> When the Parent DS is "in-sync" with the CDS, the Child DNS Operator
> MAY delete the CDS RRset.
>
> i.e., if the child may delete a CDS for a new DNSKEY after
> synchronization, clearly it cannot use the removal of CDS as an
> indication of the removal of DNSKEY.
This quote from the draft talks about removing the entire RRset, so it is
consistent with my explanation above.
To indicate the removal of a DNSKEY, the child uses a CDS RRset which
does not include a record matching the removed DNSKEY, but does include
the other DNSKEYs that are still present.
Tony.
--
f.anthony.n.finch <[email protected]> http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
