Re: [Starlink] IXPs in space

Re: [Starlink] IXPs in space

[David Fernández]

Apologies in advance for any *profound* misunderstanding that could
trigger any nerves, although I am grateful for all the info being
shared. I will read this carefully:
https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

In the abstract, I read, at the end: "Low level mechanisms to support
these functions are justified only as performance enhancements." So,
every rule has its exceptions, like the PEPs for TCP performance
acceleration.

"Adding those anycast addresses to the satellites would be transparent
to all users (assuming the satellites are operating at the IP layer,
the old bent-pipe approach did not, but once you have routing in space
via the laser links...)" Satellites being routers just because they
have ISL does not follow. Is there any satellite nowadays doing
routing in space? They do switching only (and not Ethernet switching).
Because of this I proposed the idea of the so called L2 snooping. It
is a hack, somehow similar to the PEPs to accelerate TCP, but in this
case to accelerate DNS (not encrypted), without making satellites
routers, keeping them transparent as they are now.

If it has not been done before by anybody is for a good reason, maybe.
Things like this did not have so much success, it seems:
https://en.wikipedia.org/wiki/Internet_Routing_in_Space

"DNS is an easy thing to start with compared to most others." Even in
this case you are going to find a lot of issues to do it with
transparent satellites, even with GEO satellites, where the gain could
be bigger and things simpler than with fast moving LEO satellites.

"bent pipe for normal operations doesn't mean that you can't watch for
an anycast address to serve locally." This is what I was suggesting,
you sniff packets in the satellite uplink and answer anycast DNS
queries directly from satellite, if you see any, cutting RTT by a
half.

Regards,

David

Re: [Starlink] IXPs in space

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

nobody else has had enough satellites in space to do real in space routing, so 
take anything you read about it that's not specifically referring to starlink 
as guesses/suggestions.

David Lang

On Mon, 17 Apr 2023, David Fernández via Starlink wrote:

> Date: Mon, 17 Apr 2023 16:22:33 +0200
> From: David Fernández via Starlink <starlink@lists.bufferbloat.net>
> Reply-To: David Fernández <davidfdzp@gmail.com>
> To: starlink <starlink@lists.bufferbloat.net>
> Subject: Re: [Starlink] IXPs in space
> 
> Apologies in advance for any *profound* misunderstanding that could
> trigger any nerves, although I am grateful for all the info being
> shared. I will read this carefully:
> https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
>
> In the abstract, I read, at the end: "Low level mechanisms to support
> these functions are justified only as performance enhancements." So,
> every rule has its exceptions, like the PEPs for TCP performance
> acceleration.
>
> "Adding those anycast addresses to the satellites would be transparent
> to all users (assuming the satellites are operating at the IP layer,
> the old bent-pipe approach did not, but once you have routing in space
> via the laser links...)" Satellites being routers just because they
> have ISL does not follow. Is there any satellite nowadays doing
> routing in space? They do switching only (and not Ethernet switching).
> Because of this I proposed the idea of the so called L2 snooping. It
> is a hack, somehow similar to the PEPs to accelerate TCP, but in this
> case to accelerate DNS (not encrypted), without making satellites
> routers, keeping them transparent as they are now.
>
> If it has not been done before by anybody is for a good reason, maybe.
> Things like this did not have so much success, it seems:
> https://en.wikipedia.org/wiki/Internet_Routing_in_Space
>
> "DNS is an easy thing to start with compared to most others." Even in
> this case you are going to find a lot of issues to do it with
> transparent satellites, even with GEO satellites, where the gain could
> be bigger and things simpler than with fast moving LEO satellites.
>
> "bent pipe for normal operations doesn't mean that you can't watch for
> an anycast address to serve locally." This is what I was suggesting,
> you sniff packets in the satellite uplink and answer anycast DNS
> queries directly from satellite, if you see any, cutting RTT by a
> half.
>
> Regards,
>
> David
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink

Re: [Starlink] IXPs in space

