Fly-managed ACME challenge target returns authoritative NXDOMAIN

Questions / Help
1

I’m having an issue provisioning a Fly-managed certificate for a custom domain.

Fly asks me to configure an ACME CNAME similar to:

_acme-challenge.<subdomain> → <hostname>.<fly-app-id>.flydns.net

The CNAME is configured correctly and resolves publicly to the exact target shown by Fly.

However, querying Fly’s authoritative DNS directly for the generated target:

dig @ns1.flydns.net <hostname>.<fly-app-id>.flydns.net TXT

returns:

status: NXDOMAIN

As a control test, I have another Fly app/custom domain whose certificate provisioned successfully. Performing the same authoritative query against that app’s generated flydns.net target returns the expected ACME TXT value.

I also deleted and recreated only the failing custom hostname/certificate request. Fly generated the same validation target again, and that target still returns authoritative NXDOMAIN.

Public DNS for the required CNAME and ownership TXT records has been verified independently.

Is there a way to force Fly to reprovision the ACME challenge target, or could this indicate a problem with the Fly-managed DNS entry associated with this certificate request?

4

Hi, when did you configure the _acme-challenge record?

I tested on a well-known public DNS and I see the record you created, but on my ISP’s DNS it’s not there yet, so it looks like this is simply a propagation delay.

5

Hi, thanks for checking.

The _acme-challenge CNAME was initially configured several hours ago. I also deleted and recreated the Fly certificate request later during troubleshooting, but Fly generated the same CNAME target again.

I can confirm the CNAME itself is resolving correctly through public resolvers such as 1.1.1.1.

The part that made me suspect this may be more than propagation is that I queried Fly’s authoritative DNS directly for the generated target:

dig @ns1.flydns.net <generated-target>.flydns.net TXT

and received an authoritative NXDOMAIN.

For comparison, performing the same query against the generated target for my working Fly certificate returns its ACME TXT value directly from ns1.flydns.net.

I’m happy to wait if propagation is still expected here. Is the generated flydns.net TXT record also subject to propagation/provisioning delay on Fly’s side, and roughly how long would you recommend waiting before checking again?

6

Hi, can you check if the generated target you set up in your DNS provider (the target for the CNAME) has a typo? I’m seeing an error on my side indicating there may be a typo. If you typed it by hand I recommend copypasting it to avoid typos.

7

Thanks. I checked the generated target again and compared it directly with the record currently configured at my DNS provider.

Fly displays:
api.dancefinder.app.kjlkomg.flydns.net.

The CNAME at the DNS provider is:
api.dancefinder.app.kjlkomg.flydns.net

So they match exactly; the only visual difference is the trailing DNS root dot.

The record is also configured as DNS-only, and the equivalent ACME CNAME for another Fly app on the same domain is configured the same way and successfully provisioned.

Could you check what specific typo/error your side is reporting for the generated target?

8

Hi David,

On our end, we’re seeing:

```

dns verification incorrect: <target.domain>.app.kjlkomg.flydns.net, <target.domain>.app.kj1komg.flydns.net.

```

it’s an easy typo to make depending on your font–the second value is what we want to see for the ACME challenge. Can you retry and let us know if that does the trick?