FullyQualifiedHostname: failed to reverse lookup this machin

Error message

FullyQualifiedHostname: failed to reverse lookup this machine's local IP (%v): %v

What it means

Step 3 of FullyQualifiedHostname reverse-resolves the machine's IP via net.LookupAddr to get the FQDN. This error means the reverse DNS lookup of the local IP failed (no PTR record or resolver failure).

Source

Thrown at go/netutil/netutil.go:84

	if err != nil {
		return "", fmt.Errorf("FullyQualifiedHostname: failed to retrieve the hostname of this machine: %v", err)
	}

	// 2. Look up the IP address for that hostname. Example: 127.0.0.1
	ips, err := net.LookupHost(hostname)
	if err != nil {
		return "", fmt.Errorf("FullyQualifiedHostname: failed to lookup the IP of this machine's hostname (%v): %v", hostname, err)
	}
	if len(ips) == 0 {
		return "", fmt.Errorf("FullyQualifiedHostname: lookup of the IP of this machine's hostname (%v) did not return any IP address", hostname)
	}
	// If multiple IPs are returned, we only look at the first one.
	localIP := ips[0]

	// 3. Reverse lookup the IP. Example: localhost.localdomain
	resolvedHostnames, err := net.LookupAddr(localIP)
	if err != nil {
		return "", fmt.Errorf("FullyQualifiedHostname: failed to reverse lookup this machine's local IP (%v): %v", localIP, err)
	}
	if len(resolvedHostnames) == 0 {
		return "", fmt.Errorf("FullyQualifiedHostname: reverse lookup of this machine's local IP (%v) did not return any hostnames", localIP)
	}
	// If multiple hostnames are found, we return only the first one.
	// If multiple hostnames are listed e.g. in an entry in the /etc/hosts file,
	// the current Go implementation returns them in that order.
	// Example for an /etc/hosts entry:
	//   127.0.0.1	localhost.localdomain localhost
	// If the FQDN isn't returned by this function, check the order in the entry
	// in your /etc/hosts file.
	return strings.TrimSuffix(resolvedHostnames[0], "."), nil
}

// FullyQualifiedHostnameOrPanic is the same as FullyQualifiedHostname
// but panics in case of an error.
func FullyQualifiedHostnameOrPanic() string {
	hostname, err := FullyQualifiedHostname()

View on GitHub (pinned to 01a25a7d17)

Solutions

Add a reverse entry in /etc/hosts: "10.0.0.5 tablet-1.example.com tablet-1"
Create a PTR record for the host's IP in your DNS server
Provide the fully-qualified hostname explicitly to Vitess instead of relying on reverse lookup (e.g. -hostname flag / tablet hostname field)
Verify with `dig -x <localIP>` or `nslookup <localIP>`

Example fix

// /etc/hosts, before
10.0.0.5 tablet-1
// after
10.0.0.5 tablet-1.example.com tablet-1

Defensive patterns

Strategy: fallback

Validate before calling

ip, err := net.LookupHost(os.Hostname())
if err == nil && len(ip) > 0 {
    if _, err := net.LookupAddr(ip[0]); err != nil {
        return fmt.Errorf("no PTR for %s: %v", ip[0], err)
    }
}

Try / catch

fqdn, err := netutil.FullyQualifiedHostname()
if err != nil {
    log.Warn("reverse DNS failed; set hostname explicitly", slog.Any("error", err))
    fqdn = cfg.ExplicitHostname // preconfigured value
}

Prevention

Create PTR records for all Vitess host IPs or add reverse entries in /etc/hosts
Prefer passing an explicit hostname (e.g. vttablet -hostname flag) in DNS-less environments
Monitor `dig -x <ip>` health in your cluster checks

When it happens

Trigger: FullyQualifiedHostname is called (directly or via FullyQualifiedHostnameOrPanic, backup, BuildTabletFromInput) on a host whose IP has no reverse DNS entry or whose resolver is unreachable.

Common situations: Cloud/private-network IPs without PTR records; DNS outage; /etc/hosts lacking a reverse mapping; using an IP like 127.0.0.1 that has no PTR in the environment.

Related errors

AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01). Data as JSON: /api/errors/ee6b35ae655f2744. Report an issue: GitHub.