fly.dev dns records aren't being created

1

Stopped sometime today, anything I’m deploying says Visit your newly deployed app at https://<snip>.fly.dev/

but dig gives

; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;<snip>.fly.dev.          IN      A```

and cloudflare in front of the cname gives Error 1016, status 530
2

If i allocate a private ipv6 withflyctl ips allocate-v6 --private -a "${FLY_APP_NAME}", dig now returns an ip for the fly.dev domain (an ipv4 address)

Update: may have been unrelated. tried again on another app and it didnt fix it.

3

I also tried to deploy an app, and can’t seem to access it. The config I was using was working yesterday… is there any issues at DNS or proxy. To help: my app is ( gdcwa.fly.dev ).

4

I don’t see any errors or unexpected behaviour from fly.dev DNS. I also tried adding IPs to a test app and they are resolved correctly.

@elliots I can’t look at your app since you haven’t posted the app name. if you don’t want to share it publicly, email me at “myname at fly dot io” and I can take a look later.

@kaleng DNS is working correctly for your app, but it looks like you don’t have any ports set in your service config. maybe you want http_service instead App configuration (fly.toml) · Fly Docs

5

Ok, I think I’ve worked out whats going on.

I added a second service, with internal=true. Adding that means no shared ip is provisioned.

[http_service] (original service)
  force_https = false
  internal_port = 80
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 0
  max_machines_running = 1
  processes = ['app']

[[services]] (extra private one)
  internal_port = 8880
  protocol = "tcp"
  auto_stop_machines = "stop"
  auto_start_machines = true
  min_machines_running = 0
  max_machines_running = 1
  #  internal = true # not an actual config property, invented by chatgpt.

[[services.ports]]
  handlers = ["http"]
  port = 8880

Removing it i get

Provisioning ips for upowr-nextday
  Dedicated ipv6: 2a09:8280:1::65:9bb4:0
  Shared ipv4: 66.241.125.90
  Add a dedicated ipv4 with: fly ips allocate-v4

and the domain can now be resolved.

If i add the second service and deploy again, everything is fine. (so when i’d updated a previous app it kept working, hence thinking there was an issue with new apps)

With the new app, no errors or prompts were coming up (because this is called from ci, not interactive).

When running locally it prompts with ? Would you like to allocate dedicated ipv4 and ipv6 addresses now? which, no I don’t want a dedicated ipv4, just the shared one.

This is one from yesterday - upowr-morespace.fly.dev (didnt work)
This is one from today - upowr-nextday.fly.dev (removed the second internal service, deployed, added it back, deployed again, now working)

6

Right, services don’t work like that - all services will be available to all IP addresses on the app. Not sure what internal = true does, it doesn’t seem to be documented :thinking:

I’m not 100% on the fly deploy flow, but you might want to try fly ips list, then fly ips allocate-v4 --shared. It’s likely fly deploy is failing to prompt in CI because there is no terminal to reply on.

7

The internal: true was clearly hallucinated by an llm, sorry! I’ll protect the internal endpoints another way.

So, the issues i can see are:

  • Adding the extra service prevents ips being allocated automatically
  • In CI/non-interactive, there is no error and no prompt
  • Without ips, it still says the cname is there in the log output and in the dashboard

I’ll allocate the ips i need during deploy.

8

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.