I’ve just rolled out a preview version of the new DNS server for
fly.dev subdomains. It’s available at
<your-app-name>.preview.fly.dev, and it should work the same as the current
<your-app-name>.fly.dev, including TLS certificates.
Some background: we’ve had issues on and off with our current DNS provider (we currently make an API request to update records every time an IP address is added/removed from an app), and we were already keeping IP to app name mappings around on edge nodes for request routing, so it was easy to write a small DNS server in Rust to do the job instead
Let us know if you find any issues with the new DNS server, or if it’s returning responses differently than the current one.
Awesome! Is there any timeline for when the new DNS will be rolled out as the main DNS?
Will this also power the internal DNS?
P.S: you should add the announcement tag to your posts so they’re easier to find.
I did some quick testing, is there anything that needs to be done on our apps to enable this? For example, I spun up an app this morning and it does not seem to be available on the preview address.
https://fly-dns-test-ts.fly.dev/ works fine, https://fly-dns-test-ts.preview.fly.dev/ does not connect.
Checking the dig record, they both point to the same IP for the A record. Non-preview has a ttl of 5 minutes, preview has a ttl of 5 seconds.
When I run
curl -v to both, it appears to fail to connect to the preview version on the TLS handshake.
* Connected to fly-dns-test-ts.preview.fly.dev (126.96.36.199) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to fly-dns-test-ts.preview.fly.dev:443
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to fly-dns-test-ts.preview.fly.dev:443
I noticed similar issues on some apps I’ve been running for some time, some work fine, others have this issue. I’ve tested both from my home connection and from a gitpod container with the same results.
Hope this helps, please let me know if you need more info or testing.
Will this new DNS system support PTR records for users instances? I have a use case that would be easier with them
This already powers internal DNS, I just adapted it to also serve external DNS I can’t commit to a timeline, but we’ll roll it out once we sort out the bugs
Oh, thanks. I was trying to do that, but couldn’t find the tag at first…
This was a bug with shared IPs. I’ve just rolled out a fix (and also fixed the TTL, whoops). Thanks for the report!
PTR records are not planned at the moment, but could probably happen. What’s your use case?
Perfect thanks! I can confirm this corrects the issue with the app I noted, as well as the rest of the apps having issues. Thanks!
I am trying to run a rabbitmq cluster with dns based cluster formation. Rabbitmq required a PTR record to lookup nodes by name