gman has asked for the wisdom of the Perl Monks concerning the following question:

Update: From Olaf,

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

#!/usr/bin/perl # use strict; use warnings; use Data::Dumper; #use Net::DNS; use Net::DNS qw(rrsort); # my @prioritysorted=rrsort("SRV","priority",@rr_array); my $domain = ".e164.org"; my $number = join('.',(reverse(split(//,"18604850042")))) . $domain; print "$number\n"; my $res = Net::DNS::Resolver::UNIX->new( nameservers => ['e164.org'], recurse => 0, debug => 0, ); my $NAPTR = $res->query($number,'NAPTR'); my @rrs_array = ($NAPTR->answer); my @sorted = rrsort("NAPTR","priority",@rrs_array); print Dumper(@rrs);

Update: cpan ticket #47515

Hello all, 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
#!/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";
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' );
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!

Replies are listed 'Best First'.
Re: Net::DNS debug off, returns different structure
by ikegami (Patriarch) on Jun 26, 2009 at 17:31 UTC

    This is not the appropriate place to report a bug. There's no reason to believe its maintainer reads PerlMonks.

    Bugs can be reported by visiting Net::DNS::Resolver on CPAN and following the link "Report a bug".

    Update: By the way, I get the correct output with and without debug.

    You could try downgrading. I have O/OL/OLAF/Net-DNS-0.59.tar.gz installed. You should be able to install it from the cpan tool by using that string as the module name.

    Update: The regression was introduced in 0.62.

      Thanks, was not sure this was a bug. The documentation appeared clear, but did not know if I missed anything. Since the i did not find anything similar doing a search, I thought maybe I missed something. Thanks, Cory
      Thanks,

      I have tried downgrading with the same result. I am running perl 5.10.0, maybe that is the difference or the C lib ver.?

      Anyway, I will work on submitting the bug.

      Thanks again

        Odd. I used perl 5.10.0 and the same library and compiler to build 0.59, 0.61, 0.62, 0.63, 0.64 and 0.65.

        0.59 and 0.61 did not exhibit the problem
        0.62 to 0.65 did.