SRV pointing to Argo Tunnel CNAME

I’ve created a tunnel, it works fine when using it as abc.example.com.

I’ve created an SRV record, _service._tcp.example.com with a value of 0 0 443 abc.example.com. Cloudflare UI warns that this ‘exposes the IP’, which it doesn’t, but it also doesn’t work.

When I dig -t SRV on the record I get something like: 0 0 443 dc-7c5b2d54f1d5.example.com. This domain does not have an A record, but does have a ULA AAAA record.

Is there a technical reason why a SRV shouldn’t be able to point to this tunnel?

I would think that if you did a lookup of that dc-xxxx record, you’d get an IP address, which is typically what happens when someone’s MX record points to a proxied hostname.

I’m sure it can point to it, but as for it working, I think tunnels only work over Port 7844.

I would think that if you did a lookup of that dc-xxxx record, you’d get an IP address

I would have thought that too. I expected the same IP I get when I look up the abc.example.com address itself. Alas it doesn’t seem to happen though. There’s no IP on the dc-xxxx record.

I’m sure it can point to it, but as for it working, I think tunnels only work over Port 7844.

Well the tunnel is working fine. Hitting abc.example.com on port 443 goes through the tunnel exactly as expected. It’s simply that the SRV can’t seem to point to it.

I personally can’t see any reason this shouldn’t work.

I don’t think this is caused by the Argo side of things, just the port being used in the SRV. You simply can’t have an SRV record pointing to a Cloudflare-proxied hostname on port 443 within the same domain (or at least this still didn’t work when I last tried - I check it from time to time). Multiple tickets and moaning about it on here hasn’t changed Cloudflare’s stance.

The only thing you can do is that there is nothing stopping you pointing to port 443 on an alternative Cloudflare proxied domain bizarrely. So if you owned example.com and example.org you could have an SRV on example.com pointing to sub.example.org. It’s not a soln by any means but it’s the only workaround that’s close to kind of working as you need.

2 Likes

Oh, wow I never would have guessed. It seems like such a common and simple use-case.

Thanks for the heads up on the cross-domain potential workaround.