#851388 IPv6 resolving broken

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:
#851388#5
Date:
2017-01-14 14:25:51 UTC
From:
To:
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

#851388#12
Date:
2017-01-15 06:55:13 UTC
From:
To:
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

#851388#19
Date:
2017-01-15 13:05:10 UTC
From:
To:
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

#851388#24
Date:
2017-01-15 14:20:27 UTC
From:
To:
[ 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.

#851388#29
Date:
2017-01-15 15:38:20 UTC
From:
To:
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