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 [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
