In message <3581be55-b178-4298-8ee8-73fd16b42...@gmail.com>, Brian Dickson
writes:
> Mark,
>
> I don't think the use cases for most of the sandbox involving alt, and/or
> the homenet use case, requires support for validating stubs. If stubs
> aren't already validating, the incremental addition of a local alt, only
> requires distribution of the trust anchor to the resolvers. That is a
> solvable problem for most values of "local".
It's not just stubs.
> If use cases for non-local or validating stubs exits, IMHO that rises to
> the level of requiring something real, not an alt name.
>
> If you think that is something that there is a demand for, I don't know
> if it might belong in a separate domain.
>
> An insecure delegation from the root may be seen as an invitation for
> exploitation by squatters.
And if they could find a way to squat here (which requires intercepting
queries) what would be the problem? We are expecting the namespace
to be squatted. Thats the whole point of the namespace. In fact
we are going to tell nameserver vendors to squat on .alt by default*
to generate the NXDOMAIN responses.
There is absolutely no need for a secure NXDOMAIN here. Just as
there is zero need for secure NXDOMAINs in COM, ORG, NET or any
other gTLD. The gTLDs prevent secure delegations being spoofed
away. The don't prevent names being spoofed into existence between
the secure delegations.
There is absolutely no need for a secure delegation here.
I have not seen anyone demonstrate a technical need for a secure
delegation for alt. There are no formal delegation in alt so there
can be no secure delegations from alt.
Mark
> Sent from my iPhone
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
