musl - Behavior difference in hostname -f resolution with IPv6-only /etc/hosts entries

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFJkf0Xz8emL_xg8idOZPdFTVb1N3EmCABXvA5w6uPPFt7DuKw@mail.gmail.com>
Date: Tue, 18 Nov 2025 22:28:57 +0800
From: Bing Hongtao <695097494plus@...il.com>
To: musl@...ts.openwall.com
Subject: Behavior difference in hostname -f resolution with IPv6-only
 /etc/hosts entries

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.

Content of type "text/html" skipped

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.