Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY

[Warren Kumari <[e-mail]>]

On Thu, Feb 6, 2014 at 1:29 PM, 神明達哉 <[e-mail]> 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?)

Hmmm...

What we were trying to say is that the parent publishes verbatim what
the child says.


So, lets say that at time T things look like this:
Parent:
  example.com. 300  IN DS 31589 8 1 123456.....
Child:
   example.com. 300  IN CDS 31589 8 1 123456......
[ The parent and child are in sync ]

At time T+1 the child decides to perform a key rollover, so they
generate a new DNSKEY, compute the DS, etc.
Parent:
  example.com. 300  IN DS 31589 8 1 123456.....
Child:
  example.com. 300  IN CDS 31589 8 1 123456......
  example.com. 300  IN CDS 31589 8 1 789ABC......
[ The parent still has not updated yet ]

At time T+2 the parent performs the CDS action (either they polled, or
the person operating the child logged onto the web interface and
clicked a button):
The parent sees that what the child has published does not match with
the parent currently has, and so the parent copies the contents from
the child. Now things look like:
Parent:
  example.com. 300  IN DS 31589 8 1 123456......
  example.com. 300  IN DS 31589 8 1 789ABC......
Child:
  example.com. 300  IN CDS 31589 8 1 123456......
  example.com. 300  IN CDS 31589 8 1 789ABC......
[ The parent and child are now in sync / agreement again ]

At time T+3 the child sees that the parent has published the new key
information ( and the standard keyroll stuff has all happened (records
are signed with new key, waited for old TTLs to expire, etc)) and so
wants to remove the old key.
** This is, as far as I understand, what you were  asking about)
The child now publishes just the new key info. They stop publishing the old one.
Parent:
  example.com. 300  IN DS 31589 8 1 123456......
  example.com. 300  IN DS 31589 8 1 789ABC......
Child:
  example.com. 300  IN CDS 31589 8 1 789ABC......
[ Child is only publishing new record / they stop publishing the old one ]

At time T+4 the parent checks agin (it polls, the human clicks the
button on the web page, some other trigger happens, etc):
It sees that what the child has published does not match what the
parent currently has, and so it copies the contents from the child.
Parent:
  example.com. 300  IN DS 31589 8 1 789ABC......
Child:
  example.com. 300  IN CDS 31589 8 1 789ABC......
[ The child and parent are back in sync. The old key (123456...) is no
longer in use anywhere. ]


The CDS RR set says, in effect, "Please replace *all* of the key
information for me with *this* set of info."

>
> 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.

It at any point during this process the parent contacts the child and
does NOT find any CDS records, it simply does nothing.
This means that you can use this to update / replace / remove existing
DS records (if you have keys A, B, C and D and want to stop using C,
you simply publish A, B, D), but you cannot remove *all* DS records /
go unsigned.


>
> Am I missing some part of the draft that answers my question, or is
> this actually out of scope of CDS/CDNSKEY?

I think that it in in the draft, but we need to be clearer that the
CDS/CDNSKEY *RRset* that the child publishes should be published in
the parent exactly (after transforming DNSKEYs to DS if needed). This
isn't a "please add record X" or "please remove record Y", it is
"Please publish this *list*"
We specifically want to remove the need for the parent to maintain state, etc.

>
> p.s. apologize in advance this was already discussed; I don't remember
> all previous discussions of the proposal.

Me neither!
:-)

W


>
> --
> JINMEI, Tatuya
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop