>> 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. ...
Yeah. It seems to me that if we want DNSSEC to work for locally served DNS subtrees, we need some way to distribute trust anchors for the subtrees to those cable modems. While that is probably not an insoluble problem, it is not one that I would plan to solve any time soon, so it's one I would prefer to address separately. >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). Agreed. Say that you can do anything you want with .ALT (duh) but you SHOULD NOT resolve .ALT names via the DNS protocol because of the DNSSEC problems. To minimize leakage, we can use the tools we already have: qname minimization, local mirrors of the root, and special casing in DNS caches as many now do for .onion. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
