gitea on MacOS X (homebrew build) unable to resolve tailscale *.ts.net names #9930

New Issue

GiteaMirror · 2025-11-02T08:53:20-06:00

GiteaMirror commented

2025-11-02 08:53:20 -06:00

Originally created by @jum on GitHub (Dec 5, 2022).

Description

My Gitea instance on MacOS X (homebrew build) is unable to resolve tailscale *.ts.net names. I wanted to make internal hooks all reachable via the tailscale private net only, and allthough I am able to curl the hook URL successfully on the same host, the gitea binary build is not able to resolve that address.

Gitea Version

1.17.3

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

Delivery: Post "https://myhost.tailXXXXX.ts.net/giteahook": dial tcp: lookup myhost.tailXXXXX.ts.net on 192.168.178.1:53: no such host

Screenshots

Delivery: Post "https://myhost.tailXXXXX.ts.net/giteahook": dial tcp: lookup myhost.tailXXXXX.ts.net on 192.168.178.1:53: no such host

The IP number is the IP number of my DSL router, but I have also tailscale with magic DNS running, and all other services appear to pick name resolution via the OS X native DNS resolver to map the tailscale network.

Git Version

2.24.3 (Apple Git-128)

Operating System

MacOS X Catalina

How are you running Gitea?

I am running the homebrew build of gitea as a server via a launchd plist file.

Database

PostgreSQL

Originally created by @jum on GitHub (Dec 5, 2022). ### Description My Gitea instance on MacOS X (homebrew build) is unable to resolve tailscale *.ts.net names. I wanted to make internal hooks all reachable via the tailscale private net only, and allthough I am able to curl the hook URL successfully on the same host, the gitea binary build is not able to resolve that address. ### Gitea Version 1.17.3 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist Delivery: Post "https://myhost.tailXXXXX.ts.net/giteahook": dial tcp: lookup myhost.tailXXXXX.ts.net on 192.168.178.1:53: no such host ### Screenshots Delivery: Post "https://myhost.tailXXXXX.ts.net/giteahook": dial tcp: lookup myhost.tailXXXXX.ts.net on 192.168.178.1:53: no such host The IP number is the IP number of my DSL router, but I have also tailscale with magic DNS running, and all other services appear to pick name resolution via the OS X native DNS resolver to map the tailscale network. ### Git Version 2.24.3 (Apple Git-128) ### Operating System MacOS X Catalina ### How are you running Gitea? I am running the homebrew build of gitea as a server via a launchd plist file. ### Database PostgreSQL

GiteaMirror added the type/bug label 2025-11-02 08:53:20 -06:00

GiteaMirror closed this issue

2025-11-02 08:53:21 -06:00

GiteaMirror commented

2025-11-02 08:53:21 -06:00

@silverwind commented on GitHub (Dec 6, 2022):

Check if other golang applications can resolve, I imagine this is not an issue related to gitea application code, but golang dns resolution itself. also check MacOS's scutil --dns.

@silverwind commented on GitHub (Dec 6, 2022): Check if other golang applications can resolve, I imagine this is not an issue related to gitea application code, but golang dns resolution itself. also check MacOS's `scutil --dns`.

GiteaMirror commented

2025-11-02 08:53:22 -06:00

@jum commented on GitHub (Dec 6, 2022):

Check if other golang applications can resolve, I imagine this is not an issue related to gitea application code, but golang dns resolution itself. also check MacOS's scutil --dns.

I have checked it, and it appears to be an artefact of how the go binary is build. If cgo is disabled, the dns resolve fails. I made a small program that does a net.LookupHost on my tailnode of interest, and it works if enabled:

`
$ GODEBUG=netdns=go ./dnstest
Lookup anubis.tail6f5c6.ts.net: lookup anubis.tail6f5c6.ts.net on 192.168.178.1:53: no such host

$ GODEBUG=netdns=cgo ./dnstest
a: "100.105.227.119"
`

dnstest.go is a simple quick test:

`
package main

import (
"fmt"
"net"
"os"
)

const tailNode = "anubis.tail6f5c6.ts.net"

func main() {
addrs, err := net.LookupHost(tailNode)
if err != nil {
fmt.Fprintf(os.Stderr, "Lookup %v: %v\n", tailNode, err)
os.Exit(1)
}
for _, a := range addrs {
fmt.Printf("a: %#v\n", a)
}
}
`

So my question here: would it be possible to make the build homebrew uses cgo or do I have to build it myself?

@jum commented on GitHub (Dec 6, 2022): > Check if other golang applications can resolve, I imagine this is not an issue related to gitea application code, but golang dns resolution itself. also check MacOS's `scutil --dns`. I have checked it, and it appears to be an artefact of how the go binary is build. If cgo is disabled, the dns resolve fails. I made a small program that does a net.LookupHost on my tailnode of interest, and it works if enabled: ` $ GODEBUG=netdns=go ./dnstest Lookup anubis.tail6f5c6.ts.net: lookup anubis.tail6f5c6.ts.net on 192.168.178.1:53: no such host $ GODEBUG=netdns=cgo ./dnstest a: "100.105.227.119" ` dnstest.go is a simple quick test: ` package main import ( "fmt" "net" "os" ) const tailNode = "anubis.tail6f5c6.ts.net" func main() { addrs, err := net.LookupHost(tailNode) if err != nil { fmt.Fprintf(os.Stderr, "Lookup %v: %v\n", tailNode, err) os.Exit(1) } for _, a := range addrs { fmt.Printf("a: %#v\n", a) } } ` So my question here: would it be possible to make the build homebrew uses cgo or do I have to build it myself?

GiteaMirror commented

2025-11-02 08:53:22 -06:00

@techknowlogick commented on GitHub (Dec 6, 2022):

So my question here: would it be possible to make the build homebrew uses cgo or do I have to build it myself?

The build homebrew uses is built with CGO so that sqlite works, although netdns is overridden the tag netgo is set.

Not that it likely matters, but for debugging sake are you using an M1/2 device or an amd64 mac?

@techknowlogick commented on GitHub (Dec 6, 2022): > So my question here: would it be possible to make the build homebrew uses cgo or do I have to build it myself? The build homebrew uses is built with CGO so that sqlite works, although netdns is overridden the tag `netgo` is set. Not that it likely matters, but for debugging sake are you using an M1/2 device or an amd64 mac?

GiteaMirror commented

2025-11-02 08:53:22 -06:00

@jum commented on GitHub (Dec 6, 2022):

No, my gitea server is an old AMD64 mac mini stuck on Catalina.

@jum commented on GitHub (Dec 6, 2022): No, my gitea server is an old AMD64 mac mini stuck on Catalina.

GiteaMirror commented

2025-11-02 08:53:22 -06:00

@techknowlogick commented on GitHub (Dec 7, 2022):

Good news, I reached out to tailscale and they provided some insight. This is due to an interaction between go and macOS, but will be fixed in go 1.20. Depending on your timelines you may need to build Gitea with the alternate options until that version of go is released. I'll close this ticket now as there is nothing we can do except wait for the new go version to release.

Source: https://twitter.com/bradfitz/status/1600364606022889473

@techknowlogick commented on GitHub (Dec 7, 2022): Good news, I reached out to tailscale and they provided some insight. This is due to an interaction between go and macOS, but will be fixed in go 1.20. Depending on your timelines you may need to build Gitea with the alternate options until that version of go is released. I'll close this ticket now as there is nothing we can do except wait for the new go version to release. Source: https://twitter.com/bradfitz/status/1600364606022889473

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#9930