[DNSOP] Re: [EXT] [dtn] Re: An Interplanetary DNS Model

["Sipos, Brian J." <[e-mail]>]

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 <[e-mail]>
> Sent: Thursday, July 25, 2024 12:24 PM
> To: Sipos, Brian J. <[e-mail]>
> Cc: Marc Blanchet <[e-mail]>; Lorenzo Breda
> <[e-mail]>; DTN WG <[e-mail]>; dnsop <[e-mail]>
> Subject: Re: [DNSOP] Re: [EXT] [dtn] Re: An Interplanetary DNS Model
> 
> APL external email warning: Verify sender [e-mail] 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 <[e-mail]>
> >> Sent: Wednesday, July 24, 2024 4:44 PM
> >> To: Marc Blanchet <[e-mail]>
> >> Cc: Lorenzo Breda <[e-mail]>; DTN WG <[e-mail]>; dnsop
> >> <[e-mail]>
> >> Subject: [EXT] [dtn] Re: [DNSOP] An Interplanetary DNS Model
> >>
> >> APL external email warning: Verify sender
> >> [e-mail] before clicking links or attachments
> >>
> >> Hi Marc,
> >>
> >> On Wed, 24 Jul 2024, Marc Blanchet wrote:
> >>
> >>>
> >>>
> >>>       Le 24 juill. 2024 à 11:42, Lorenzo Breda
> >>>       <[e-mail]> 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 -- [e-mail]
> >>> To unsubscribe send an email to [e-mail]
> >>>
> >>>
> >>>
> >>>
> >