Skip Menu |

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

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

People
Owner: Nobody in particular
Requestors: corycartwright [...] sbcglobal.net
Cc:
AdminCc:

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



Subject: Net::DNS debug off, returns different structure
Hello, I was working on looking up NAPTR records with Net::DNS. I have some simple code and I'm using e164.org to demonstrate, but this will be used on a private ENUM server. The problem is a the data structure that is returned from a query seem to only be correct is debug is on. Bellow is my sample code, and below that is the returned data with and without debug on. Thanks, Cory PM http://perlmonks.org/?node_id=775110 #!/usr/bin/perl # use strict; use warnings; use Data::Dumper; use Net::DNS; my $domain = ".e164.org"; my $number = join('.',(reverse(split(//,"18604850042")))) . $domain; print "$number\n"; my $res = Net::DNS::Resolver->new( nameservers => ['e164.org'], recurse => 0, debug => 0, ); my $NAPTR = $res->query($number,'NAPTR'); print Dumper($NAPTR); print "*** " . $NAPTR->{'answer'}->[1]->{'regexp'} . "\n"; [download] With debug off $VAR1 = bless( { 'answer' => [], 'buffer' => \'üv 24005840681e164org#À #<Md E2U+X-ADDRESS7!^.*$!data:,CN=Cory C Cartwright;ST=CT;C=United States!À #<Gd uE2U+SIP7!^\\+18604850042$!sip:6200@superiordesign.homelinux.net!', 'question' => [ bless( { 'qclass' => 'IN', 'qname' => '2.4.0.0.5.8.4.0. +6.8.1.e164.org', 'qtype' => 'NAPTR' }, 'Net::DNS::Question' ) ], 'answerfrom' => '208.70.151.161', 'answersize' => 220, 'additional' => [], 'authority' => [], 'header' => bless( { 'nscount' => 0, 'cd' => 0, 'qdcount' => 1, 'ancount' => 2, 'rcode' => 'NOERROR', 'tc' => 0, 'opcode' => 'QUERY', 'ad' => 0, 'ra' => 0, 'qr' => 1, 'arcount' => 0, 'id' => 64630, 'aa' => 1, 'rd' => 0 }, 'Net::DNS::Header' ), 'offset' => 48 }, 'Net::DNS::Packet' ); [download] With debug on ;; query(2.4.0.0.5.8.4.0.6.8.1.e164.org, NAPTR) ;; Trying to set up a AF_INET6() family type UDP socket with srcaddr: +0.0.0.0 ... done ;; setting up an AF_INET() family type UDP socket ;; send_udp(208.70.151.161:53) ;; answer from 208.70.151.161:53 : 220 bytes ;; HEADER SECTION ;; id = 1301 ;; qr = 1 opcode = QUERY aa = 1 tc = 0 rd = 0 ;; ra = 0 ad = 0 cd = 0 rcode = NOERROR ;; qdcount = 1 ancount = 2 nscount = 0 arcount = 0 ;; QUESTION SECTION (1 record) ;; 2.4.0.0.5.8.4.0.6.8.1.e164.org. IN NAPTR ;; ANSWER SECTION (2 records) 2.4.0.0.5.8.4.0.6.8.1.e164.org. 60 IN NAPTR 100 10 "u" "E2 +U+X-ADDRESS" "!^.*$!data:,CN=Cory C Cartwright;ST=CT;C=United States! +" . 2.4.0.0.5.8.4.0.6.8.1.e164.org. 60 IN NAPTR 100 10 "u" "E2 +U+SIP" "!^\+18604850042$!sip:6200@superiordesign.homelinux.net!" . ;; AUTHORITY SECTION (0 records) ;; ADDITIONAL SECTION (0 records) $VAR1 = bless( { 'answer' => [ bless( { 'flags' => 'u', 'ttl' => 60, 'name' => '2.4.0.0.5.8.4.0.6.8 +.1.e164.org', 'service' => 'E2U+X-ADDRESS', 'rdata' => 'd E2U+X-ADDRESS7!^.*$!data:,CN=Cory C Cartwright;ST=CT;C=United States!' +, 'preference' => 10, 'rdlength' => 77, 'regexp' => '!^.*$!data:,CN=Co +ry C Cartwright;ST=CT;C=United States!', 'order' => 100, 'type' => 'NAPTR', 'class' => 'IN', 'replacement' => '' }, 'Net::DNS::RR::NAPTR' ), bless( { 'flags' => 'u', 'ttl' => 60, 'name' => '2.4.0.0.5.8.4.0.6.8 +.1.e164.org', 'service' => 'E2U+SIP', 'rdata' => 'd uE2U+SIP7!^\\+18604850042$!sip:6200@superiordesign.homelinux.net!', 'preference' => 10, 'rdlength' => 71, 'regexp' => '!^\\+18604850042$ +!sip:6200@superiordesign.homelinux.net!', 'order' => 100, 'type' => 'NAPTR', 'class' => 'IN', 'replacement' => '' }, 'Net::DNS::RR::NAPTR' ) ], 'buffer' => undef, 'question' => [ bless( { 'qclass' => 'IN', 'qname' => '2.4.0.0.5.8.4.0. +6.8.1.e164.org', 'qtype' => 'NAPTR' }, 'Net::DNS::Question' ) ], 'answerfrom' => '208.70.151.161', 'answersize' => 220, 'additional' => [], 'authority' => [], 'header' => bless( { 'nscount' => 0, 'cd' => 0, 'qdcount' => 1, 'ancount' => 2, 'rcode' => 'NOERROR', 'tc' => 0, 'opcode' => 'QUERY', 'ad' => 0, 'ra' => 0, 'qr' => 1, 'arcount' => 0, 'id' => 1301, 'aa' => 1, 'rd' => 0 }, 'Net::DNS::Header' ), 'offset' => undef }, 'Net::DNS::Packet' ); *** !^\+18604850042$!sip:6200@superiordesign.homelinux.net! [download]
Subject: I was working on looking up NAPTR records with Net.rtf

