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

[Andrew Sullivan <[e-mail]>]

On Tue, Feb 07, 2017 at 10:01:23AM -0500, Bob Harold wrote:
> What I envision for the future is an insecure delegation of .alt, and an
> option in future cable modems to enable a local "homenet.alt" domain, which
> would just work, even if some stub resolvers in the house are validating.
> The cable modem is already a recursive resolver or forwarder, and dhcp
> server, so it seems a logical place for the local domain.

No, it won't just work if a stub is validating, because the validating
stub will want to validate the delegation from the parent, and that
will be a proof of non-existence.  Provable non-existence prevents you
from being poisoned through typosquatting, but it means you can't
inject things in the tree without co-operation from the parent.

This is part of why I don't want to extend alt this way, and the more
I think about it the less desirable it seems to me.  We have a
particular problem: non-DNS-protocol switching for applications that
want to use a DNS-compatible domain name slot (see RFC 5890).  This is
problems like onion, local, and so on.  We propose a solution in which
we steal four of the available 255 octets to create a "safe" space
from DNS delegation.  Now anyone can use that space for their non-DNS
protocol, and every resolver library in the world knows that if it
runs into a name in the alt tree it shouldn't need to look it up in
DNS.  If the query leaks to the root and gets a proof of
non-existence, it doesn't matter because it was supposed to be a
different protocol.  Non-existence in the DNS is analytically true.
If a validating resolver gets an answer back from another resolver
that provides NXDOMAIN without the proof of non-existence and treats
the result as bogus instead, who cares?  It was never supposed to
resolve in the DNS anyway.

The homenet case is different, because it _is_ supposed to work with
DNS.  In that case, the missing proofs are a problem for validating
end points.

Best regards,

A

-- 
Andrew Sullivan
[e-mail]