Skip Menu |

This queue is for tickets about the IO-Socket-INET6 CPAN distribution.

Report information
The Basics
Id: 55278
Status: new
Priority: 0/
Queue: IO-Socket-INET6

People
Owner: Nobody in particular
Requestors: luigi.lauro [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: IO-Socket-INET6 bug: incorrectly query "127.0.0.1" as a domain name against the local domain
Date: Sat, 6 Mar 2010 10:02:51 +0100
To: bug-IO-Socket-INET6 [...] rt.cpan.org
From: Luigi Lauro <luigi.lauro [...] gmail.com>
The actual bug lies in module IO::Socket::INET6 in sub configure. My nameserver entry in /etc/resolv.conf is 127.0.0.1 . The configure() is trying to figure out which protocol family to use, so it tries both, the AF_INET6, then AF_INET. Code near line 192 is: 192: @rres = getaddrinfo( 193: $raddr,$rport,$fam,$type,$proto,AI_PASSIVE 194: ); Since getaddrinfo is told to try AF_INET6 first but is given 0.0.0.0. and 127.0.0.1 as $raddr, it decides it is not an IPv6 address, and tries to resolve it! My DNS server is configured to resolve ANY *.mydomain to my external public IPv4/IPv6 addresses. So IO-Socket-INET6 query my external DNS server (which is NOT recursive, but only authoritative) instead of the given 127.0.0.1 and therefore fails. You can read about all the details here: http://www.mail-archive.com/users@spamassassin.apache.org/msg71672.html I think the best fix is treating 127.0.0.1, 0.0.0.0, ::1 as special cases and not trying to resolve them, but use them as IP (they are IP after all...). Afterall no one would ever use 127.0.0.1.mydomain.com or 0.0.0.0.mydomain.com as valid DNS names. -- Luigi Lauro
Subject: Re: [rt.cpan.org #55278] AutoReply: IO-Socket-INET6 bug: incorrectly query "127.0.0.1" as a domain name against the local domain
Date: Sat, 6 Mar 2010 10:09:10 +0100
To: bug-IO-Socket-INET6 [...] rt.cpan.org
From: Luigi Lauro <luigi.lauro [...] gmail.com>
On Sat, Mar 6, 2010 at 10:03, Bugs in IO-Socket-INET6 via RT <bug-IO-Socket-INET6@rt.cpan.org> wrote: Show quoted text
> > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: >        "IO-Socket-INET6 bug: incorrectly query "127.0.0.1" as a domain name  against the local domain", > a summary of which appears below. > > There is no need to reply to this message right now.  Your ticket has been > assigned an ID of [rt.cpan.org #55278].  Your ticket is accessible > on the web at: > >    https://rt.cpan.org/Ticket/Display.html?id=55278 > > Please include the string: > >         [rt.cpan.org #55278] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > >                        Thank you, >                        bug-IO-Socket-INET6@rt.cpan.org > > ------------------------------------------------------------------------- > The actual bug lies in module IO::Socket::INET6 in sub configure. > > My nameserver entry in /etc/resolv.conf is 127.0.0.1 . > > The configure() is trying to figure out which protocol family to use, > so it tries both, the AF_INET6, then AF_INET. Code near line 192 is: > > 192:  @rres = getaddrinfo( > 193:    $raddr,$rport,$fam,$type,$proto,AI_PASSIVE > 194:  ); > > Since getaddrinfo is told to try AF_INET6 first but is given 0.0.0.0. > and 127.0.0.1 > as $raddr, it decides it is not an IPv6 address, and tries to resolve it! > > My DNS server is configured to resolve ANY *.mydomain to my external > public IPv4/IPv6 addresses. > > So IO-Socket-INET6 query my external DNS server (which is NOT > recursive, but only authoritative) > instead of the given 127.0.0.1 and therefore fails. > > You can read about all the details here: > http://www.mail-archive.com/users@spamassassin.apache.org/msg71672.html > > I think the best fix is treating 127.0.0.1, 0.0.0.0, ::1 as special > cases and not trying to resolve them, but use them as IP (they are IP > after all...). > > Afterall no one would ever use 127.0.0.1.mydomain.com or > 0.0.0.0.mydomain.com as valid DNS names. > > -- > Luigi Lauro > >
-- Luigi Lauro