[Starlink] IXPs in space

[Ulrich Speidel]

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 at auckland.ac.nz  
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230417/6a98bea6/attachment-0001.html>