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

Scott Johnson <scott@spacelypackets.com> Sat, 27 July 2024 08:56 UTC

Return-Path: <scott@spacelypackets.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69806C17C8A9; Sat, 27 Jul 2024 01:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrE6LzWFnbg5; Sat, 27 Jul 2024 01:56:49 -0700 (PDT)
Received: from www.spacelypackets.com (www.spacelypackets.com [IPv6:2602:fdf2:bee:feed::ee]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0E0C17C8B0; Sat, 27 Jul 2024 01:56:47 -0700 (PDT)
Received: from scott (helo=localhost) by www.spacelypackets.com with local-esmtp (Exim 4.96) (envelope-from <scott@spacelypackets.com>) id 1sXdCE-0008IY-2a; Sat, 27 Jul 2024 08:54:34 +0000
Date: Sat, 27 Jul 2024 08:54:34 +0000
From: Scott Johnson <scott@spacelypackets.com>
To: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>
In-Reply-To: <20080798d3744898900d9e610f2b3568@jhuapl.edu>
Message-ID: <3a220c57-c908-dbe8-68a7-31b5743d5dc4@spacelypackets.com>
References: <65daf988-f696-4f35-5a72-5b11ef4893b8@spacelypackets.com> <CAEhHO_MaUFraCuur2uYEBrRcdKUty3ZwoPsFeP3V1iXf5vQxxA@mail.gmail.com> <b098f7cb-e42b-c7e4-56b8-dcb9125c17e9@spacelypackets.com> <CAEhHO_P4VmCC0VfxHRPdnvUzzwamMThbcuQAp1N98yWTCd-Bsg@mail.gmail.com> <0685c4ca-0b10-d7a8-ccd4-507dc6755d1a@spacelypackets.com> <CAEhHO_PbrkKqaJsBD+Fih+i1rY5YN+9=Y-fNUpOp2PfXL+hAuA@mail.gmail.com> <41A7771E-8D08-4272-B457-F9FE61CD77A3@viagenie.ca> <358b7baa-d4f1-5f73-152b-768806efa0f3@spacelypackets.com> <bdd9f024fb884af9adfa115e2971b598@jhuapl.edu> <4d704bbc-a1ed-c089-af18-78cfbae08094@spacelypackets.com> <20080798d3744898900d9e610f2b3568@jhuapl.edu>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="-2112415152-2030929502-1722070474=:27015"
Message-ID-Hash: RVDE232FGYORM2T6NMWSE2UJEM46XCBZ
X-Message-ID-Hash: RVDE232FGYORM2T6NMWSE2UJEM46XCBZ
X-MailFrom: scott@spacelypackets.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Marc Blanchet <marc.blanchet@viagenie.ca>, Lorenzo Breda <lorenzo@lbreda.com>, DTN WG <dtn@ietf.org>, dnsop <dnsop@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [EXT] [dtn] Re: An Interplanetary DNS Model
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/hn7Sj3G5z4lRDGe-Zmn3gSZXVUM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Hi Brian,

Thanks for the input.  It seems new TLDs for deployment on other worlds is 
the general consensus on how to accomplish this.  I will amend the draft 
to indicate this.

Thanks,
ScottJ

On Fri, 26 Jul 2024, Sipos, Brian J. wrote:

> 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 <scott@spacelypackets.com>
>> Sent: Thursday, July 25, 2024 12:24 PM
>> To: Sipos, Brian J. <Brian.Sipos@jhuapl.edu>
>> Cc: Marc Blanchet <marc.blanchet@viagenie.ca>; Lorenzo Breda
>> <lorenzo@lbreda.com>; DTN WG <dtn@ietf.org>; dnsop <dnsop@ietf.org>
>> Subject: Re: [DNSOP] Re: [EXT] [dtn] Re: An Interplanetary DNS Model
>>
>> APL external email warning: Verify sender scott@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 <scott@spacelypackets.com>
>>>> Sent: Wednesday, July 24, 2024 4:44 PM
>>>> To: Marc Blanchet <marc.blanchet@viagenie.ca>
>>>> Cc: Lorenzo Breda <lorenzo@lbreda.com>; DTN WG <dtn@ietf.org>; dnsop
>>>> <dnsop@ietf.org>
>>>> Subject: [EXT] [dtn] Re: [DNSOP] An Interplanetary DNS Model
>>>>
>>>> APL external email warning: Verify sender
>>>> forwardingalgorithm@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
>>>>>       <lorenzo@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 -- dtn@ietf.org
>>>>> To unsubscribe send an email to dtn-leave@ietf.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>