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