On Mon, 27 Apr 2020, Brian Dickson wrote:
The other would be the kind that are multiple-depth delegation zones, where the
Public Suffix List is already kind of necessary.
What I think is needed is a way to explicitly declare the places where the depth
is > 1 (if a normal flat delegation-only zone has depth == 1).
We thought about using two bits instead of one, so we could specify a
variable depth (per zone, not per delegation) but it seemed to add a
lot of complexity. It is far easier for these TLDs to make their ENTs
a signed delegation.
And that would effectively just need a way of making permanent and well-known,
the set of ENTs for the zone (empty non-terminals).
I think that list is likely to be short even for the most convoluted zones..
Doing things in more variable ways with lists of exceptions to a depth
== 1 seems very complicated and would add complexity for resolvers.
Without this, it would be theoretically possible for the TLD to add additional
unsigned delegations to bypass a signed delegation.
I do not understand this? You mean leaving the ENT unsigned, and then
adding NS records to create a false shadow tree? At best that would
result in DS records for the real delegations to be ignored because
there is a validation error in the path. Or if the DS records would
still be served signed from the parent, then this hostile takeover
via unsigned records would not work because the shadow tree would not
have the DNSKEYs matching the signed DS record.
If two delegations were present, child.example.com and example.com, it would
not be possible to disambiguate them without knowing more about the zone
structure and semantics.
This is an interesting case I had not considered. If a TLD hands out
domains in a mix of 1 level and 2 levels deep, what can be done
other than not using this draft? If the ENTs are limited, then
I'd still be tempted to say to turn those into real signed zones.
Any mechanism that would convey this list of ENT's would really
complicate things far more than just turning the ENTs into real
signed zones.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
