TXT _instances.internal seemingly not containing all apps

[devpikachu]

Per the documentation, _instances.internal’s TXT record should contain

all addresses, apps, regions, and instances, comma separated

Interestingly, when doing a dig from my workstation through a WG tunnel, I only get information about one of the 2 apps under the organization:

[andrei@fedora template]$ dig +short txt _instances.internal @fdaa:2:8fc2::3
"instance=5683d5ddf79008,app=nats-dev,ip=172.19.132.90,region=otp;
instance=e2865956fe2318,app=nats-dev,ip=172.19.128.74,region=otp;
instance=9080401a513187,app=nats-dev,ip=172.19.129.74,region=otp"

NOTE: List manually wrapped for readability.

Initially I thought this was because the other app had scaled to zero, but all apps are scaled to zero. It seems that the instance for notify-dev is not showing up in this record.

My use-case is to leverage Fly’s DNS to perform autodiscovery for some cluster-level scale to zero / start on request.

I know that we’re already limited by the fact that most DNS entries contain no information after a machine is stopped, so my last hope was this TXT entry out of which to extract instance IDs, then use the API to send them a start signal.

Is this a bug, or is it intended behaviour?

[MatthewIngwersen]

Thanks for the report @devpikachu!

Only running machines should be reported.

It looks like there was a bug in our internal DNS server causing it to include some stopped machines (with their IPv4 addresses, rather than their 6PN IPv6 addresses) in the _instances.internal TXT record. We’ve fixed the bug and also updated our online documentation to clarify that only running machines are listed in that record.

Since you are already using the Machines API to start machines, would it be possible to use it to list/discover them (including stopped machines) as well?

[devpikachu]

@MatthewIngwersen Thanks for the reply and the quick fix!

Yep, using the API will be just fine for my use case.