lookup tailscale-operator-testing.tail0225ab.ts.net on 127.0.0.53:53: no such host;

[jameslamini]

1. From github action Run tailscale/github-action@v2 with: oauth-client-id: *** oauth-secret: *** tags: tag:ci

kubeconfig configured for "tailscale-operator-testing"

helm upgrade --install persistent-test ./persistent-test
--namespace testing
--set database.enabled=true
--wait
--timeout=2m
--debug

Error: Kubernetes cluster unreachable: Get "https://tailscale-operator-testing.tail0225ab.ts.net/version": dial tcp: lookup tailscale-operator-testing.tail0225ab.ts.net on 127.0.0.53:53: no such host

This was working earlier today.

2. Kubectl with the same command is fine when running from local machine: tailscale configure kubeconfig tailscale-operator-testing kubeconfig configured for "tailscale-operator-testing" helm upgrade --install persistent-test ./persistent-test --namespace testing --set database.enabled=true --wait --timeout=2m --debug

Release "persistent-test" has been upgraded. Happy Helming! NAME: persistent-test LAST DEPLOYED: Wed Apr 9 17:32:32 2025 NAMESPACE: testing STATUS: deployed REVISION: 48 TEST SUITE: None

[cmentzer]

Hey! Also seeing this.

error looking up IP of "<tailscale managed DNS record>": lookup <tailscale managed DNS record> on 127.0.0.53:53: no such host

Looking at the resolv.conf file in the hosted github runner:

Run echo "resolv.conf"
resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.[53](https://github.com/headway/chart-review-service/actions/runs/14387070134/job/40345022859#step:8:54)
options edns0 trust-ad
search tjh4lp41keku1akg0120f5foxa.bx.internal.cloudapp.net

I would expect this to work, I believe it works locally via tailscale managed entries in resolv.conf looks like maybe tailscale installed on a hosted github runner isn't properly overriding resolv.conf?

[cmentzer]

Update - we updated our github action to use ubuntu-latest instead of ubuntu 22.04 for the runs-on parameter in the runner configuration, and now it seems to be working? not sure if you can try to replicate and circle back, but at the least we see the correct entries in resolv.conf now.

@jameslamini

[jameslamini]

@cmentzer

We just tried again and still received the same error.

Unable to connect to the server: dial tcp: lookup tailscale-operator-testing.tail0225ab.ts.net on 127.0.0.53:53: no such host

For reference, we had used a workaround, TS_DEBUG_FIREWALL_MODE: "nftables", per suggestion:

uses: tailscale/github-action@v3 with: oauth-client-id: ${{ secrets.TS_OAUTH_CLIENT_ID }} oauth-secret: ${{ secrets.TS_OAUTH_SECRET }} tags: tag:ci env: TS_DEBUG_FIREWALL_MODE: "nftables"

relates to https://github.com/tailscale/tailscale/issues/13863

[matanbaruch]

@cmentzer

We just tried again and still received the same error.

Unable to connect to the server: dial tcp: lookup tailscale-operator-testing.tail0225ab.ts.net on 127.0.0.53:53: no such host

For reference, we had used a workaround, TS_DEBUG_FIREWALL_MODE: "nftables", per suggestion:

uses: tailscale/github-action@v3 with: oauth-client-id: ${{ secrets.TS_OAUTH_CLIENT_ID }} oauth-secret: ${{ secrets.TS_OAUTH_SECRET }} tags: tag:ci env: TS_DEBUG_FIREWALL_MODE: "nftables"

relates to https://github.com/tailscale/tailscale/issues/13863

Thanks that really helped. I did TS_DEBUG_FIREWALL_MODE: "auto" so it can auto detect the firewall.

I didn't saw anything regarding this on Gitub Runner release. Looks like ubuntu-latest and all ARM64 flavor still using iptables. But Larger runners are not.

[oxtoacart]

@jameslamini I'm curious if you still see this problem with v4 of the GitHub Action? If yes, I'm curious if your tailscale status output shows the machine to which you're trying to connect.