Subject: NSEC3 Issue 13: DDNS and Opt-In Determination

From: Geoffrey Sisson <[email-masked]>
Date: Tue, 21 Feb 2006 18:29:12 GMT

Issue:

When a DDNS client sends an UPDATE transaction containing RRs for a new
unsigned delegation to be inserted into an NSEC3 zone, there is no
obvious way for the server to determine whether or not the new
delegation should be included in the NSEC3 chain.  This is because the
values of the Opt-In fields of NSEC3 RRs in the zone need not be
uniform.  In other words, it's permissible to include and exclude
unsigned delegations in the NSEC3 chain in any combination.

Discussion:

Possible approaches:

1.  No support for Opt-In in DDNS

    - All NSEC3 RRs produced as a result an UPDATE will
      default to Opt-In = 0

    - Cannot change value of NSEC RR.

2.  Use overloaded NSEC3 RR to signal Opt-In

    - New unsigned delegations will default to Opt-In = 0, i.e. they
      will be included in the NSEC3 chain.  An unsigned delegation may
      be removed from the NSEC3 chain by sending an UPDATE containing
      an NSEC3 RR with the /unhashed/ owner name of the delegation and
      the Opt-In flag set to 1.  If the NSEC3 RR is included in the
      same atomic update as the RRs of the new unsigned delegation,
      the new delegation will not be inserted into the NSEC3 chain in
      the first place.

    - This method is in effect an overloading of the NSEC3 RR.
      The owner name of the NSEC3 RR in the UPDATE is be the owner name of
      the delegation, not the hashed value.  Only the value of the Opt-In
      field is meaningful; the other data in the RDATA section is ignored.

    - UPDATEs containinr than on RRs exist, the server will return an error.

    However:

    - Convoluted use of NSEC3 RR.

    - NSEC3 RR is larger than required, as only one bit of the
      16 octet RDATA section will be meaningful in a DDNS context.

    - Has unresolved corner cases, e.g. what if an UPDATE removes
      an unsigned delegation which is at the boundary of two
      spans, one with Opt-In = 0 and the other with Opt-In = 1?

3.  Introduce a new RRTYPE for used with DDNS updates

    - Similar to previous, but uses a new RRTYPE, e.g. `OPTOUT', rather
      than overloading the NSEC3 RR.

    - RR more compact as only one octet will be required for RDATA
      section.

    However:

    - requires use of a dedicated RRTYPE which would be meaningful only
      in the context of DDNS updates.

    - Has corner cases such as the one described in Approach 2.

4.  Inherited behaviour

    - If an update containing a new unsigned delegation falls in
      a span with Opt-In = 1, then it's not added to the NSEC3
      chain; if falls on one one which is Opt-In = 0, it is added.

    However:

    - Mismatch between granularity of control permitted by

    - Has corner cases such as the one described in Approach 2.

5.  Discourage or prohibit partial Opt-In zones.

    - Opt-In = 0 or Opt-In = 1 for all NSEC3 RRs in a chain.

    - Use cases unknown for partial Opt-In zones.

    However:

    - Adds unnecessary restrictions to the protocol.

Resolution:

None.  We are still investigating the problem space.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>