[Bug 279618] getnameinfo - IPv6 problem
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 279618] getnameinfo - IPv6 problem"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 279618] getnameinfo - IPv6 problem"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 279618] getnameinfo - IPv6 problem"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 10 Jun 2024 00:24:14 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279618 Bug ID: 279618 Summary: getnameinfo - IPv6 problem Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: ipv6 Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: bz@FreeBSD.org 6cb9418289f90 introduced a special check on the first nibble of an in6_addr: + switch (sin6->sin6_addr.s6_addr[0]) { + case 0x00: If it doesn't fall into any of the two categories it will not attempt to do name resolution and lookup the PTR because it sets NI_NUMERICHOST. I cannot see why this "else" case was ever added (and someone should dig into the KAME archives to understand). Also someone should check if POSIX says anything beyond the RFC and fully understand what is supposed to go on. Addresses with the IPv6 DNS64 default prefix 64:ff9b::/96 such as 64:ff9b::4007:8d09 (zoo) will not be resolved and that does indeed break software (e.g. postfix in an ipv6-only setup behind a NAT64). Manually calling hp = getipnodebyaddr(&sin6.sin6_addr, sizeof(struct in6_addr), AF_INET6, &h_error); will result in the correct answer from an accordingly setup resolver. -- You are receiving this mail because: You are the assignee for the bug.