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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: