- Package:
- libnetaddr-ip-perl
- Source:
- libnetaddr-ip-perl
- Description:
- IP address manipulation module
- Submitter:
- Mike Gabriel
- Date:
- 2026-10-21 19:09:01 UTC
- Severity:
- important
- Tags:
Resolving DNS names to IPv6 addresses with NetAddr::IP->new6($hostname) fails and results in some IPv4'ish address with IPv6 syntax. ``` #!/usr/bin/perl use NetAddr::IP; my $hostname = "google-public-dns-a.google.com"; my $ip6 = NetAddr::IP->new6($hostname); my $ip4 = NetAddr::IP->new($hostname); print "$ip6 <- WTF???\n"; print "$ip4\n"; exit(0); ``` ... gives... ``` [mike@minobo ~]$ ./netaddr-ip_resolv-ipv6.pl 0:0:0:0:0:0:808:808/128 <- WTF??? 8.8.8.8/32 ``` This issues currently causes this upstream bug in UIF [1]. Greets, Mike https://github.com/cajus/uif/issues/2
In the mtpolicyd plugin for querying a spamassassin AWL database for reputation there is: lib/Mail/MtPolicyd/Plugin/SaAwlLookup.pm: my $addr = NetAddr::IP->new6( $ip.'/48' ); If I understand the bug correctly, then it's affected. Scott K
I don't think so.
The issue we're seeing is that resolving hostnames which have both an
IPv4 and IPv6 address fails. In this case here, the function
truncate_ip_v6 has the quoted line; $ip smells like an IP address and
not a hostname; truncate_ip_v6 is called from truncate_ip:
if( $ip =~ /:/) {
return $self->truncate_ip_v6($ip);
}
which called from query_awl:
my $ip_key = $self->truncate_ip( $ip );
which called from run():
my $ip = $r->attr('client_address');
..
sub { $self->query_awl( $addr, $ip ) } );
I don't think that $ip is a hostname in any of these functions.
Cheers.
gregor
[ The first address is in the "IPv4-Compatible IPv6 Address" format
(nowadays deprecated in favour of the "IPv4-Mapped IPv6 Address"
format), see https://tools.ietf.org/html/rfc4291#section-2.5.5 ]
FWIW it looks to me like this is more or less intentional behaviour.
From the documentation of the new6() method:
"->new6" and "->new_cis6" mark the address as being in ipV6
address space even if the format would suggest otherwise.
i.e. ->new6('1.2.3.4') will result in ::102:304
[...]
$addr can be any of the following and possibly more...
[..]
Fully Qualified Domain Name which returns an ipV4 address or an ipV6
address, embodied in that order.
This seems to match the code as well, see
http://sources.debian.net/src/libnetaddr-ip-perl/4.079%2Bdfsg-1/Lite/Lite.pm/#L1023
So it looks for an IPv4 address first as documented, and then makes an
IPv6 address out of that, again as documented. Of course, whether this
behaviour is useful/expected is another matter entirely (and I certainly
agree it's unexpected.)
As noted on IRC, I suspect you're better off doing the resolving step separately.
Hi, Personally, I feel that instatiating an IPv6 address object from a DNS host name should end up with the real IPv6 address of that host (i.e. what you find in AAAA records of the FQDN, after resolving all CNAME references). Everything else feels like bogus behaviour... Just my 2¢, Meanwhile, I implemented DNS resolution via Socket in UIF. So this issue is not bugging me that much anymore... Greets, Mike