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.
E.g.
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?