Message body not shown because it is not plain text.

update: Linux esacdev 2.6.27.21-78.2.41.fc9.i686 #1 SMP Mon Mar 23 23:45:58 EDT 2009 i686 i686 i386 GNU/Linux This is perl, v5.10.0 built for i386-linux-thread-multi bind ver, not sure e164.org On Thu Jul 02 13:02:25 2009, corycartwright wrote: Show quoted text
> Hello, > I was working on looking up NAPTR records with Net::DNS. I have some > simple code and I'm using e164.org to demonstrate, but this will be used > on a private ENUM server. The problem is a the data structure that is > returned from a query seem to only be correct is debug is on. Bellow is > my sample code, and below that is the returned data with and without > debug on. Thanks, Cory PM http://perlmonks.org/?node_id=775110 > > #!/usr/bin/perl # use strict; use warnings; use Data::Dumper; use > Net::DNS; my $domain = ".e164.org"; my $number = > join('.',(reverse(split(//,"18604850042")))) . $domain; print > "$number\n"; my $res = Net::DNS::Resolver->new( nameservers => > ['e164.org'], recurse => 0, debug => 0, ); my $NAPTR = > $res->query($number,'NAPTR'); print Dumper($NAPTR); print "*** " . > $NAPTR->{'answer'}->[1]->{'regexp'} . "\n"; > [download] > > With debug off > > $VAR1 = bless( { 'answer' => [], 'buffer' => \'üv 24005840681e164org#À > #<Md E2U+X-ADDRESS7!^.*$!data:,CN=Cory C Cartwright;ST=CT;C=United > States!À #<Gd > uE2U+SIP7!^\\+18604850042$!sip:6200@superiordesign.homelinux.net!', > 'question' => [ bless( { 'qclass' => 'IN', 'qname' => '2.4.0.0.5.8.4.0. > +6.8.1.e164.org', 'qtype' => 'NAPTR' }, 'Net::DNS::Question' ) ], > 'answerfrom' => '208.70.151.161', 'answersize' => 220, 'additional' => > [], 'authority' => [], 'header' => bless( { 'nscount' => 0, 'cd' => 0, > 'qdcount' => 1, 'ancount' => 2, 'rcode' => 'NOERROR', 'tc' => 0, > 'opcode' => 'QUERY', 'ad' => 0, 'ra' => 0, 'qr' => 1, 'arcount' => 0, > 'id' => 64630, 'aa' => 1, 'rd' => 0 }, 'Net::DNS::Header' ), 'offset' => > 48 }, 'Net::DNS::Packet' ); > [download] > > With debug on > > ;; query(2.4.0.0.5.8.4.0.6.8.1.e164.org, NAPTR) ;; Trying to set up a > AF_INET6() family type UDP socket with srcaddr: +0.0.0.0 ... done ;; > setting up an AF_INET() family type UDP socket ;; > send_udp(208.70.151.161:53) ;; answer from 208.70.151.161:53 : 220 bytes > ;; HEADER SECTION ;; id = 1301 ;; qr = 1 opcode = QUERY aa = 1 tc = 0 rd > = 0 ;; ra = 0 ad = 0 cd = 0 rcode = NOERROR ;; qdcount = 1 ancount = 2 > nscount = 0 arcount = 0 ;; QUESTION SECTION (1 record) ;; > 2.4.0.0.5.8.4.0.6.8.1.e164.org. IN NAPTR ;; ANSWER SECTION (2 records) > 2.4.0.0.5.8.4.0.6.8.1.e164.org. 60 IN NAPTR 100 10 "u" "E2 +U+X-ADDRESS" > "!^.*$!data:,CN=Cory C Cartwright;ST=CT;C=United States! +" . > 2.4.0.0.5.8.4.0.6.8.1.e164.org. 60 IN NAPTR 100 10 "u" "E2 +U+SIP" > "!^\+18604850042$!sip:6200@superiordesign.homelinux.net!" . ;; AUTHORITY > SECTION (0 records) ;; ADDITIONAL SECTION (0 records) $VAR1 = bless( { > 'answer' => [ bless( { 'flags' => 'u', 'ttl' => 60, 'name' => > '2.4.0.0.5.8.4.0.6.8 +.1.e164.org', 'service' => 'E2U+X-ADDRESS', > 'rdata' => 'd E2U+X-ADDRESS7!^.*$!data:,CN=Cory C > Cartwright;ST=CT;C=United States!' +, 'preference' => 10, 'rdlength' => > 77, 'regexp' => '!^.*$!data:,CN=Co +ry C Cartwright;ST=CT;C=United > States!', 'order' => 100, 'type' => 'NAPTR', 'class' => 'IN', > 'replacement' => '' }, 'Net::DNS::RR::NAPTR' ), bless( { 'flags' => 'u', > 'ttl' => 60, 'name' => '2.4.0.0.5.8.4.0.6.8 +.1.e164.org', 'service' => > 'E2U+SIP', 'rdata' => 'd > uE2U+SIP7!^\\+18604850042$!sip:6200@superiordesign.homelinux.net!', > 'preference' => 10, 'rdlength' => 71, 'regexp' => '!^\\+18604850042$ > +!sip:6200@superiordesign.homelinux.net!', 'order' => 100, 'type' => > 'NAPTR', 'class' => 'IN', 'replacement' => '' }, 'Net::DNS::RR::NAPTR' ) > ], 'buffer' => undef, 'question' => [ bless( { 'qclass' => 'IN', 'qname' > => '2.4.0.0.5.8.4.0. +6.8.1.e164.org', 'qtype' => 'NAPTR' }, > 'Net::DNS::Question' ) ], 'answerfrom' => '208.70.151.161', 'answersize' > => 220, 'additional' => [], 'authority' => [], 'header' => bless( { > 'nscount' => 0, 'cd' => 0, 'qdcount' => 1, 'ancount' => 2, 'rcode' => > 'NOERROR', 'tc' => 0, 'opcode' => 'QUERY', 'ad' => 0, 'ra' => 0, 'qr' => > 1, 'arcount' => 0, 'id' => 1301, 'aa' => 1, 'rd' => 0 }, > 'Net::DNS::Header' ), 'offset' => undef }, 'Net::DNS::Packet' ); *** > !^\+18604850042$!sip:6200@superiordesign.homelinux.net! > [download] >
Subject: Re: [rt.cpan.org #47515] Net::DNS debug off, returns different structure
Date: Thu, 2 Jul 2009 21:29:41 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Olaf Kolkman <olaf [...] dacht.net>
The reason why they are different is because some parsing off the off- the-wire data (that lives in the buffer) is only parsed to various attributes of the structure when that data is needed. When in debug mode that data is apparently needed by the debug code. The reason to have objects and classes is to provide the data through all kind of methods. In this case you can digest the packet by using the answer() method and access the RRs therein via the methods available in Net::DNS::RR. --Olaf On 2 jul 2009, at 19:02, Cory via RT wrote: Show quoted text
> Thu Jul 02 13:02:25 2009: Request 47515 was acted upon. > Transaction: Ticket created by corycartwright > Queue: Net-DNS > Subject: Net::DNS debug off, returns different structure > Broken in: 0.65 > Severity: Important > Owner: Nobody > Requestors: corycartwright@sbcglobal.net > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=47515 > > > > Hello, > I was working on looking up NAPTR records with Net::DNS. I have some > simple code and I'm using e164.org to demonstrate, but this will be > used > on a private ENUM server. The problem is a the data structure that is > returned from a query seem to only be correct is debug is on. Bellow > is > my sample code, and below that is the returned data with and without > debug on. Thanks, Cory PM http://perlmonks.org/?node_id=775110 > > #!/usr/bin/perl # use strict; use warnings; use Data::Dumper; use > Net::DNS; my $domain = ".e164.org"; my $number = > join('.',(reverse(split(//,"18604850042")))) . $domain; print > "$number\n"; my $res = Net::DNS::Resolver->new( nameservers => > ['e164.org'], recurse => 0, debug => 0, ); my $NAPTR = > $res->query($number,'NAPTR'); print Dumper($NAPTR); print "*** " . > $NAPTR->{'answer'}->[1]->{'regexp'} . "\n"; > [download] > > With debug off > > $VAR1 = bless( { 'answer' => [], 'buffer' => \'üv 24005840681e164org#À > #<Md E2U+X-ADDRESS7!^.*$!data:,CN=Cory C Cartwright;ST=CT;C=United > States!À #<Gd > uE2U+SIP7!^\\+18604850042$!sip:6200@superiordesign.homelinux.net!', > 'question' => [ bless( { 'qclass' => 'IN', 'qname' => > '2.4.0.0.5.8.4.0. > +6.8.1.e164.org', 'qtype' => 'NAPTR' }, 'Net::DNS::Question' ) ], > 'answerfrom' => '208.70.151.161', 'answersize' => 220, 'additional' => > [], 'authority' => [], 'header' => bless( { 'nscount' => 0, 'cd' => 0, > 'qdcount' => 1, 'ancount' => 2, 'rcode' => 'NOERROR', 'tc' => 0, > 'opcode' => 'QUERY', 'ad' => 0, 'ra' => 0, 'qr' => 1, 'arcount' => 0, > 'id' => 64630, 'aa' => 1, 'rd' => 0 }, 'Net::DNS::Header' ), > 'offset' => > 48 }, 'Net::DNS::Packet' ); > [download] > > With debug on > > ;; query(2.4.0.0.5.8.4.0.6.8.1.e164.org, NAPTR) ;; Trying to set up a > AF_INET6() family type UDP socket with srcaddr: +0.0.0.0 ... done ;; > setting up an AF_INET() family type UDP socket ;; > send_udp(208.70.151.161:53) ;; answer from 208.70.151.161:53 : 220 > bytes > ;; HEADER SECTION ;; id = 1301 ;; qr = 1 opcode = QUERY aa = 1 tc = > 0 rd > = 0 ;; ra = 0 ad = 0 cd = 0 rcode = NOERROR ;; qdcount = 1 ancount = 2 > nscount = 0 arcount = 0 ;; QUESTION SECTION (1 record) ;; > 2.4.0.0.5.8.4.0.6.8.1.e164.org. IN NAPTR ;; ANSWER SECTION (2 records) > 2.4.0.0.5.8.4.0.6.8.1.e164.org. 60 IN NAPTR 100 10 "u" "E2 +U+X- > ADDRESS" > "!^.*$!data:,CN=Cory C Cartwright;ST=CT;C=United States! +" . > 2.4.0.0.5.8.4.0.6.8.1.e164.org. 60 IN NAPTR 100 10 "u" "E2 +U+SIP" > "!^\+18604850042$!sip:6200@superiordesign.homelinux.net!" . ;; > AUTHORITY > SECTION (0 records) ;; ADDITIONAL SECTION (0 records) $VAR1 = bless( { > 'answer' => [ bless( { 'flags' => 'u', 'ttl' => 60, 'name' => > '2.4.0.0.5.8.4.0.6.8 +.1.e164.org', 'service' => 'E2U+X-ADDRESS', > 'rdata' => 'd E2U+X-ADDRESS7!^.*$!data:,CN=Cory C > Cartwright;ST=CT;C=United States!' +, 'preference' => 10, 'rdlength' > => > 77, 'regexp' => '!^.*$!data:,CN=Co +ry C Cartwright;ST=CT;C=United > States!', 'order' => 100, 'type' => 'NAPTR', 'class' => 'IN', > 'replacement' => '' }, 'Net::DNS::RR::NAPTR' ), bless( { 'flags' => > 'u', > 'ttl' => 60, 'name' => '2.4.0.0.5.8.4.0.6.8 +.1.e164.org', 'service' > => > 'E2U+SIP', 'rdata' => 'd > uE2U+SIP7!^\\+18604850042$!sip:6200@superiordesign.homelinux.net!', > 'preference' => 10, 'rdlength' => 71, 'regexp' => '!^\\+18604850042$ > +!sip:6200@superiordesign.homelinux.net!', 'order' => 100, 'type' => > 'NAPTR', 'class' => 'IN', 'replacement' => '' }, > 'Net::DNS::RR::NAPTR' ) > ], 'buffer' => undef, 'question' => [ bless( { 'qclass' => 'IN', > 'qname' > => '2.4.0.0.5.8.4.0. +6.8.1.e164.org', 'qtype' => 'NAPTR' }, > 'Net::DNS::Question' ) ], 'answerfrom' => '208.70.151.161', > 'answersize' > => 220, 'additional' => [], 'authority' => [], 'header' => bless( { > 'nscount' => 0, 'cd' => 0, 'qdcount' => 1, 'ancount' => 2, 'rcode' => > 'NOERROR', 'tc' => 0, 'opcode' => 'QUERY', 'ad' => 0, 'ra' => 0, > 'qr' => > 1, 'arcount' => 0, 'id' => 1301, 'aa' => 1, 'rd' => 0 }, > 'Net::DNS::Header' ), 'offset' => undef }, 'Net::DNS::Packet' ); *** > !^\+18604850042$!sip:6200@superiordesign.homelinux.net! > [download] > > > <I was working on looking up NAPTR records with Net.rtf>
Download PGP.sig
application/pgp-signature 235b

