[<prev] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251118160102.GR1827@brightrain.aerifal.cx>
Date: Tue, 18 Nov 2025 11:01:02 -0500
From: Rich Felker <dalias@...c.org>
To: Bing Hongtao <695097494plus@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: Behavior difference in hostname -f resolution with
IPv6-only /etc/hosts entries
On Tue, Nov 18, 2025 at 10:28:57PM +0800, Bing Hongtao wrote:
> Hi,
>
> I am writing to report a behavior discrepancy between musl libc and glibc
> regarding canonical hostname resolution (*hostname -f*), specifically when
> the local hostname is defined only with an IPv6 address in /etc/hosts.
>
> *Environment:*
>
> 1. Distro: Alpine Linux (Containerized environment)
> 2. Architecture: aarch64
> 3. musl version: 1.2.5
> 4. Network: IPv6-only / Missing IPv4 local entries
>
> *The Issue*: When running *hostname -f *inside a musl-based container: If
> */etc/hosts* does not contain an IPv4 entry for the current hostname (even
> if a valid IPv6 entry exists), the command fails completely with "Address
> not available".
>
> In contrast, glibc-based systems successfully resolve the FQDN using the
> existing IPv6 entry in */etc/hosts* without requiring an IPv4 entry.
>
>
> *Steps to Reproduce:*
> 1. Configure* /etc/hosts *to have only an IPv6 entry for this hostname,
> removing any IPv4 mapping for it.
>
> Example /etc/hosts:
> ```
> #127.0.0.1 localhost
> ::1 localhost ip6-localhost ip6-loopback
> fe00::0 ip6-localnet
> fe00::0 ip6-mcastprefix
> fe00::1 ip6-allnodes
> fe00::2 ip6-allrouters
> #10.88.101.228 test-pod
> 2001:db8:4860::65df test-pod
> ```
>
> 2. Run `hostname -f`
>
> *Observed Behavior (musl 1.2.5): *The command fails immediately.
> ```
> hostname: test-pod: Address not available
> ```
>
> *Strace Analysis: *The strace output shows the process reading */etc/hosts *and
> then exiting with status 1. It appears that the resolver specifically looks
> for an IPv4 address or fails to fall back/iterate correctly when *AF_INET*
> yields no results but valid *AF_INET6* entries exist.
> ```
> execve("/bin/hostname", ["hostname", "-f"], 0xffffe2ec1c58 /* 17 vars */) =
> 0
> set_tid_address(0xfdead8455e80) = 22
> brk(NULL) = 0xb6094620b000
> brk(0xb6094620d000) = 0xb6094620d000
> mmap(0xb6094620b000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
> -1, 0) = 0xb6094620b000
> mprotect(0xfdead8452000, 4096, PROT_READ) = 0
> mprotect(0xb60937abc000, 16384, PROT_READ) = 0
> getuid() = 0
> uname({sysname="Linux", nodename="test-pod", ...}) = 0
> openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> fcntl(3, F_SETFD, FD_CLOEXEC) = 0
> read(3, "# Kubernetes-managed hosts file."..., 1024) = 237
> read(3, "", 1024) = 0
> close(3) = 0
> write(2, "hostname: test-pod: Address not "..., 42hostname: test-pod:
> Address not available
> ) = 42
> exit_group(1) = ?
> +++ exited with 1 +++
> ```
>
> This issue creates compatibility problems in IPv6-only containerized
> environments (like Kubernetes IPv6 clusters) where applications relying on
> hostname -f fail unexpectedly on Alpine/musl images.
I think the concrete problem you're seeing has nothing to do with musl
but with the busybox version of the hostname utility, which is using
backwards ipv4-only interfaces to do the lookup. You could try
installing a more full-featured version of it, or reporting the bug to
busybox and Alpine in hopes of getting it fixed (I suspect Apline
would be more likely to expedite it).
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
