#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.

 

#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/
****************************************************************