fly wireguard - not sure how to properly query DNS

1

Hi,

I’ve created a wireguard peer, and am connected:

8: fly0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet6 fdaa:0:4da4:a7b:ce2:0:a:302/120 scope global
       valid_lft forever preferred_lft forever


> ip -6 r | grep fly0
fdaa:0:4da4:a7b:ce2:0:a:300/120 dev fly0 proto kernel metric 256 pref medium
fdaa:0:4da4::/48 dev fly0 metric 1024 pref medium

Yet, using the query [from the Private Networking docs]:

> dig +short txt _peer.internal @fdaa:0:18::3
;; UDP setup with fdaa:0:18::3#53(fdaa:0:18::3) for _peer.internal failed: network unreachable.
;; no servers could be reached

;; UDP setup with fdaa:0:18::3#53(fdaa:0:18::3) for _peer.internal failed: network unreachable.
;; no servers could be reached

;; UDP setup with fdaa:0:18::3#53(fdaa:0:18::3) for _peer.internal failed: network unreachable.
;; no servers could be reached

Am I doing something wrong? I’m not sure why I’m getting network unreachable unless the subnet for fly0 is wrong… but that’s coming from flyctl… so… I’m a bit confused.

3

Wait, but this works? How? Does systemd-resolved try all the servers it thinks it might be able to query? My main internet interface obviously is not configured for Fly’s DNS.

> dig +noall +answer _apps.internal txt
_apps.internal.         5       IN      TXT     "redact1,redact2,..."
4

So…

> dig +noall +answer tube-colemickens._peer.internal aaaa @fdaa:0:4da4::3
tube-colemickens._peer.internal. 5 IN   AAAA    fdaa:0:4da4:a7b:ce2:0:a:102

fdaa:0:4da4::3 != fdaa:0:18::3

Are the docs wrong, or is my reading comprehension failing me again?

EDIT: While I’m here, is it possible the fly-instance local DNS IP is wrong too? Because I’m also investigating DNS failures from the box when using fdaa:0:18::3 as documented. fdaa::3 didn’t work either… :confused: ([fdaa::3] is working from inside a fly instance)

really feels like the documentation is wrong here, or I’m missing something big.

5

@colemickens-ds I think that fdaa:0:18::3 is just a stand-in example address. What the docs are trying to say (perhaps without being clear enough!) is that you should find the DNS= line in the WireGuard configuration that was generated for you, and then use whatever address you find there. For your organization (as you’ve found), it looks like that’s fdaa:0:4da4::3.

If this works, then I suspect that your system automatically installed the name server listed in the DNS= line when the WireGuard interface was configured. (IIRC, wg-quick does this.)

Hope this helps!

1 Like
6

Thanks @MatthewIngwersen, appreciate the fast helpful replies over the past week. It’s really great that Fly has this WireGuard infrastructure in place. I’ve used it to build a “'cloudflare(d) tunnel”-lite using Caddy and it’s automatic dynamic ACME support. Our developers can now create a fly wireguard peer, and magically a new set of subdomains become accessible via Caddy, complete with TLS.

It’s 97% generic over any Fly customer (though it has one “hard-coded” thing for the exact subdomain structure we use). It uses Caddy’s on_demand_tls like this:

https://*.*.redact.redact.redact.redact:443 {
	tls {
		on_demand
	}
	reverse_proxy {
		dynamic a {
			# note: labels are indexed right-to-left, from 0
			name tube-{labels.4}._peer.internal
			port 9090
			versions ipv6
		}
	}
}

There’s a bit more magic I layered on to translate Caddy’s on_demand_tls "ask" mechanism to a request that rrda can handle (effectively doing a DNS check via HTTP), so that this magic endpoint doesn’t become an ACME abuse vector. Now only certain subdomains, on another subdomain that is a valid fly wg peer names may get an ACME cert.

This gives us a “cloudflare tunnel” without needing Cloudflare. Built on top of Fly’s peer+key management.

1 Like
7

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