TAKy and DNS
Server observations
I started playing with the TAK ecosystem( https://www.civtak.org/ ) with ATAK and iTAK on user devices. For the server component I've been utilizing TAKy( https://github.com/tkuester/taky ). So far its been working out great.
The setup guides for TAKy and other TAK servers are focused on the public IP address of the server you're setting up. In many cases though, you won't really have a public IP address to give the setup wizard. Things like hosting it on a consumer internet connection where you only get a DHCP address from the ISP make it a problem. But also how you choose to implement it via bare metal, Virtual Machines or Containers, there isn't a public IP address in scope to give the setup wizard.
I moved forward with TAKy on an internal VM and got that working and started connecting ATAK/iTAK clients that were already on my internal network. Everything worked as expected. As I used the onboarding/setup Datapackages( TAK term ) to get a client connected, I poked into the zip file to find a manifest. As part of this manifest it tells clients where the server is, and right there is the “public IP” the setup wizard was asking about.
TAKy is a pretty small server implementation for TAK, this was part of the reason I choose it. Its also implemented in python and is open source, so it was easy to go take a look at things. I found that the configuration file for TAKy is just a simple .ini type file. Further, the “public_ip” field ONLY gets used for making that onboarding manifest file, its never used internally for TAK server functionality.
So, I just tried putting in a DNS name for “public_ip” in the configuration file and restarted. Everything still functioned just fine. Even modifying an existing ATAK client server settings with the DNS name still worked just fine. I then created an onboarding datapackage for a brand new client and indeed, the manifest file included the DNS name instead of an IP address. Passing this onboarding datapackage to a friend worked flawlessly as well.
So, in fact, TAKy can use a DNS name for the public ip instead of a literal IP address. This simplifies hosting & infrastructure concerns. I'm not sure how this would effect other TAK server implementations.
Client DNS Observation
ATAK on an android device has been working great during several testing sessions. However, I noticed one interesting thing. It appears that ATAK( the program ) only makes up a single DNS query on startup. What ever IP address comes back as part of the response is cached internally for the duration of the program run and through connect/reconnect cycles to the server.
Normally, this is a good thing, less network traffic & noise. However when a client moves networks and the DNS response changes, this is a problem.
When my client moves from home WiFi to LTE, the IP response for the DNS changes from and internal IP address to the public facing WAN address. If I start ATAK while I'm connected to home WiFi, it gets the DNS response for the internal IP address of my TAKy hosting. As soon as I move to the LTE network, this no longer is valid and while ATAK tries to reconnect periodically, it never performs a DNS lookup to get the latest response. Thus, my ATAK client always shows offline. The same occurs if I start on LTE and move to home WiFi.
Note: this only occurs for me since I'm hosting the TAKy server. ATAK clients that are never on MY home WiFi have this issue and they can roam between LTE and THEIR home WiFi with out issue. This is because the DNS response while on LTE and on THEIR home Wifi is always the same.
Work around
If you go into the Settings of the ATAK client and disable( with the check box ) the server connection and then enable the connection, ATAK will perform another DNS query and get an updated response for the IP address of the TAKy server. This will then restore connectivity while on the LTE network.