The suggestion of DNAME to empty.as112.arpa involves some subtle details, which 
IMHO may in combination be the right mix here.

The DNAME target is an insecure empty zone.

This avoids the validation issue, and facilitates use of local "alt" namespaces.

The default response to queries under alt would be unsigned NXDOMAINs.

I am not seeing a problem with this.

Am I missing anything?

Brian

Sent from my iPhone

> On Feb 6, 2017, at 10:31 PM, Mark Andrews <ma...@isc.org> wrote:
> 
> 
> 
> 
> 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

Reply via email to