Deleting and recreating app with same name seems to have broken internal DNS

I recycled app names for cdna-cms and cdna-db and now the .internal DNS does not work for (at least cdna-cms). The apps are healthy and cdna-cms is available at fly dev.

Is there a way I can flush the DNS?

Is this still true? I just checked some hosts and it looks correct.

How long after you deleted the apps did this happen? DNS is eventually consistent, so it could take a few minutes. More than 10 would be weird, though.

If this happens again can you compare the results of:

fly ips private -a cdna-cms
fly dig aaaa cdna-cms.internal -a cnda-cms

Those two commands resolve to the same/correct ip.

When I curl with -v inside a container it’s resolving to the wrong IP. But maybe this is some DNS caching inside the container itself.


curl -v http://cdna-cms.internal:8080
*   Trying fdaa:0:78c0:a7b:2985:6483:a4cc:2:8080...
* connect to fdaa:0:78c0:a7b:2985:6483:a4cc:2 port 8080 failed: Connection refused
* Failed to connect to cdna-cms.internal port 8080: Connection refused
* Closing connection 0
curl: (7) Failed to connect to cdna-cms.internal port 8080: Connection refused

Where as the other commands are outputting: 2a09:8280:1::6:5c4e

I jump into another container on the same private network with the same command it also resolves to: fdaa:0:78c0:a7b:2985:6483:a4cc

I’m using curl instead of dig because these containers don’t have apk or dig, not sure if there is a better approach.

I think that IP is correct. Is the service within that app listening on IPv6 by chance?

I think so, the source isn’t mine, but from what I can tell by skimming it should be (I don’t have netstat on the container). Also fly ssh console isn’t connecting for me right now.

Connecting to top1.nearest.of.cdna-cms.internal…⡿

Would curling [::1] do the trick once I get an ssh connection again?

Ok I’m in, it is not listening on ipv6. Am I out of luck using the .internal DNS for this container without opening a PR to the project to listen on ipv6?