Re: [DNSOP] ALT-TLD and (insecure) delgations.

[Suzanne Woolf <[e-mail]>]

> On Feb 3, 2017, at 9:40 PM, Ted Lemon <[e-mail]> wrote:
> 
> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan <[e-mail] <mailto:[e-mail]>> wrote:
>> My memory is that only after that
>> did we start thinking of a sort of 1918-style part of the DNS as
>> well.  That may have been a mistake, since as this discussion is
>> showing the properties of an in-protocol, in-DNS namespace without
>> delegations are somewhat different to alternative-protocol uses that
>> do not rely on the DNS at all.
> 
> I think that we've seen a number of questions go by that lead to the conclusion that it makes sense to have two hierarchies: one for experimental non-DNS queries, and one for locally served zones.   I don't know if we _need_ the .LSZ (or whatever) SUTLDN, but if we need to be able to have a special-use top-level domain name that has an un-signed delegation, it probably ought to be different than the SUTLDN that is used for non-DNS stuff, so that both names can have the appropriate configuration in the root zone.

We may be making this harder than it has to be.

It’s worth noting at this point that the "1918-style part of the DNS” (DNSSEC compatibility for names intended to be locally resolved with the DNS protocol) is a solved problem, if you mean it literally: they’re under .arpa.

This was an obvious solution for address blocks, since in-addr.arpa was already established by the protocol for PTR records and .arpa was already administered under IETF rules.

However, in terms of the desired behavior all the parts are there: .arpa is a signed zone, can have signed or unsigned delegations for names intended to be resolvable in the DNS (locally or globally), and is administered under IETF rules that include *not* delegating special use names under it that shouldn’t be in the DNS (I don’t see the IAB having a problem with making a commitment that a specific string won’t be delegated).

The objections to .home.arpa were to the specific string “.arpa” and that it wasn’t a single-label name, which seemed to be strong preferences but I’m not sure were ever documented as hard (“it won’t work otherwise”) requirements. For other special use names, they might very well not be constraints.

Having already decided that “single label” is a tough constraint to maintain if you want an unsigned delegation from a signed zone (i.e. an unsigned TLD in the root), I’m not sure I see a major difference between mystring.alt and mystring.arpa.


Suzanne