On Mon, Jun 15, 2020 at 3:00 PM Tony Finch <d...@dotat.at> wrote: > Paul Vixie <p...@redbarn.org> wrote: > > On Monday, 15 June 2020 17:58:42 UTC Tim Wicinski wrote: > > > > > > or since domains are cheap, why not buy a new domain, and use that for > the > > > namespace? > > > > that makes internet viral, and private communications require global > > allocations for no necessary reason. the above quite describes > centralization > > for the sake of centralization. nothing should be centralized unless > there's > > no other way to do what needs doing. > > > > reserving a corner of the namespace for decentralized operations makes > sense. > > There are perhaps three contexts that you might want a private namespace: > > * enterprisey setups > > * home setups >
No. Just No. At most, home setups may not want dedicated registered domains (that they pay money for directly to a registrar and indirectly to a registry). However, they absolutely need to have functioning global DNS ability, regardless of the parent domain(s) they might use. As long as they are able to have a workable FQDN, regardless of whether it is ephemeral or a stable name, that is the minimum requirement. As your argument below points out, any decentralized thing can't be used for this (regardless of whether it's anchored in 2-letter ISO space or underneath some arpa child). > > * splendid isolation > > For both the enterprise and home case, you're probably going to want to do > things beyond the DNS that are much easier if you're part of a global > namespace - TLS certs are probably the main one. For the enterprise case, > getting a suitable domain is normal. For the home case, it would make > sense for manufacturers of home gateways / access points to allocate a > per-customer subdomain. Then you can have IPv6 prefix delegation and > managed access to your devices at home without everything being proxied > via some cloud server. (I can dream?) > The enterprise case is not a single case, and is the exception that proves the point. As much as it may require more technically savvy operations, if there is a need for both an internet-reachable and a non-internet-reachable subsection of their infrastructure, having different name spaces with different properties is the answer that best fits their needs. Internal-only use is not only satisfied with non-delegated name spaces, it actually is a much better fit for everything. Both DNSSEC and PKIX (or more likely, DANE/TLSA for X.509 certs) are better fits for the internal-only case. The goal for internal only, is to ensure it CANNOT work over the internet, not just that it isn't guaranteed to work over the internet. You WANT resolution to fail. You WANT certificate validation to fail. You WANT DNSSEC validation to fail. Anchoring all of these things in a non-global namespace (which is still sufficiently well-defined to be highly collision resistant) is the ideal choice. This has NOTHING to do with the parts of an enterprisey setup for the parts that are meant to be internet-reachable. Trying to force the two things together for some perceived benefit is unwise in the extreme. As Randy Bush often says, to paraphrase, I encourage my competitors to do this. Except I'm not Randy, and I wouldn't encourage ANYONE to do this. That's just mean. > > For splendid isolation, you're already committing to setting up your own > CA and distributing keys, so you can probably set up your own fake root > zone and whatever else. I don't think it's something that should be > encouraged as a standard thing to do, though. How could it be made to work > usefully for non-technical home users? > You don't want home users doing this, ever. Even the most extreme cases in homenet WG still envision having their stuff linked below the DNS equivalent of a prefix delegation, optionally. If there is any ambiguity in the draft to the effect that anyone other than the non-internet-reachable enterprisey or the splendid isolation use cases, let's make the document better to that effect. Respectfully, Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