[Edwin Liava'a]

[-- Attachment #1: Type: text/plain, Size: 5593 bytes --]

Indeed an interesting and insightful discussion.

Tons of thanks to everyone for sharing.

Bravo!

On Mon, 17 Apr 2023 at 13:28, David P. Reed via Starlink <
starlink@lists.bufferbloat.net> wrote:

> David Fernandez and others here seem to have a *profound* misunderstanding
> of the core architecture of the Internet Protocols with respect to, say,
> Starlink.
>
>
>
> I am having a hard time sitting on my hands listening to this discussion,
> but hey, I just was one of the few people who spent a lot of time on the IP
> architecture, and maybe there are new, better ideas that we somehow missed.
> Clearly not.
>
>
>
> #1: There's a reason that the whole Internet is designed around "not
> putting extra functions" into the underlying network. It's outlined in a
> paper I wrote with Jerry Saltzer and David Clark, based on the work I did
> as part of the team that designed IP, TCP, and UDP, but abstracted as a
> principle of architecture. Please read the original paper carefully (and
> for goodness' sake don't read any of the Wikipedia pages that claim to
> explain the End-to-end principle or End=to-end argument, as a primary
> source I am actively barred from editing it and the paper, as a primary
> source, is viewed as suspect by Wikipedia, because Wikipedia requires that
> all citations be *secondary* sources).
> https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
>
>
>
> #2: DNS service doesn't specify that "geolocation" is a function of the
> DNS service. It is the job of the endpoint *after resolving the DNS name to
> one of many IP addresses* to decide which IP address to use for the DNS
> name. That is, "geolocation" is an endpoint function, not something that
> the network does by spying on packet contents and faking a response from
> real DNS servers.
>
>
>
> #4: In general, IP as a protocol underlying ALL of the Internet protocols
> is required to deliver the content to the address specified by the sender,
> *without either reading or modifying the content*. There are certain cases
> where "masquerading" as the destination is sometimes OK, but ONLY when the
> sender and receiver are specifically AWARE of this interception. This is
> called a Man In The Middle *attack* otherwise.
>
>
>
> #5: As a special case, some IP addresses are "anycast", which has nothing
> to do with DNS itself as a protocol, but instead provides some low-level
> "neighborhood" addressing for a class of servers. Cloudflare uses 1.1.1.1,
> for example, as an "anycast" address supported by the global Internet
> Routing architecture (BGP, for example), that can be used as a DNS caching
> resolver (server) address. This works because the DNS database is designed
> to be replicatable, so one can cache subsets of the DNS database for short
> durations without problems, because the servers are "loosely" replicated.
> But"anycast" doesn't guarantee (anymore than DNS itself does) that the most
> up-to-date information is available at any particular anycast instance.
> 8.8.4.4 is another DNS anycast address of a different set of resolvers, and
> may be more up to date or less up to date than 1.1.1.1.
>
>
>
> #6: The idea that one can "identify" DNS requests by snooping on layer 2
> packets is so crazy it is not even wrong. Layer 2 packets have layer 2
> addresses (like Ethernet addresses, e.g.). Their contents above Layer 2
> cannot be decoded. My DNS requests are DNS-over-HTTPS, except within my
> home I cache the answers on a local server that uses DNS/UDP/IP. I
> certainly don't trust any Elon Musk corporation not to spy on my traffic.
>
>
>
> #7: The general idea that one should put more function into Starlink
> Satellites basically will start to "fork" Starlink Enterprises (the Musk
> companies) as an "alternate Internet" where applications must use only the
> functions that Starlink supports (where other Internet providers may
> support broader standards or not support the special "Starlink-only"
> functions). This is a way to balkanize the Internet, and maybe Musk who
> loves Monopoly Power after all because it makes him more Powerful, sees
> that as a great thing. Certainly the Chinese Communist Party is trying hard
> to balkanize a Chinese-only Internet, spending a lot of money to block
> interoperability. Musk may envy China, I don't know.
>
> If you want a Balkanized, non-interoperable Internet, where the carriers
> feel free to examine all the traffic and create their own,
> non-interoperable protocol set, I'd suggest China might be a good place to
> move. Or maybe Mars?
>
>
>
> Now what's a powerful idea in the Internet (so far) is that what prevents
> bad ideas like this is that the Internet interprets such stupid ideas as
> damage, and routes around them. But to route around them, the Internet has
> to be overall, *interoperable*.
>
>
>
> There's no law, and no "cryptocurrency" like Ethereum that prevents bad
> ideas that destroy interoperability, in the Internet Architecture. Anyone
> can invent and deploy a new protocol, and you can invent new layer 2
> transport technologies too. But I daresay we who built the Internet will
> make it very clear that anyone ought to "route around you" (including using
> you with a tunnal that you can't interfere with except by blocking all
> communications).
>
>
>
> So, my recommendation: don't do such dumb things!
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>


-- 
Edwin Liava'a
WhatsApp: +61451013850
https://www.linkedin.com/in/edwin-liavaa

[-- Attachment #2: Type: text/html, Size: 8159 bytes --]

Re: [Starlink] IXPs in space

[Ulrich Speidel]

[-- Attachment #1: Type: text/plain, Size: 4167 bytes --]

On 17/04/2023 12:27 pm, David P. Reed via Starlink wrote:
>
> #2: DNS service doesn't specify that "geolocation" is a function of 
> the DNS service. It is the job of the endpoint *after resolving the 
> DNS name to one of many IP addresses* to decide which IP address to 
> use for the DNS name. That is, "geolocation" is an endpoint function, 
> not something that the network does by spying on packet contents and 
> faking a response from real DNS servers.
>
Oh dear. I think I didn't express myself well here - I didn't mean 
"geolocation" in the "Internet" sense of "Where is that IP address?" but 
in the sense of having a DNS server on a satellite that "knows" that 
querying clients are in its topological proximity, and is able to do a 
recursive DNS lookup for them from its own gateway DNS server (assuming 
that gateways will function as such) - yielding the topologically 
closest CDN server where applicable. Or - looking at it from the gateway 
DNS perspective - knowing that any DNS queries it gets are 
"topologically close". I shouldn't have used the term "geolocation" there.

> #4: In general, IP as a protocol underlying ALL of the Internet 
> protocols is required to deliver the content to the address specified 
> by the sender, *without either reading or modifying the content*. 
> There are certain cases where "masquerading" as the destination is 
> sometimes OK, but ONLY when the sender and receiver are specifically 
> AWARE of this interception. This is called a Man In The Middle 
> *attack* otherwise.
>
Never mind connection-breaking performance-enhancing proxies ;-)
>
>
> #6: The idea that one can "identify" DNS requests by snooping on layer 
> 2 packets is so crazy it is not even wrong. Layer 2 packets have layer 
> 2 addresses (like Ethernet addresses, e.g.). Their contents above 
> Layer 2 cannot be decoded. My DNS requests are DNS-over-HTTPS, except 
> within my home I cache the answers on a local server that uses 
> DNS/UDP/IP. I certainly don't trust any Elon Musk corporation not to 
> spy on my traffic.
>
Um, yes, indeed. Except that there is no reason that a satellite 
couldn't function as a fully fledged upstream DNS server (so you don't 
need all that layer 2 snooping stuff, which seems strange indeed). Every 
home DSL router has for years, and there's no reason you couldn't cache 
a bit more stuff either. Even on your home router, there's nothing that 
stops you from using a DNS server elsewhere. The question is whether it 
makes sense and is worth the effort, and my point is that it's very 
little gain for a lot of effort. E.g., you'd have to ensure dynamic 
(CDN) entries age off whenever the satellite changes gateway, because at 
that point, any clients that use the sat will be in a different 
topological location.

> #7: The general idea that one should put more function into Starlink 
> Satellites basically will start to "fork" Starlink Enterprises (the 
> Musk companies) as an "alternate Internet" where applications must use 
> only the functions that Starlink supports (where other Internet 
> providers may support broader standards or not support the special 
> "Starlink-only" functions). This is a way to balkanize the Internet, 
> and maybe Musk who loves Monopoly Power after all because it makes him 
> more Powerful, sees that as a great thing. Certainly the Chinese 
> Communist Party is trying hard to balkanize a Chinese-only Internet, 
> spending a lot of money to block interoperability. Musk may envy 
> China, I don't know.
>
> If you want a Balkanized, non-interoperable Internet, where the 
> carriers feel free to examine all the traffic and create their own, 
> non-interoperable protocol set, I'd suggest China might be a good 
> place to move. Or maybe Mars?
>
Taken as read.

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************



[-- Attachment #2: Type: text/html, Size: 7366 bytes --]

Re: [Starlink] IXPs in space

[David Lang]

I think that recent experience just reinforces the idea that the network should 
be neutral to the traffic going over it (with the allowance that people should 
be able to opt-in to services provided as they want to)

David Lang

On Sun, 16 Apr 2023, Hesham ElBakoury via Starlink wrote:

> Hi David,
> With in-network computing and programmable networks which can put many
> functions in the network, do you still think the E2E argument is still
> applicable? Or time has come to update it?
>
> Hesham
>
> On Sun, Apr 16, 2023, 5:28 PM David P. Reed via Starlink <
> starlink@lists.bufferbloat.net> wrote:
>
>> David Fernandez and others here seem to have a *profound* misunderstanding
>> of the core architecture of the Internet Protocols with respect to, say,
>> Starlink.
>>
>>
>>
>> I am having a hard time sitting on my hands listening to this discussion,
>> but hey, I just was one of the few people who spent a lot of time on the IP
>> architecture, and maybe there are new, better ideas that we somehow missed.
>> Clearly not.
>>
>>
>>
>> #1: There's a reason that the whole Internet is designed around "not
>> putting extra functions" into the underlying network. It's outlined in a
>> paper I wrote with Jerry Saltzer and David Clark, based on the work I did
>> as part of the team that designed IP, TCP, and UDP, but abstracted as a
>> principle of architecture. Please read the original paper carefully (and
>> for goodness' sake don't read any of the Wikipedia pages that claim to
>> explain the End-to-end principle or End=to-end argument, as a primary
>> source I am actively barred from editing it and the paper, as a primary
>> source, is viewed as suspect by Wikipedia, because Wikipedia requires that
>> all citations be *secondary* sources).
>> https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
>>
>>
>>
>> #2: DNS service doesn't specify that "geolocation" is a function of the
>> DNS service. It is the job of the endpoint *after resolving the DNS name to
>> one of many IP addresses* to decide which IP address to use for the DNS
>> name. That is, "geolocation" is an endpoint function, not something that
>> the network does by spying on packet contents and faking a response from
>> real DNS servers.
>>
>>
>>
>> #4: In general, IP as a protocol underlying ALL of the Internet protocols
>> is required to deliver the content to the address specified by the sender,
>> *without either reading or modifying the content*. There are certain cases
>> where "masquerading" as the destination is sometimes OK, but ONLY when the
>> sender and receiver are specifically AWARE of this interception. This is
>> called a Man In The Middle *attack* otherwise.
>>
>>
>>
>> #5: As a special case, some IP addresses are "anycast", which has nothing
>> to do with DNS itself as a protocol, but instead provides some low-level
>> "neighborhood" addressing for a class of servers. Cloudflare uses 1.1.1.1,
>> for example, as an "anycast" address supported by the global Internet
>> Routing architecture (BGP, for example), that can be used as a DNS caching
>> resolver (server) address. This works because the DNS database is designed
>> to be replicatable, so one can cache subsets of the DNS database for short
>> durations without problems, because the servers are "loosely" replicated.
>> But"anycast" doesn't guarantee (anymore than DNS itself does) that the most
>> up-to-date information is available at any particular anycast instance.
>> 8.8.4.4 is another DNS anycast address of a different set of resolvers, and
>> may be more up to date or less up to date than 1.1.1.1.
>>
>>
>>
>> #6: The idea that one can "identify" DNS requests by snooping on layer 2
>> packets is so crazy it is not even wrong. Layer 2 packets have layer 2
>> addresses (like Ethernet addresses, e.g.). Their contents above Layer 2
>> cannot be decoded. My DNS requests are DNS-over-HTTPS, except within my
>> home I cache the answers on a local server that uses DNS/UDP/IP. I
>> certainly don't trust any Elon Musk corporation not to spy on my traffic.
>>
>>
>>
>> #7: The general idea that one should put more function into Starlink
>> Satellites basically will start to "fork" Starlink Enterprises (the Musk
>> companies) as an "alternate Internet" where applications must use only the
>> functions that Starlink supports (where other Internet providers may
>> support broader standards or not support the special "Starlink-only"
>> functions). This is a way to balkanize the Internet, and maybe Musk who
>> loves Monopoly Power after all because it makes him more Powerful, sees
>> that as a great thing. Certainly the Chinese Communist Party is trying hard
>> to balkanize a Chinese-only Internet, spending a lot of money to block
>> interoperability. Musk may envy China, I don't know.
>>
>> If you want a Balkanized, non-interoperable Internet, where the carriers
>> feel free to examine all the traffic and create their own,
>> non-interoperable protocol set, I'd suggest China might be a good place to
>> move. Or maybe Mars?
>>
>>
>>
>> Now what's a powerful idea in the Internet (so far) is that what prevents
>> bad ideas like this is that the Internet interprets such stupid ideas as
>> damage, and routes around them. But to route around them, the Internet has
>> to be overall, *interoperable*.
>>
>>
>>
>> There's no law, and no "cryptocurrency" like Ethereum that prevents bad
>> ideas that destroy interoperability, in the Internet Architecture. Anyone
>> can invent and deploy a new protocol, and you can invent new layer 2
>> transport technologies too. But I daresay we who built the Internet will
>> make it very clear that anyone ought to "route around you" (including using
>> you with a tunnal that you can't interfere with except by blocking all
>> communications).
>>
>>
>>
>> So, my recommendation: don't do such dumb things!
>>
>>
>> _______________________________________________
>> Starlink mailing list
>> Starlink@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>

Re: [Starlink] IXPs in space

[Hesham ElBakoury]

[-- Attachment #1: Type: text/plain, Size: 5614 bytes --]

Hi David,
With in-network computing and programmable networks which can put many
functions in the network, do you still think the E2E argument is still
applicable? Or time has come to update it?

Hesham

On Sun, Apr 16, 2023, 5:28 PM David P. Reed via Starlink <
starlink@lists.bufferbloat.net> wrote:

> David Fernandez and others here seem to have a *profound* misunderstanding
> of the core architecture of the Internet Protocols with respect to, say,
> Starlink.
>
>
>
> I am having a hard time sitting on my hands listening to this discussion,
> but hey, I just was one of the few people who spent a lot of time on the IP
> architecture, and maybe there are new, better ideas that we somehow missed.
> Clearly not.
>
>
>
> #1: There's a reason that the whole Internet is designed around "not
> putting extra functions" into the underlying network. It's outlined in a
> paper I wrote with Jerry Saltzer and David Clark, based on the work I did
> as part of the team that designed IP, TCP, and UDP, but abstracted as a
> principle of architecture. Please read the original paper carefully (and
> for goodness' sake don't read any of the Wikipedia pages that claim to
> explain the End-to-end principle or End=to-end argument, as a primary
> source I am actively barred from editing it and the paper, as a primary
> source, is viewed as suspect by Wikipedia, because Wikipedia requires that
> all citations be *secondary* sources).
> https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf
>
>
>
> #2: DNS service doesn't specify that "geolocation" is a function of the
> DNS service. It is the job of the endpoint *after resolving the DNS name to
> one of many IP addresses* to decide which IP address to use for the DNS
> name. That is, "geolocation" is an endpoint function, not something that
> the network does by spying on packet contents and faking a response from
> real DNS servers.
>
>
>
> #4: In general, IP as a protocol underlying ALL of the Internet protocols
> is required to deliver the content to the address specified by the sender,
> *without either reading or modifying the content*. There are certain cases
> where "masquerading" as the destination is sometimes OK, but ONLY when the
> sender and receiver are specifically AWARE of this interception. This is
> called a Man In The Middle *attack* otherwise.
>
>
>
> #5: As a special case, some IP addresses are "anycast", which has nothing
> to do with DNS itself as a protocol, but instead provides some low-level
> "neighborhood" addressing for a class of servers. Cloudflare uses 1.1.1.1,
> for example, as an "anycast" address supported by the global Internet
> Routing architecture (BGP, for example), that can be used as a DNS caching
> resolver (server) address. This works because the DNS database is designed
> to be replicatable, so one can cache subsets of the DNS database for short
> durations without problems, because the servers are "loosely" replicated.
> But"anycast" doesn't guarantee (anymore than DNS itself does) that the most
> up-to-date information is available at any particular anycast instance.
> 8.8.4.4 is another DNS anycast address of a different set of resolvers, and
> may be more up to date or less up to date than 1.1.1.1.
>
>
>
> #6: The idea that one can "identify" DNS requests by snooping on layer 2
> packets is so crazy it is not even wrong. Layer 2 packets have layer 2
> addresses (like Ethernet addresses, e.g.). Their contents above Layer 2
> cannot be decoded. My DNS requests are DNS-over-HTTPS, except within my
> home I cache the answers on a local server that uses DNS/UDP/IP. I
> certainly don't trust any Elon Musk corporation not to spy on my traffic.
>
>
>
> #7: The general idea that one should put more function into Starlink
> Satellites basically will start to "fork" Starlink Enterprises (the Musk
> companies) as an "alternate Internet" where applications must use only the
> functions that Starlink supports (where other Internet providers may
> support broader standards or not support the special "Starlink-only"
> functions). This is a way to balkanize the Internet, and maybe Musk who
> loves Monopoly Power after all because it makes him more Powerful, sees
> that as a great thing. Certainly the Chinese Communist Party is trying hard
> to balkanize a Chinese-only Internet, spending a lot of money to block
> interoperability. Musk may envy China, I don't know.
>
> If you want a Balkanized, non-interoperable Internet, where the carriers
> feel free to examine all the traffic and create their own,
> non-interoperable protocol set, I'd suggest China might be a good place to
> move. Or maybe Mars?
>
>
>
> Now what's a powerful idea in the Internet (so far) is that what prevents
> bad ideas like this is that the Internet interprets such stupid ideas as
> damage, and routes around them. But to route around them, the Internet has
> to be overall, *interoperable*.
>
>
>
> There's no law, and no "cryptocurrency" like Ethereum that prevents bad
> ideas that destroy interoperability, in the Internet Architecture. Anyone
> can invent and deploy a new protocol, and you can invent new layer 2
> transport technologies too. But I daresay we who built the Internet will
> make it very clear that anyone ought to "route around you" (including using
> you with a tunnal that you can't interfere with except by blocking all
> communications).
>
>
>
> So, my recommendation: don't do such dumb things!
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 7893 bytes --]

Re: [Starlink] IXPs in space

[David P. Reed]

[-- Attachment #1: Type: text/plain, Size: 5060 bytes --]


David Fernandez and others here seem to have a *profound* misunderstanding of the core architecture of the Internet Protocols with respect to, say, Starlink.
 
I am having a hard time sitting on my hands listening to this discussion, but hey, I just was one of the few people who spent a lot of time on the IP architecture, and maybe there are new, better ideas that we somehow missed. Clearly not.
 
#1: There's a reason that the whole Internet is designed around "not putting extra functions" into the underlying network. It's outlined in a paper I wrote with Jerry Saltzer and David Clark, based on the work I did as part of the team that designed IP, TCP, and UDP, but abstracted as a principle of architecture. Please read the original paper carefully (and for goodness' sake don't read any of the Wikipedia pages that claim to explain the End-to-end principle or End=to-end argument, as a primary source I am actively barred from editing it and the paper, as a primary source, is viewed as suspect by Wikipedia, because Wikipedia requires that all citations be *secondary* sources).  [ https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf ]( https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf )
 
#2: DNS service doesn't specify that "geolocation" is a function of the DNS service. It is the job of the endpoint *after resolving the DNS name to one of many IP addresses* to decide which IP address to use for the DNS name. That is, "geolocation" is an endpoint function, not something that the network does by spying on packet contents and faking a response from real DNS servers.
 
#4: In general, IP as a protocol underlying ALL of the Internet protocols is required to deliver the content to the address specified by the sender, *without either reading or modifying the content*. There are certain cases where "masquerading" as the destination is sometimes OK, but ONLY when the sender and receiver are specifically AWARE of this interception. This is called a Man In The Middle *attack* otherwise.
 
#5: As a special case, some IP addresses are "anycast", which has nothing to do with DNS itself as a protocol, but instead provides some low-level "neighborhood" addressing for a class of servers. Cloudflare uses 1.1.1.1, for example, as an "anycast" address supported by the global Internet Routing architecture (BGP, for example), that can be used as a DNS caching resolver (server) address. This works because the DNS database is designed to be replicatable, so one can cache subsets of the DNS database for short durations without problems, because the servers are "loosely" replicated. But"anycast" doesn't guarantee (anymore than DNS itself does) that the most up-to-date information is available at any particular anycast instance. 8.8.4.4 is another DNS anycast address of a different set of resolvers, and may be more up to date or less up to date than 1.1.1.1.
 
#6: The idea that one can "identify" DNS requests by snooping on layer 2 packets is so crazy it is not even wrong. Layer 2 packets have layer 2 addresses (like Ethernet addresses, e.g.). Their contents above Layer 2 cannot be decoded. My DNS requests are DNS-over-HTTPS, except within my home I cache the answers on a local server that uses DNS/UDP/IP. I certainly don't trust any Elon Musk corporation not to spy on my traffic. 
 
#7: The general idea that one should put more function into Starlink Satellites basically will start to "fork" Starlink Enterprises (the Musk companies) as an "alternate Internet" where applications must use only the functions that Starlink supports (where other Internet providers may support broader standards or not support the special "Starlink-only" functions). This is a way to balkanize the Internet, and maybe Musk who loves Monopoly Power after all because it makes him more Powerful, sees that as a great thing. Certainly the Chinese Communist Party is trying hard to balkanize a Chinese-only Internet, spending a lot of money to block interoperability. Musk may envy China, I don't know.
If you want a Balkanized, non-interoperable Internet, where the carriers feel free to examine all the traffic and create their own, non-interoperable protocol set, I'd suggest China might be a good place to move. Or maybe Mars?
 
Now what's a powerful idea in the Internet (so far) is that what prevents bad ideas like this is that the Internet interprets such stupid ideas as damage, and routes around them. But to route around them, the Internet has to be overall, *interoperable*. 
 
There's no law, and no "cryptocurrency" like Ethereum that prevents bad ideas that destroy interoperability, in the Internet Architecture. Anyone can invent and deploy a new protocol, and you can invent new layer 2 transport technologies too. But I daresay we who built the Internet will make it very clear that anyone ought to "route around you" (including using you with a tunnal that you can't interfere with except by blocking all communications).
 
So, my recommendation: don't do such dumb things!
 

[-- Attachment #2: Type: text/html, Size: 7429 bytes --]