Scott, Yes, new qualified names (identifiers) for new things will disambiguate from existing names. The important thing is to avoid a truly "split horizon" DNS situation where the same qualified name means different things in different contexts (the lack of specific records visible from a context is different than records with different meaning though). The DNS already provides a facility to have human-facing relative/unqualified names while the tools resolve to and manage qualified names, so there isn't a need for new terms or techniques here.
> -----Original Message----- > From: Scott Johnson <sc...@spacelypackets.com> > Sent: Thursday, July 25, 2024 12:24 PM > To: Sipos, Brian J. <brian.si...@jhuapl.edu> > Cc: Marc Blanchet <marc.blanc...@viagenie.ca>; Lorenzo Breda > <lore...@lbreda.com>; DTN WG <d...@ietf.org>; dnsop <dnsop@ietf.org> > Subject: Re: [DNSOP] Re: [EXT] [dtn] Re: An Interplanetary DNS Model > > APL external email warning: Verify sender sc...@spacelypackets.com before > clicking links or attachments > > Hi Brain, > > Are you in concurrance that using new, dedicated TLDs only for off world use > (and discrete to a single world) solves this issue? > > Thanks, > ScottJ > > On Thu, 25 Jul 2024, Sipos, Brian J. wrote: > > > All, > > I'm replying to a non-specific message in this chain just to mention that, > > similar > to what Lorenzo brought up, any translation of identifiers (names or > addresses) > will be fraught with problems related to security and should not be done. > There > can be translation or mapping that happens in a way not visible to > users/clients, > but whatever identifiers are visible to the user/client need to have stable > meaning across any network. > > > > Naming authorities, such as PKIX CAs, need to rely on the fact that once a > > user > proves ownership of a specific identifier that same identifier will not be > used by > other users (at least not simultaneously over a short time interval). Part of > the > reason why public CAs such as Let's Encrypt will not issue certificates for IP > addresses is the prevalence of IP NATs, even though IP identifiers are > allowed by > the CA/Browser TLS baseline [1]. > > > > [1] > > https://cabforum.org/working-groups/server/baseline-requirements/docum > > ents/CA-Browser-Forum-TLS-BR-2.0.5.pdf > > > >> -----Original Message----- > >> From: Scott Johnson <sc...@spacelypackets.com> > >> Sent: Wednesday, July 24, 2024 4:44 PM > >> To: Marc Blanchet <marc.blanc...@viagenie.ca> > >> Cc: Lorenzo Breda <lore...@lbreda.com>; DTN WG <d...@ietf.org>; dnsop > >> <dnsop@ietf.org> > >> Subject: [EXT] [dtn] Re: [DNSOP] An Interplanetary DNS Model > >> > >> APL external email warning: Verify sender > >> forwardingalgori...@ietf.org before clicking links or attachments > >> > >> Hi Marc, > >> > >> On Wed, 24 Jul 2024, Marc Blanchet wrote: > >> > >>> > >>> > >>> Le 24 juill. 2024 à 11:42, Lorenzo Breda > >>> <lore...@lbreda.com> a écrit : > >>> > >>> > >>> Why are you against leaving the current TLDs implicitly on Earth by > >>> default? > >>> > >>> > >>> Right. One do not need a special TLD for space. We can use what we > >>> have and it just works fine. > >> > >> I do not disagree with this notion as respects my proposed architecture. > >> 3rd level domains mapped to off-world domains works just fine, for > >> the low low price of annual domain renewal. a tld representing each > >> remote world is preferable, however, because it is just "cooler;" > >> easier to use and more memorable than a much longer domain. This, > >> however, assumes we are talking about the same proposal, which we are > not. > >> > >>> One has just to be careful on remote resolution so that it contains > >>> what is needed: trust chain, local names, ... > >>> > >> > >> Lets be clear here, Marc. You are talking about a completely > >> different solution than I am; one predicated on IP only. Your > >> comment on this thread, without context, only serves to confuse the other > participants. > >> > >> For example, you are talking about using F-root, right? That is a > >> very different thing than the functionality which I am describing, > >> with significantly more network resource usage requirements. My > >> solution uses BP in some network segments. Personally, I don't think > >> your method will ever fly, primarily due to security reasons, but I > >> don't troll your threads about it in a manner which would muddy the > >> waters of those considering your proposal. I don't mind healthy > >> competition of ideas, but I do expect fair play. If you wish to > >> contrast the two methods, thats fine, yet unproductive, IMHO. Just make > sure the reader knows you are talking about your proposal, and not mine. > >> > >> ScottJ > >> > >> > >> > >>> This is discussed in: > >>> - running IP in deep space (noBP<->IP): > >>> https://www.ietf.org/archive/id/draft-many-deepspace-ip-asse > >>> ssment-01.txt > >>> - running DNS in remote places: > >>> https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networ > >>> k > >>> s-01.txt > >>> > >>> > >>> Regards, Marc. > >>> > >>> > >>> > >>> -- > >>> Lorenzo Breda > >>> _______________________________________________ > >>> dtn mailing list -- d...@ietf.org > >>> To unsubscribe send an email to dtn-le...@ietf.org > >>> > >>> > >>> > >>> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
