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

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

[Bing Hongtao]

[-- Attachment #1: Type: text/plain, Size: 2756 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3295 bytes --]

Re: [musl] Behavior difference in hostname -f resolution with IPv6-only /etc/hosts entries

[Rich Felker]

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