Subject: [DNSOP] DS transfer requirements

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Apr 2013 06:18:45 -0700

Ed pointed me to a message he wrote [1] and some of the text there
triggered my "oh yeah; we need to start with the requirements" bell.  I
think part of the problem has been we don't have a good list of
requirements to compare any given solution to and we're talking around
them all because they're not written down (at least in one place).  So,
stealing bullets from Ed's text and adding some, what are in these lists
that shouldn't be, or is in the wrong place and what is missing
entirely?  There are some I surely suspect people disagree about their
location in the list.  This is very much a working-document list.

* MUST be able tos

  + Let the child be able to signal a desire to:
    - add a DS record for a key that is not yet published.
    - delete a DS record for a key that has never been published.
    - add a DS recrord for a key that is in use.
    - delete a DS record for a key that is in use.
    - add DS records for hashes not previously supported.
    - add DS records for hashes I am moving away from.

  + Allow the insertion/deletion action to be done by the parental agent
    when the child and parent both agree that one of these will trigger
    a "go" indication:
    - A child operator indicates "go" via a secondary mechanism (e.g., http)
    - Immediately after successful data verification within the transfer
      mechanism 

  + Not change existing DNSSEC validation steps (see [2] below)

* SHOULDs if possible
  + be able to signal using key material
  + be able to signal using DS hash material
  + operate on a single record at a time (publish this DS, don't touch
    the rest)

* MAYs
  + [2] If DNSSEC is used to validate the data, there may be other
    data verification steps (cryptographic or not) required before a
    "go" can occur

* Explicitly *not* a requirement:
  + Use the DNS itself as the transport

What else?  I'm quite sure there are more.  (And I'm pseudo-deliberately
stopping here to make sure that I don't sound like I'm trying to impose
only just my ideas or the ones I pulled from Ed's message).

Footnotes: 
[1]  http://www.ietf.org/mail-archive/web/dnsop/current/msg10293.html

-- 
Wes Hardaker
Parso
ns

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 24 Apr 2013 15:57:53 +0200

Op 24-04-13 15:18, Wes Hardaker schreef:

> + operate on a single record at a time (publish this DS, don't
> touch the rest)

I don't understand the rationale behind this one.
Can someone please explain to me?

I would think a child knows what "the rest" is at all time, and it's
best for him to have that oversight before he changes anything.
What am I missing, unknown standby keys?

When I change one nameserver in my delegation, I have to fill in the
other ones too with most parents. Where is DS different in that it
needs this requirement?

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Joe Abley <[email-masked]>
Date: Wed, 24 Apr 2013 09:59:14 -0400

Hi Wes,

On 2013-04-24, at 09:18, Wes Hardaker <[email-masked]> wrote:

> I
> them all because they're not written down (at least in one place).

I like your list. I think it's useful.

I think it's also instructive to write down the workflow of how changes might occur. For example,

1. each polling party (registry, registrar, parent zone operator, something) maintains a list of child zones that should be polled for CDS RRSets (which could be "all children", "all customers who have clicked a button to say they want to be polled", "child zones that we publish a DS for" or something else)

2. those child zones are polled regularly and the result is occasionally the construction of change requests for the DS RRSet

3. the polling party satisfies their requirements that a change should be made (e.g. automatic so long as technical checks pass, signal the child zone operator and request an out-of-band confirmation, something else)

4. the change is made in the parent zone (e.g. through direct changes to a locally-maintained parent zone, EPP signalling to a registry, something else)

Perhaps this could be made more general, but those four steps seem fairly integral to me, regardless of the shape of the relationship between child zone operator and parent zone operator.

A parent zone operator who wants to generate her own DS RRSets for a child zone could use the CDS signalling as method to identify a DNSKEY, could retrieve the DNSKEY RR in question (checking signatures) and generate their own DS RR for publication. The problem of how to signal the desire to publish a DS for a key that has not yet been published remains.

It occurred to me that there may be use cases where including a "do not process before <date>" and "do not process after <date>" on a CDS RR might be useful, especially if the time taken for the parent to poll is not predictable. But I haven't thought that through very hard.

Joe

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 24 Apr 2013 07:30:27 -0700

> What am I missing, unknown standby keys?

Well, I agree: you should be able to say "publish this list" and have it
be the entire set.  But others have indicated (in random conversations)
they want to be able to distinctly say do this or that.  I suspect that
it would be fine to bulk-publish a list for most people, however.

But the one caveat is that if we end up adding a hold-down time, and you
want to make another (but different) change half way through the
hold-down time then your only choice is to restart entirely or wait.
But it depends on what the hold down is watching too.

The real requirement could probably be better worded to indicate some
sort of independence between add/remove operations.

-- 
Wes Hardaker
Parsons

---

From: Edward Lewis <[email-masked]>
Date: Mon, 29 Apr 2013 14:07:44 -0400

> Can someone please explain to me?

In the sense that having to tell the parent that "I want these 10 DS records now" and then later "I want these 9 DS records now", resulting in the transfer of 19 records.  I could say, "please delete this one record now."  I.e., less to transfer.

The tradeoff is whether you value the mythical property of idempotent operations (where an unintentional repeated request has no bearing) or value minimizing verbiage exchanged.

Idempotent operations has appeal, but having lived through it, it's not "all that."  The alternative approach means the child has to maintain state and an eye on the parent.

Anyway, that's a rationale behind it.  Not a judgement.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.