Skip Menu |

This queue is for tickets about the Net-DNS CPAN distribution.

Report information
The Basics
Id: 114351
Status: resolved
Priority: 0/
Queue: Net-DNS

People
Owner: Nobody in particular
Requestors: bjornr [...] isnic.is
Cc:
AdminCc:

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



CC: bug-Net-DNS [...] rt.cpan.org
Subject: p5-Net-DNS 1.05 problems
Date: Thu, 12 May 2016 15:43:20 +0000 (GMT)
To: mat [...] FreeBSD.org
From: Björn Róbertsson <bjornr [...] isnic.is>
Hi, after upgrading p5-Net-DNS the resolver->nameservers breaks on a lot of nameservers i.e. unresolvable name: ns02.CENTRALNETPOINT.COM My code piece has : $domain_checks::resolver->nameservers($_ns); I have downgraded p5-Net-DNS downgraded: 1.05_1,1 -> 1.02,1 - in order to bypass this. Regards, Björn Róbertsson ISNIC
From: rwfranks [...] acm.org
On Thu May 12 11:43:38 2016, bjornr@isnic.is wrote: Show quoted text
> Hi, > > after upgrading p5-Net-DNS the resolver->nameservers breaks on a lot > of nameservers > > i.e. > > unresolvable name: ns02.CENTRALNETPOINT.COM > > My code piece has : $domain_checks::resolver-
> >nameservers($_ns);
> > I have downgraded p5-Net-DNS downgraded: 1.05_1,1 -> 1.02,1 - in order > to bypass this. > > Regards, > Björn Róbertsson > ISNIC
What exactly are you claiming here? Running this code: use Net::DNS; print 'Net::DNS ', Net::DNS->version, "\n"; my $resolver = Net::DNS::Resolver->new(); my $name = 'ns02.CENTRALNETPOINT.COM'; $resolver->nameservers($name); my @ip = $resolver->nameservers(); print "$name\t@ip\n"; produces: Net::DNS 1.01 ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 Net::DNS 1.02 ns02.CENTRALNETPOINT.COM 83.169.55.96 217.160.113.155 Net::DNS 1.03 ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 Net::DNS 1.04 ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 Net::DNS 1.05 ns02.CENTRALNETPOINT.COM 83.169.55.96 217.160.113.155 Net::DNS 1.0506 ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96
Subject: Re: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems
Date: Thu, 19 May 2016 15:28:25 +0000 (GMT)
To: bug-Net-DNS [...] rt.cpan.org
From: Björn Róbertsson <bjornr [...] isnic.is>
Hello, I am sorry I will try to clarify. We're running FreeBSD 10.[123] with two local resolvers. We're running a perl application which fails after upgrading p5-Net-DNS from 1.02 to 1.05 I looked in the code and the error message is only returned from this particular portion (->nameservers). Consecutive runs of the code your provided with p5-Net-DNS 1.05: Net::DNS 1.05 unresolvable name: ns02.CENTRALNETPOINT.COM at resolve.pl line 8. ns02.CENTRALNETPOINT.COM Net::DNS 1.05 ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 Net::DNS 1.05 unresolvable name: ns02.CENTRALNETPOINT.COM at resolve.pl line 8. ns02.CENTRALNETPOINT.COM Net::DNS 1.05 unresolvable name: ns02.CENTRALNETPOINT.COM at resolve.pl line 8. ns02.CENTRALNETPOINT.COM Net::DNS 1.05 unresolvable name: ns02.CENTRALNETPOINT.COM at resolve.pl line 8. ns02.CENTRALNETPOINT.COM Net::DNS 1.05 unresolvable name: ns02.CENTRALNETPOINT.COM at resolve.pl line 8. ns02.CENTRALNETPOINT.COM Net::DNS 1.02 ns02.CENTRALNETPOINT.COM 83.169.55.96 217.160.113.155 Net::DNS 1.02 ns02.CENTRALNETPOINT.COM 83.169.55.96 217.160.113.155 Net::DNS 1.02 (and multiple repeated successful runs... never a failure) Our local resolvers run bind910-9.10.3P4, looking at the query-log we see: p5-Net-DNS 1.05 log lines from our local resolver: 19-May-2016 15:16:41.589 client IP#34390 (ns02.CENTRALNETPOINT.COM.isnic.is): query: ns02.CENTRALNETPOINT.COM.isnic.is IN AAAA + (193.4.58.93) 19-May-2016 15:16:41.842 client IP#45586 (ns02.CENTRALNETPOINT.COM): query: ns02.CENTRALNETPOINT.COM IN A + (193.4.58.93) 19-May-2016 15:16:41.845 client IP#41490 (ns02.CENTRALNETPOINT.COM): query: ns02.CENTRALNETPOINT.COM IN AAAA + (193.4.58.93) 19-May-2016 15:16:41.848 client IP#57647 (ns02.CENTRALNETPOINT.COM.isnic.is): query: ns02.CENTRALNETPOINT.COM.isnic.is IN AAAA + (193.4.58.93) ---- and the downgrade on the client p5-Net-DNS with 1.02 ---- p5-Net-DNS 1.02 log lines from our local resolver: 19-May-2016 15:18:33.955 client IP#47520 (ns02.CENTRALNETPOINT.COM): query: ns02.CENTRALNETPOINT.COM IN A + (193.4.58.93) 19-May-2016 15:18:33.958 client IP#40112 (ns02.CENTRALNETPOINT.COM): query: ns02.CENTRALNETPOINT.COM IN AAAA + (193.4.58.93) 19-May-2016 15:18:34.802 client IP#42436 (ns02.CENTRALNETPOINT.COM): query: ns02.CENTRALNETPOINT.COM IN A + (193.4.58.93) 19-May-2016 15:18:34.805 client IP#36431 (ns02.CENTRALNETPOINT.COM): query: ns02.CENTRALNETPOINT.COM IN AAAA + (193.4.58.93) The only change on the client machine is the 1.05 -> 1.02 It appears like the search path is appended to some queries, and then cached, if you use 1.05. Kind regards, Björn Show quoted text
----- Original Message -----
> From: "Dick Franks via RT" <bug-Net-DNS@rt.cpan.org> > To: bjornr@isnic.is > Sent: Friday, 13 May, 2016 7:22:03 PM > Subject: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems > > <URL: https://rt.cpan.org/Ticket/Display.html?id=114351 > > > On Thu May 12 11:43:38 2016, bjornr@isnic.is wrote:
> > Hi, > > > > after upgrading p5-Net-DNS the resolver->nameservers breaks on a lot > > of nameservers > > > > i.e. > > > > unresolvable name: ns02.CENTRALNETPOINT.COM > > > > My code piece has : $domain_checks::resolver-
> > >nameservers($_ns);
> > > > I have downgraded p5-Net-DNS downgraded: 1.05_1,1 -> 1.02,1 - in order > > to bypass this. > > > > Regards, > > Björn Róbertsson > > ISNIC
> > What exactly are you claiming here? > > Running this code: > > use Net::DNS; > print 'Net::DNS ', Net::DNS->version, "\n"; > > my $resolver = Net::DNS::Resolver->new(); > > my $name = 'ns02.CENTRALNETPOINT.COM'; > > $resolver->nameservers($name); > > my @ip = $resolver->nameservers(); > > print "$name\t@ip\n"; > > produces: > > Net::DNS 1.01 > ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 > > Net::DNS 1.02 > ns02.CENTRALNETPOINT.COM 83.169.55.96 217.160.113.155 > > Net::DNS 1.03 > ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 > > Net::DNS 1.04 > ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 > > Net::DNS 1.05 > ns02.CENTRALNETPOINT.COM 83.169.55.96 217.160.113.155 > > Net::DNS 1.0506 > ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 > > >
Subject: Re: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems
Date: Thu, 19 May 2016 15:42:56 +0000 (GMT)
To: bug-Net-DNS [...] rt.cpan.org
From: Björn Róbertsson <bjornr [...] isnic.is>
And for the different versions, it's from 1.03: Net::DNS 1.03 unresolvable name: ns02.CENTRALNETPOINT.COM at resolve.pl line 8. ns02.CENTRALNETPOINT.COM Net::DNS 1.04 unresolvable name: ns02.CENTRALNETPOINT.COM at resolve.pl line 8. ns02.CENTRALNETPOINT.COM Net::DNS 1.02 ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 Kind Regards, Björn Show quoted text
----- Original Message -----
> From: "Dick Franks via RT" <bug-Net-DNS@rt.cpan.org> > To: bjornr@isnic.is > Sent: Friday, 13 May, 2016 7:22:03 PM > Subject: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems > > <URL: https://rt.cpan.org/Ticket/Display.html?id=114351 > > > On Thu May 12 11:43:38 2016, bjornr@isnic.is wrote:
> > Hi, > > > > after upgrading p5-Net-DNS the resolver->nameservers breaks on a lot > > of nameservers > > > > i.e. > > > > unresolvable name: ns02.CENTRALNETPOINT.COM > > > > My code piece has : $domain_checks::resolver-
> > >nameservers($_ns);
> > > > I have downgraded p5-Net-DNS downgraded: 1.05_1,1 -> 1.02,1 - in order > > to bypass this. > > > > Regards, > > Björn Róbertsson > > ISNIC
> > What exactly are you claiming here? > > Running this code: > > use Net::DNS; > print 'Net::DNS ', Net::DNS->version, "\n"; > > my $resolver = Net::DNS::Resolver->new(); > > my $name = 'ns02.CENTRALNETPOINT.COM'; > > $resolver->nameservers($name); > > my @ip = $resolver->nameservers(); > > print "$name\t@ip\n"; > > produces: > > Net::DNS 1.01 > ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 > > Net::DNS 1.02 > ns02.CENTRALNETPOINT.COM 83.169.55.96 217.160.113.155 > > Net::DNS 1.03 > ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 > > Net::DNS 1.04 > ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 > > Net::DNS 1.05 > ns02.CENTRALNETPOINT.COM 83.169.55.96 217.160.113.155 > > Net::DNS 1.0506 > ns02.CENTRALNETPOINT.COM 217.160.113.155 83.169.55.96 > > >
Subject: Re: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems
Date: Thu, 19 May 2016 16:05:20 +0000 (GMT)
To: bug-Net-DNS [...] rt.cpan.org
From: Björn Róbertsson <bjornr [...] isnic.is>
And continuing, I've downgraded the bind resolver from 9.10 to 9.9 and then I've found this: If the cache is returning a particular match of upper/lower: Net::DNS 1.05 unresolvable name: ns02.centralnetpoint.com at resolve.pl line 8. ns02.centralnetpoint.com but: host ns02.centralnetpoint.com ns02.CENTRALNETPOINT.com has address 83.169.55.96 ns02.CENTRALNETPOINT.com has address 217.160.113.155 and we change the test: Net::DNS 1.05 ns02.CENTRALNETPOINT.com 217.160.113.155 83.169.55.96 voila! Is the p5-Net-DNS changed from 1.03 to compare the strings before and after, and resolvers which return cached searches, with different case strings cause it to fail? Anyway, named.conf option to bypass this behavious and get successful DNS requests all the time is: no-case-compress { any; }; This discussion can be found on the bind users list with the heading: BIND started replying to queries for .com with .COM Kind regards, Björn (p.s. sorry for the many mails)
From: rwfranks [...] acm.org
On Thu May 19 12:05:33 2016, bjornr@isnic.is wrote: Show quoted text
> And continuing, I've downgraded the bind resolver from 9.10 to 9.9 and > then I've found this: If the cache is returning a particular match of > upper/lower: > > > > Net::DNS 1.05 > unresolvable name: ns02.centralnetpoint.com at resolve.pl line 8. > ns02.centralnetpoint.com > > but: > > host ns02.centralnetpoint.com > ns02.CENTRALNETPOINT.com has address 83.169.55.96 > ns02.CENTRALNETPOINT.com has address 217.160.113.155 > > and we change the test: > > Net::DNS 1.05 > ns02.CENTRALNETPOINT.com 217.160.113.155 83.169.55.96 > > voila! > > Is the p5-Net-DNS changed from 1.03 to compare the strings before and > after, and resolvers which return cached searches, with different case > strings cause it to fail?
Please can you boil your script down to a _small_ and convincing example using nameservers in the global internet, so that we can attempt to repeat your observations free of any influence from your local BIND configuration.
Subject: Re: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems
Date: Fri, 20 May 2016 18:11:01 +0000 (GMT)
To: bug-Net-DNS [...] rt.cpan.org
From: Björn Róbertsson <bjornr [...] isnic.is>
Hello, The test program: #!/usr/local/bin/perl use Net::DNS; print 'Net::DNS ', Net::DNS->version, "\n"; my $resolver = Net::DNS::Resolver->new(); my $name = $ARGV[0]; $resolver->nameservers($name); my @ip = $resolver->nameservers(); print "$name\t@ip\n"; Test 1: Using the Google resolver 8.8.8.8: [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.com Net::DNS 1.02 ns1.ipage.com 66.96.142.163 66.96.142.162 66.96.142.116 [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.com Net::DNS 1.05 ns1.ipage.com 66.96.142.163 66.96.142.116 66.96.142.162 [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.COM Net::DNS 1.05 ns1.ipage.COM 66.96.142.163 66.96.142.116 66.96.142.162 Show quoted text
--- All nice --- Test 2: Using Bind 9.10 resolver (bind910-9.10.3P4) [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.is Net::DNS 1.05 aker.isnic.is 193.4.58.91 2001:67c:6c:58:0:0:0:91 [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.com Net::DNS 1.05 ns1.ipage.com 66.96.142.163 66.96.142.116 66.96.142.162 [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.COM Net::DNS 1.05 unresolvable name: ns1.ipage.COM at ./resolve.pl line 6. ns1.ipage.COM [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.IS Net::DNS 1.05 unresolvable name: aker.isnic.IS at ./resolve.pl line 6. aker.isnic.IS [bjornr@dev-br ~]$ ./resolve.pl aker.ISNIC.is Net::DNS 1.05 unresolvable name: aker.ISNIC.is at ./resolve.pl line 6. aker.ISNIC.is [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.is Net::DNS 1.05 aker.isnic.is 193.4.58.91 2001:67c:6c:58:0:0:0:91 --- Fails when you change the case Test 3: Using Bind 9.10 resolver, same as above but with the option no-case-compress { any; }; [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.is Net::DNS 1.05 aker.isnic.is 193.4.58.91 2001:67c:6c:58:0:0:0:91 [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.IS Net::DNS 1.05 aker.isnic.IS 193.4.58.91 2001:67c:6c:58:0:0:0:91 --- Everything works Test 4: Using Bind 9.8 (9.8.4.dfsg.P1-6+nmu2+deb7u10) [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.IS Net::DNS 1.05 aker.isnic.IS 193.4.58.91 2001:67c:6c:58:0:0:0:91 [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.is Net::DNS 1.05 aker.isnic.is 193.4.58.91 2001:67c:6c:58:0:0:0:91 --- Everything works The discussion which matches this problem, and where I found the no-case-compress suggestion: https://lists.isc.org/pipermail/bind-users/2016-March/096578.html My issue is not with external DNS resolvers, I only experience this issue with recent Bind 9.9 and Bind 9.10 servers as local resolvers. Kind regards, Björn
----- Original Message -----
> From: "Dick Franks via RT" <bug-Net-DNS@rt.cpan.org> > To: bjornr@isnic.is > Sent: Friday, 20 May, 2016 5:24:08 PM > Subject: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems > > <URL: https://rt.cpan.org/Ticket/Display.html?id=114351 > >
...
> > > Please can you boil your script down to a _small_ and convincing example > using nameservers in the global internet, so that we can attempt to repeat > your observations free of any influence from your local BIND configuration. > >
From: rwfranks [...] acm.org
On Fri May 20 14:11:19 2016, bjornr@isnic.is wrote: Show quoted text
> Hello, > > The test program: > > #!/usr/local/bin/perl > use Net::DNS; > print 'Net::DNS ', Net::DNS->version, "\n"; > my $resolver = Net::DNS::Resolver->new(); > my $name = $ARGV[0]; > $resolver->nameservers($name); > my @ip = $resolver->nameservers(); > print "$name\t@ip\n"; > > Test 1: Using the Google resolver 8.8.8.8: > > [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.com > Net::DNS 1.02 > ns1.ipage.com 66.96.142.163 66.96.142.162 66.96.142.116 > [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.com > Net::DNS 1.05 > ns1.ipage.com 66.96.142.163 66.96.142.116 66.96.142.162 > [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.COM > Net::DNS 1.05 > ns1.ipage.COM 66.96.142.163 66.96.142.116 66.96.142.162 > > --- All nice --- > > Test 2: Using Bind 9.10 resolver (bind910-9.10.3P4) > > [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.is > Net::DNS 1.05 > aker.isnic.is 193.4.58.91 2001:67c:6c:58:0:0:0:91 > [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.com > Net::DNS 1.05 > ns1.ipage.com 66.96.142.163 66.96.142.116 66.96.142.162 > [bjornr@dev-br ~]$ ./resolve.pl ns1.ipage.COM > Net::DNS 1.05 > unresolvable name: ns1.ipage.COM at ./resolve.pl line 6. > ns1.ipage.COM > [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.IS > Net::DNS 1.05 > unresolvable name: aker.isnic.IS at ./resolve.pl line 6. > aker.isnic.IS > [bjornr@dev-br ~]$ ./resolve.pl aker.ISNIC.is > Net::DNS 1.05 > unresolvable name: aker.ISNIC.is at ./resolve.pl line 6. > aker.ISNIC.is > [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.is > Net::DNS 1.05 > aker.isnic.is 193.4.58.91 2001:67c:6c:58:0:0:0:91 > > --- Fails when you change the case > > Test 3: Using Bind 9.10 resolver, same as above but with the option > no-case-compress { any; }; > > [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.is > Net::DNS 1.05 > aker.isnic.is 193.4.58.91 2001:67c:6c:58:0:0:0:91 > [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.IS > Net::DNS 1.05 > aker.isnic.IS 193.4.58.91 2001:67c:6c:58:0:0:0:91 > > --- Everything works > > Test 4: Using Bind 9.8 (9.8.4.dfsg.P1-6+nmu2+deb7u10) > > [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.IS > Net::DNS 1.05 > aker.isnic.IS 193.4.58.91 2001:67c:6c:58:0:0:0:91 > [bjornr@dev-br ~]$ ./resolve.pl aker.isnic.is > Net::DNS 1.05 > aker.isnic.is 193.4.58.91 2001:67c:6c:58:0:0:0:91 > > --- Everything works > > The discussion which matches this problem, and where I found the no- > case-compress suggestion: https://lists.isc.org/pipermail/bind- > users/2016-March/096578.html > > My issue is not with external DNS resolvers, I only experience this > issue with recent Bind 9.9 and Bind 9.10 servers as local resolvers. > > Kind regards, > Björn > > ----- Original Message -----
> > From: "Dick Franks via RT" <bug-Net-DNS@rt.cpan.org> > > To: bjornr@isnic.is > > Sent: Friday, 20 May, 2016 5:24:08 PM > > Subject: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems > > > > <URL: https://rt.cpan.org/Ticket/Display.html?id=114351 > > >
> ...
> > > > > > Please can you boil your script down to a _small_ and convincing > > example > > using nameservers in the global internet, so that we can attempt to > > repeat > > your observations free of any influence from your local BIND > > configuration. > > > >
Your test program is incomplete because it does not specify the default nameserver which will be used for the lookup inside nameservers(). It is unreasonable to expect me to install various versions and configurations of BIND on the off-chance of repeating your result. If you are claiming a bug in Net::DNS, it is for you to furnish the evidence. If a particular version or configuration of BIND is an essential part of the experimental setup, then you need to make a suitable nameserver accessible from the global internet or identify one which already exists.
Subject: Re: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems
Date: Sat, 21 May 2016 08:34:24 +0000 (GMT)
To: bug-Net-DNS [...] rt.cpan.org
From: Björn Róbertsson <bjornr [...] isnic.is>
Hello, I would be happy to clone some vm's with the configuration I am using, but I would prefer not to open them up to the general community. If you tell me an IP Address range I would be happy to permit recursive resolution from that. Regards, Björn ... Show quoted text
> Your test program is incomplete because it does not specify the default > nameserver which will be used for the lookup inside nameservers(). It is > unreasonable to expect me to install various versions and configurations of > BIND on the off-chance of repeating your result. > > If you are claiming a bug in Net::DNS, it is for you to furnish the evidence. > If a particular version or configuration of BIND is an essential part of > the experimental setup, then you need to make a suitable nameserver > accessible from the global internet or identify one which already exists. > >
Subject: Re: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems
Date: Sat, 21 May 2016 11:59:59 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Willem Toorop <willem [...] nlnetlabs.nl>
Thank you Björn, That is very accommodating! I could open up some recursive resolvers at NLnet Labs accessible over TCP only too. I'll try to do that tonight. -- Willem Op 21-05-16 om 10:34 schreef Björn Róbertsson via RT: Show quoted text
> Queue: Net-DNS > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=114351 > > > Hello, > > I would be happy to clone some vm's with the configuration I am using, but I would prefer not to open them up to the general community. If you tell me an IP Address range I would be happy to permit recursive resolution from that. > > Regards, > Björn > > ...
>> Your test program is incomplete because it does not specify the default >> nameserver which will be used for the lookup inside nameservers(). It is >> unreasonable to expect me to install various versions and configurations of >> BIND on the off-chance of repeating your result. >> >> If you are claiming a bug in Net::DNS, it is for you to furnish the evidence. >> If a particular version or configuration of BIND is an essential part of >> the experimental setup, then you need to make a suitable nameserver >> accessible from the global internet or identify one which already exists. >> >>
Subject: Re: [rt.cpan.org #114351] p5-Net-DNS 1.05 problems
Date: Sat, 21 May 2016 11:18:26 +0000 (GMT)
To: bug-Net-DNS [...] rt.cpan.org
From: Björn Róbertsson <bjornr [...] isnic.is>
As discussed, I've create 4 nameservers: # FreeBSD 10.3 + bind 9.10 # nameserver 193.4.58.209 # FreeBSD 10.3 + bind 9.9 # nameserver 193.4.58.217 # Debian 8 + bind 9.9 # nameserver 193.4.58.222 # Debian 7 + bind 9.8 # nameserver 193.4.58.214 The last nameserver, always succeeds with the resolv.pl (which is run from a FreeBSD 10.3 server, with p5-Net-DNS 1.05 from the ports tree) The allow-recursion is limited for Dick Franks provided IP address, except 222 which is open. Kind regards, Björn
From: rwfranks [...] acm.org
Thanks for your help Björn. Case sensitive name compression exposes a problem in code intended to link a CNAME to its target address records.
This was fixed in 1.06