lib/60475: getaddrinfo should check both IPv4 and IPv6 before trying suffixes

["mayuresh%warunjikar.in@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60475
>Category:       lib
>Synopsis:       getaddrinfo should check both IPv4 and IPv6 before trying suffixes
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 22 10:00:00 +0000 2026
>Originator:     Mayuresh
>Release:        10.1 amd64
>Organization:
>Environment:
NetBSD warunjikar.in 10.1 NetBSD 10.1 (GENERIC) #0: Mon Dec 16 13:08:11 UTC 2024  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64 x86_64 Intel 686-class NetBSD
>Description:
The issue is fully discussed here:
https://mail-index.netbsd.org/netbsd-users/2026/07/21/msg034510.html

Summary:
When trying to resolve domainname github.com, the resolver looked for IPv6 first. But the domain does not support IPv6, no AAAA record. Then the resolver tried suffixing the domain name of the local host which is ".in". Hence it tried github.com.in, which is a different domain with AAAA record and this led to an incorrect resolution.

This can lead to serious security issues.
>How-To-Repeat:
Use tcpdump to monitor the DNS traffic.

Try pinging a non-existent domain or one with no IPv6 address.

Notice that if the given string does not yield results, it tries suffixing it with the domain name of the host.

If the domain name does not contain a dot, it tries the same string again, which is wasteful.
>Fix:
Post [1] has references to RFC 1535 that described the issue and links to the documentation of how Linux and FreeBSD address the issue.

Post [2] asserts that the behavior on NetBSD is in line is same as that described by the cited Linux documentation.

Post [3] reports that Linux attempts IPv4 and IPv6 first, before attempting to suffix the domain name, which is safer for the github.com scenario described.

[1] https://mail-index.netbsd.org/netbsd-users/2026/07/22/msg034538.html
[2] https://mail-index.netbsd.org/netbsd-users/2026/07/22/msg034539.html
[3] https://mail-index.netbsd.org/netbsd-users/2026/07/22/msg034544.html