Message body not shown because it is not plain text.

Hello Olaf, So is this a bug? I will install Net::DNS::RR and try it that way. Thanks, Cory On Thu Jul 02 15:30:13 2009, olaf@dacht.net wrote: Show quoted text
> > The reason why they are different is because some parsing off the off- > the-wire data (that lives in the buffer) is only parsed to various > attributes of the structure when that data is needed. When in debug > mode that data is apparently needed by the debug code. > > > The reason to have objects and classes is to provide the data through > all kind of methods. In this case you can digest the packet by using > the answer() method and access the RRs therein via the methods > available in Net::DNS::RR. > > --Olaf > > > On 2 jul 2009, at 19:02, Cory via RT wrote: >
> > Thu Jul 02 13:02:25 2009: Request 47515 was acted upon. > > Transaction: Ticket created by corycartwright > > Queue: Net-DNS > > Subject: Net::DNS debug off, returns different structure > > Broken in: 0.65 > > Severity: Important > > Owner: Nobody > > Requestors: corycartwright@sbcglobal.net > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=47515 > > > > > > > Hello, > > I was working on looking up NAPTR records with Net::DNS. I have some > > simple code and I'm using e164.org to demonstrate, but this will be > > used > > on a private ENUM server. The problem is a the data structure that is > > returned from a query seem to only be correct is debug is on. Bellow > > is > > my sample code, and below that is the returned data with and without > > debug on. Thanks, Cory PM http://perlmonks.org/?node_id=775110 > > > > #!/usr/bin/perl # use strict; use warnings; use Data::Dumper; use > > Net::DNS; my $domain = ".e164.org"; my $number = > > join('.',(reverse(split(//,"18604850042")))) . $domain; print > > "$number\n"; my $res = Net::DNS::Resolver->new( nameservers => > > ['e164.org'], recurse => 0, debug => 0, ); my $NAPTR = > > $res->query($number,'NAPTR'); print Dumper($NAPTR); print "*** " . > > $NAPTR->{'answer'}->[1]->{'regexp'} . "\n"; > > [download] > > > > With debug off > > > > $VAR1 = bless( { 'answer' => [], 'buffer' => \'üv 24005840681e164org#À > > #<Md E2U+X-ADDRESS7!^.*$!data:,CN=Cory C Cartwright;ST=CT;C=United > > States!À #<Gd > > uE2U+SIP7!^\\+18604850042$!sip:6200@superiordesign.homelinux.net!', > > 'question' => [ bless( { 'qclass' => 'IN', 'qname' => > > '2.4.0.0.5.8.4.0. > > +6.8.1.e164.org', 'qtype' => 'NAPTR' }, 'Net::DNS::Question' ) ], > > 'answerfrom' => '208.70.151.161', 'answersize' => 220, 'additional' => > > [], 'authority' => [], 'header' => bless( { 'nscount' => 0, 'cd' => 0, > > 'qdcount' => 1, 'ancount' => 2, 'rcode' => 'NOERROR', 'tc' => 0, > > 'opcode' => 'QUERY', 'ad' => 0, 'ra' => 0, 'qr' => 1, 'arcount' => 0, > > 'id' => 64630, 'aa' => 1, 'rd' => 0 }, 'Net::DNS::Header' ), > > 'offset' => > > 48 }, 'Net::DNS::Packet' ); > > [download] > > > > With debug on > > > > ;; query(2.4.0.0.5.8.4.0.6.8.1.e164.org, NAPTR) ;; Trying to set up a > > AF_INET6() family type UDP socket with srcaddr: +0.0.0.0 ... done ;; > > setting up an AF_INET() family type UDP socket ;; > > send_udp(208.70.151.161:53) ;; answer from 208.70.151.161:53 : 220 > > bytes > > ;; HEADER SECTION ;; id = 1301 ;; qr = 1 opcode = QUERY aa = 1 tc = > > 0 rd > > = 0 ;; ra = 0 ad = 0 cd = 0 rcode = NOERROR ;; qdcount = 1 ancount = 2 > > nscount = 0 arcount = 0 ;; QUESTION SECTION (1 record) ;; > > 2.4.0.0.5.8.4.0.6.8.1.e164.org. IN NAPTR ;; ANSWER SECTION (2 records) > > 2.4.0.0.5.8.4.0.6.8.1.e164.org. 60 IN NAPTR 100 10 "u" "E2 +U+X- > > ADDRESS" > > "!^.*$!data:,CN=Cory C Cartwright;ST=CT;C=United States! +" . > > 2.4.0.0.5.8.4.0.6.8.1.e164.org. 60 IN NAPTR 100 10 "u" "E2 +U+SIP" > > "!^\+18604850042$!sip:6200@superiordesign.homelinux.net!" . ;; > > AUTHORITY > > SECTION (0 records) ;; ADDITIONAL SECTION (0 records) $VAR1 = bless( { > > 'answer' => [ bless( { 'flags' => 'u', 'ttl' => 60, 'name' => > > '2.4.0.0.5.8.4.0.6.8 +.1.e164.org', 'service' => 'E2U+X-ADDRESS', > > 'rdata' => 'd E2U+X-ADDRESS7!^.*$!data:,CN=Cory C > > Cartwright;ST=CT;C=United States!' +, 'preference' => 10, 'rdlength' > > => > > 77, 'regexp' => '!^.*$!data:,CN=Co +ry C Cartwright;ST=CT;C=United > > States!', 'order' => 100, 'type' => 'NAPTR', 'class' => 'IN', > > 'replacement' => '' }, 'Net::DNS::RR::NAPTR' ), bless( { 'flags' => > > 'u', > > 'ttl' => 60, 'name' => '2.4.0.0.5.8.4.0.6.8 +.1.e164.org', 'service' > > => > > 'E2U+SIP', 'rdata' => 'd > > uE2U+SIP7!^\\+18604850042$!sip:6200@superiordesign.homelinux.net!', > > 'preference' => 10, 'rdlength' => 71, 'regexp' => '!^\\+18604850042$ > > +!sip:6200@superiordesign.homelinux.net!', 'order' => 100, 'type' => > > 'NAPTR', 'class' => 'IN', 'replacement' => '' }, > > 'Net::DNS::RR::NAPTR' ) > > ], 'buffer' => undef, 'question' => [ bless( { 'qclass' => 'IN', > > 'qname' > > => '2.4.0.0.5.8.4.0. +6.8.1.e164.org', 'qtype' => 'NAPTR' }, > > 'Net::DNS::Question' ) ], 'answerfrom' => '208.70.151.161', > > 'answersize' > > => 220, 'additional' => [], 'authority' => [], 'header' => bless( { > > 'nscount' => 0, 'cd' => 0, 'qdcount' => 1, 'ancount' => 2, 'rcode' => > > 'NOERROR', 'tc' => 0, 'opcode' => 'QUERY', 'ad' => 0, 'ra' => 0, > > 'qr' => > > 1, 'arcount' => 0, 'id' => 1301, 'aa' => 1, 'rd' => 0 }, > > 'Net::DNS::Header' ), 'offset' => undef }, 'Net::DNS::Packet' ); *** > > !^\+18604850042$!sip:6200@superiordesign.homelinux.net! > > [download] > > > > > > <I was working on looking up NAPTR records with Net.rtf>
>
Subject: Re: [rt.cpan.org #47515] Net::DNS debug off, returns different structure
Date: Mon, 6 Jul 2009 21:18:52 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Olaf Kolkman <olaf [...] dacht.net>
On 6 jul 2009, at 15:49, Cory via RT wrote: Show quoted text
> > So is this a bug?
No its not a bug.. its a feature.. what you could also do is call $packet->string and then look at the dump. I would bet the dumps would be similar. --Olaf
Download PGP.sig
application/pgp-signature 235b

Message body not shown because it is not plain text.

Message body is not shown because it is too large.

Subject: Re: [rt.cpan.org #47515] Net::DNS debug off, returns different structure
Date: Fri, 28 Aug 2009 22:33:53 +0200
To: "bug-Net-DNS [...] rt.cpan.org" <bug-Net-DNS [...] rt.cpan.org>
From: Olaf Kolkman <olaf [...] dacht.net>

Message body is not shown because it is too large.

Subject: Re: [rt.cpan.org #47515] Net::DNS debug off, returns different structure
Date: Fri, 28 Aug 2009 16:45:41 -0400
To: bug-Net-DNS [...] rt.cpan.org
From: Cory Cartwright <corycartwright [...] sbcglobal.net>

Message body is not shown because it is too large.

Subject: Re: [rt.cpan.org #47515] Net::DNS debug off, returns different structure
Date: Sat, 29 Aug 2009 11:03:24 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: Olaf Kolkman <olaf [...] dacht.net>
On Aug 28, 2009, at 10:34 PM, Olaf M. Kolkman via RT wrote: Show quoted text
> Queue: Net-DNS > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=47515 > > > Try to compare the results after accessing them via the appropriate > methods. > > Instead of dumping the anonymous hash try accessing it's content with > e.g. $answer->print(); > > If those results differ then there is a problem. > > --Olaf > > Sent from a phone; appologies for the telegram style this message > might have.
The somewhat longer explanation is that the data from the packet is stored in the buffer attribute of the object. For performance optimization the data contained in the packet is only parsed from wire format to presentation format when the various accessor methods are called. The results of the parsing is then also stored for future use. Looking at the internal data storage using Dumper is not the way you would like to study the content of the objects. The whole reason for using objects is to abstract that internal structure. Hope this helps, --Olaf
Download PGP.sig
application/pgp-signature 235b

Message body not shown because it is not plain text.

More practically, the rationale underpinning data hiding and object abstraction is to ensure that programs will not break whenever the implementation changes. --Dick
On Sat Aug 29 05:03:54 2009, olaf@dacht.net wrote: Show quoted text
> > On Aug 28, 2009, at 10:34 PM, Olaf M. Kolkman via RT wrote: >
> > Queue: Net-DNS > > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=47515 > > > > > Try to compare the results after accessing them via the appropriate > > methods. > > > > Instead of dumping the anonymous hash try accessing it's content
with Show quoted text
> > e.g. $answer->print(); > > > > If those results differ then there is a problem. > > > > --Olaf > > > > Sent from a phone; appologies for the telegram style this message > > might have.
> > > > The somewhat longer explanation is that the data from the packet is > stored in the buffer attribute of the object. For performance > optimization the data contained in the packet is only parsed from
wire Show quoted text
> format to presentation format when the various accessor methods are > called. The results of the parsing is then also stored for future use. > > Looking at the internal data storage using Dumper is not the way you > would like to study the content of the objects. The whole reason for > using objects is to abstract that internal structure. > > Hope this helps, > > --Olaf
Thanks Olaf! So, once I use $answer->print (or $answer->string), the contents of $answer->{'answer'} gets populated. It is not clear to me why $answer-> {'answer'} doesn't get populated before I access $answer->print. Based on the docs using $answer->print shouldn't be required. As $answer->{'answer'} previously was populated without $answer->print, it would seem that there is something amiss with my local machine configuration. I did try this code on a different machine (mac os x instead of windows XP) and it worked as expected. At least I now have a way of getting the results I need! Thanks, again! - Bob
On Mon Aug 31 09:52:35 2009, bobramsdell wrote: Show quoted text
> On Sat Aug 29 05:03:54 2009, olaf@dacht.net wrote:
> > > > On Aug 28, 2009, at 10:34 PM, Olaf M. Kolkman via RT wrote: > >
> > > Queue: Net-DNS > > > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=47515 > > > > > > > Try to compare the results after accessing them via the appropriate > > > methods. > > > > > > Instead of dumping the anonymous hash try accessing it's content
> with
> > > e.g. $answer->print(); > > > > > > If those results differ then there is a problem. > > > > > > --Olaf > > > > > > Sent from a phone; appologies for the telegram style this message > > > might have.
> > > > > > > > The somewhat longer explanation is that the data from the packet is > > stored in the buffer attribute of the object. For performance > > optimization the data contained in the packet is only parsed from
> wire
> > format to presentation format when the various accessor methods are > > called. The results of the parsing is then also stored for future use. > > > > Looking at the internal data storage using Dumper is not the way you > > would like to study the content of the objects. The whole reason for > > using objects is to abstract that internal structure. > > > > Hope this helps, > > > > --Olaf
> > Thanks Olaf! > > So, once I use $answer->print (or $answer->string), the contents of > $answer->{'answer'} gets populated. It is not clear to me why $answer-> > {'answer'} doesn't get populated before I access $answer->print. Based > on the docs using $answer->print shouldn't be required. > > As $answer->{'answer'} previously was populated without $answer->print, > it would seem that there is something amiss with my local machine > configuration. I did try this code on a different machine (mac os x > instead of windows XP) and it worked as expected. > > At least I now have a way of getting the results I need! > > Thanks, again! > > - Bob
On Mon Aug 31 09:52:35 2009, bobramsdell wrote: Sorry for the mouse fumble! Show quoted text
> So, once I use $answer->print (or $answer->string), the contents of > $answer->{'answer'} gets populated. It is not clear to me why $answer-> > {'answer'} doesn't get populated before I access $answer->print. Based > on the docs using $answer->print shouldn't be required. > > As $answer->{'answer'} previously was populated without $answer->print, > it would seem that there is something amiss with my local machine > configuration. I did try this code on a different machine (mac os x > instead of windows XP) and it worked as expected. > > At least I now have a way of getting the results I need! > > Thanks, again! > > - Bob
I doubt there is anything wrong with your machine. First thing to do is take Olaf's advice and forget about Data::Dumper and use ONLY the published access methods. Your original example then becomes something like this: #!/usr/bin/perl -w use Net::DNS; my $resolver = Net::DNS::Resolver->new; my $query = new Net::DNS::Packet('66.39.76.93', 'PTR'); # Net::DNS knows how to do reverse IP lookup foreach $qr ( $query->question ) { # list of Question objects print $qr->qname, "\n"; # get name using object's qname method } print "Resolving ...\n"; my $reply = $resolver->send( $query ); # reply (if any) is unparsed in a buffer inside packet object if ( $reply ) { # important to check if reply packet arrived foreach $rr ( $reply->answer ) { # answer parsed and returned as list of RR objects $rr->print; # invoke RR object's print method } } else { print "no response\n"; } exit;
Closing the ticket as it is not further actionable