Resolving .flycast over Wireguard

webmonarch · January 24, 2026, 11:27pm

I am doing something that I THINK should work, but hitting a wall.

TLDR: I cannot get flytest-hidden-flower-6590.flycast to resolve from my Mac over Wireguard.

Dockerfile

FROM busybox
WORKDIR /www
RUN echo "ok" > index.html
EXPOSE 8080
CMD ["httpd", "-f", "-p", "8080", "-h", "/www"]

fly.toml

# fly.toml app configuration file generated for flytest-hidden-flower-6590 on 2026-01-24T13:28:33-08:00
#
# See https://fly.io/docs/reference/configuration/ for information about how to use this file.
#

app = 'flytest-hidden-flower-6590'
primary_region = 'sjc'

[build]

[http_service]
  internal_port = 8080
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 1
  processes = ['app']

[[vm]]
  memory = '1gb'
  cpus = 1
  memory_mb = 1024

From a test machine in the same org:

(dns and curl resolves as expect)

# fly machine run --shell nicolaka/netshoot

8e476db7617918:~# dig flytest-hidden-flower-6590.internal AAAA

; <<>> DiG 9.20.10 <<>> flytest-hidden-flower-6590.internal AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9239
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;flytest-hidden-flower-6590.internal. IN	AAAA

;; ANSWER SECTION:
flytest-hidden-flower-6590.internal. 10	IN AAAA	fdaa:41:c7dd:a7b:4ec:2e29:1c7:2
flytest-hidden-flower-6590.internal. 10	IN AAAA	fdaa:41:c7dd:a7b:59f:c5ba:6e6a:2

;; Query time: 0 msec
;; SERVER: fdaa::3#53(fdaa::3) (UDP)
;; WHEN: Sat Jan 24 22:18:09 UTC 2026
;; MSG SIZE  rcvd: 190

8e476db7617918:~# dig flytest-hidden-flower-6590.flycast AAAA

; <<>> DiG 9.20.10 <<>> flytest-hidden-flower-6590.flycast AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30520
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;flytest-hidden-flower-6590.flycast. IN	AAAA

;; ANSWER SECTION:
flytest-hidden-flower-6590.flycast. 10 IN AAAA	fdaa:41:c7dd:0:1::2

;; Query time: 0 msec
;; SERVER: fdaa::3#53(fdaa::3) (UDP)
;; WHEN: Sat Jan 24 22:18:15 UTC 2026
;; MSG SIZE  rcvd: 125

8e476db7617918:~# curl flytest-hidden-flower-6590.internal:8080
ok
8e476db7617918:~# curl flytest-hidden-flower-6590.flycast
ok

From my Mac (via wireguard)

(.internal resolves, .flycast does not, but I can connect directly to the private ipv6 address)

➜  ~ dig flytest-hidden-flower-6590.internal AAAA

; <<>> DiG 9.10.6 <<>> flytest-hidden-flower-6590.internal AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52601
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;flytest-hidden-flower-6590.internal. IN	AAAA

;; ANSWER SECTION:
flytest-hidden-flower-6590.internal. 10	IN AAAA	fdaa:41:c7dd:a7b:4ec:2e29:1c7:2
flytest-hidden-flower-6590.internal. 10	IN AAAA	fdaa:41:c7dd:a7b:59f:c5ba:6e6a:2

;; Query time: 36 msec
;; SERVER: fdaa:41:c7dd::3#53(fdaa:41:c7dd::3)
;; WHEN: Sat Jan 24 15:24:33 PST 2026
;; MSG SIZE  rcvd: 190

➜  ~ dig flytest-hidden-flower-6590.flycast AAAA

; <<>> DiG 9.10.6 <<>> flytest-hidden-flower-6590.flycast AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19853
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;flytest-hidden-flower-6590.flycast. IN	AAAA

;; Query time: 13 msec
;; SERVER: fdaa:41:c7dd::3#53(fdaa:41:c7dd::3)
;; WHEN: Sat Jan 24 15:24:41 PST 2026
;; MSG SIZE  rcvd: 63

➜  ~ curl flytest-hidden-flower-6590.internal:8080
ok
➜  ~ curl flytest-hidden-flower-6590.flycast
curl: (6) Could not resolve host: flytest-hidden-flower-6590.flycast
➜  ~ curl \[fdaa:41:c7dd:0:1::2\]
ok

I guess I dont NEED it to resolve from my Mac, but it would be useful if possible. Thanks!

mayailurus · January 25, 2026, 12:51am

Hm… Yeah, that should work. It is responding from the right DNS server, which was my first guess at the problem—until I reached this part of your post, .

I would try fly dig flytest-hidden-flower-6590.flycast at this point. That will make the attempt over user-mode Wireguard, as opposed to the kernel-mode Wireguard that you’ve been using so far.

(As a side note, the flyctl proxy command is a lightweight alternative if all you need from the macOS side is occasional debugging, database seeding, management panel, etc.)

[It’s not obvious from the docs, but the remote_host argument can be any kind of address that the internal network understands, including .flycast.]

A few other classics that have worked for other people in the past (although they really shouldn’t be necessary):

Destroy the Wireguard peer and then re-create it in a different region.
Release the Flycast address and likewise re-create.
fly dig AAAA-native, as opposed to AAAA, which is a variant (sub-)mode advertized as “may be useful if diagnosing a DNS bug”.

Hope this helps a little!

webmonarch · January 25, 2026, 3:35am

Thanks @mayailurus that was the trick! Also thank you for the other helpful commands.

system · February 1, 2026, 3:36am

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