Skip Menu |

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

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

People
Owner: Nobody in particular
Requestors: mrao [...] verisign.com
Cc:
AdminCc:

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



Subject: Question throws a die
Date: Mon, 7 May 2007 18:32:06 +0530
To: <bug-Net-DNS [...] rt.cpan.org>
From: "Rao, Madhwaraj" <mrao [...] verisign.com>
Distribution name and version: Net-DNS-0.59 Perl version: v5.8.5 OS: Linux 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux Looks like Net/DNS/Question.pm throws a die if the DNS query contains a label larger than 63 bytes. For example, length of wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww wwwwwwwwwwww is larger than 63 octets; see RFC1035 section 2.3.1 at /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi/Net/DNS/Question. pm line 199 Ideally, Question should not throw a die, but return an error status. Thanks -- Raj
Show quoted text
> > Ideally, Question should not throw a die, but return an error status. >
The error message is generated by dn_comp which is used throughout the code. Now I could make changes to the code to have dn_comp return (undef, $error) but I am a bit affraid that returning undef for dn_comp will cascade throughout the code (everywhere were a packet needs to be made) and may give rise to crappy packets ending up on the network unintended. e.g if dn_comp returns undef the NEt::DNS::RR rdata methods will also need to return undef with their own error status which may cascade even further.. What I could do is have dn_comp "carp" instead of "croak" in combination with either: an undeffed dname (the datatype), a dname that should not be on the wire because it shouldn't exist, or replace the dname by a "null length label". Any thoughts?. --Olaf
Show quoted text
> > Ideally, Question should not throw a die, but return an error status. >
The error message is generated by dn_comp which is used throughout the code. Now I could make changes to the code to have dn_comp return (undef, $error) but I am a bit affraid that returning undef for dn_comp will cascade throughout the code (everywhere were a packet needs to be made) and may give rise to crappy packets ending up on the network unintended. e.g if dn_comp returns undef the NEt::DNS::RR rdata methods will also need to return undef with their own error status which may cascade even further.. What I could do is have dn_comp "carp" instead of "croak" in combination with either: an undeffed dname (the datatype), a dname that should not be on the wire because it shouldn't exist, or replace the dname by a "null length label". Any thoughts?. --Olaf
Show quoted text
> > Ideally, Question should not throw a die, but return an error status. >
The error message is generated by dn_comp which is used throughout the code. Now I could make changes to the code to have dn_comp return (undef, $error) but I am a bit affraid that returning undef for dn_comp will cascade throughout the code (everywhere were a packet needs to be made) and may give rise to crappy packets ending up on the network unintended. e.g if dn_comp returns undef the NEt::DNS::RR rdata methods will also need to return undef with their own error status which may cascade even further.. What I could do is have dn_comp "carp" instead of "croak" in combination with either: an undeffed dname (the datatype), a dname that should not be on the wire because it shouldn't exist, or replace the dname by a "null length label". Any thoughts?. --Olaf
Show quoted text
> What I could do is have dn_comp "carp" instead of "croak" in > combination with either: > an undeffed dname (the datatype), a dname that should not be on the > wire because it > shouldn't exist, or replace the dname by a "null length label". >
So what we ended up doing in 0.60 (released last week) is to "carp" (provide a warning") and to just truncate the label.