> On 15. Aug 2022, at 20:25, Ray Bellis <r...@bellis.me.uk> wrote: > > > > On 15/08/2022 19:17, Paul Vixie wrote: > >> of course i meant that each such namespace would get its own >> "sub-domain" under .alt (e.g., .GNS.ALT). > > Someone also gets to solve the problem of how you get a CA/Browser Forum > Approved TLS cert for any system not accessible via "normal" DNS...
Is ".onion" accessible via "normal" DNS? Anyway. My 2 cents regarding the subnamespace: I agree with Paul that it would be great if there is a IANA registry for .alt subdomains. I do not agree that the registration policy should allow multiple entries for the same subdomain or be "free for all" as it is currently in the draft. Apart from the arguments here brought forwarded why this is a bad idea for DNS and the global namespace (leakage) and this also applies to any namesystem using ".alt", from a draft authors perspective this is kind of silly: The IETF would require us (we currently do not want a TLD/namespace or apply for one; that was in the past) to use a subdomain to separate a carved-out namespace (a separation which we do not even discuss yet in the draft) from DNS. At the same time we need to now tell implementers on how to handle the namespace ".gns.alt". But, it is not as simple as "only accept names with suffix .gns.alt". Because, this namespace may be squatted already (or in the future!) by another resolution mechanism and we have no normative way to distinguish the names and neither does the implementer. So we would have to discuss this as an unsolvable security consideration :( Again, this would not be a problem as-is; this will become a problem as soon as we touch the namespace and name issue in the draft beyond [1]. So, from my authors hat, I would appreciate FCFS; ideally also existing RFC/Other Specification + Implementation(s) for a registration in the registry. Of course, as proposed by someone else, not using any TLD and just allowing us to specify a protocol without touching the namespace at all would also be a viable option. To throw something out: Maybe consensus could be found on a boilerplate statement for drafts such as ours with pitfalls and issues with namespace ambiguity with [1] as a starting point. Also maybe to specifically state that a standards action would be required to actually "get" a namespace or "replace" the "actual DNS resolution protocol"? BR Martin [1] https://www.ietf.org/archive/id/draft-schanzen-gns-21.html#name-namespace-ambiguity > > Ray > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
