Skip Menu |
 

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

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

People
Owner: Nobody in particular
Requestors: hsalgado [...] vulcano.cl
Cc:
AdminCc:

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



Subject: Type bit map in NSEC3 with empty non-terminal
Download (untitled) / with headers
text/plain 737b
When you have a NSEC3 signed zone with a empty non-terminal RR, the corresponding NSEC3 hashed name have an empty type bit map. In these cases, the Net::DNS::Zone::Parser->read call fails with this message: Can't use an undefined value as an ARRAY reference at /usr/local/lib/perl5/site_perl/5.10.0/Net/DNS/RR/NSEC.pm line 186, <DUMP> line 59. The problem is with the "bm" array which is empty, and so cannot be referenced inside the for condition in the line 187. In my proof-of-concept patch, I added a line return '' unless @typelist; after line 163, and then the parser finish with the full zone. My perl version is 5.10.0, module Net/DNS/RR/NSEC.pm is 728. Attached is the example signed zone from the RFC5155, which fails.
Subject: example.zone
Download example.zone
application/octet-stream 12.1k

Message body not shown because it is not plain text.

Download (untitled) / with headers
text/plain 333b
I forgot the test case, using the example.zone file: % perl -MNet::DNS::Zone::Parser -e '$p=Net::DNS::Zone::Parser->new; $p->read("example.zone", { ORIGIN => "example", CREATE_RR => 1});' Can't use an undefined value as an ARRAY reference at /usr/local/lib/perl5/site_perl/5.10.0/Net/DNS/RR/NSEC.pm line 187, <DUMP> line 59. Hugo
Download (untitled) / with headers
text/plain 1.1k
On Fri Nov 20 14:37:57 2009, HUGUEI wrote: Show quoted text
> When you have a NSEC3 signed zone with a empty non-terminal RR, the > corresponding NSEC3 hashed name have an empty type bit map.
Are you sure your signer does the right thing? I've not went back to the specs at this moment, but if my memory doesn't faill than there is no reason why empty-non-terminals should get an NSEC3 and even if they would the bitmap should contain the RRSIG, correct? Show quoted text
> > In these cases, the Net::DNS::Zone::Parser->read call fails with this > message: > Can't use an undefined value as an ARRAY reference at > /usr/local/lib/perl5/site_perl/5.10.0/Net/DNS/RR/NSEC.pm line 186, > <DUMP> line 59. > > The problem is with the "bm" array which is empty, and so cannot be > referenced inside the for condition in the line 187. > > In my proof-of-concept patch, I added a line > return '' unless @typelist; > after line 163, and then the parser finish with the full zone. >
That makes the code more fault tolerant, but more fault tolerance provides you with means to shoot yourself in the foot (i.e. you won't notice your empty bitmap). I've applied the patch but with hesitation. --Olaf
Download (untitled) / with headers
text/plain 2.1k
On Vie. Nov. 27 04:05:11 2009, OLAF wrote: Show quoted text
> On Fri Nov 20 14:37:57 2009, HUGUEI wrote:
> > When you have a NSEC3 signed zone with a empty non-terminal RR, the > > corresponding NSEC3 hashed name have an empty type bit map.
> > Are you sure your signer does the right thing? >
You can never be sure :), that's why I attached the example.test zone directly copied from RFC5155, appendix A. The NSEC3 RR with the name ji6neoaepv8b5o6k4ev33abha8ht9fgc.example., belonging to the empty non-terminal y.w.example, has an empty type bitmap. Show quoted text
> I've not went back to the specs at this moment, but if my memory > doesn't faill than there is > no reason why empty-non-terminals should get an NSEC3 and even if they > would the > bitmap should contain the RRSIG, correct?
Nop. In 7.1, second point "Each empty non-terminal MUST have a corresponding NSEC3 RR, unless the empty non-terminal is only derived from an insecure delegation covered by an Opt-Out NSEC3 RR." And regarding the RRSIG, in 7.1: "The Type Bit Maps field of every NSEC3 RR in a signed zone MUST indicate the presence of all types present at the original owner name, *except* for the types solely contributed by an NSEC3 RR itself. Note that this means that the NSEC3 type itself will never be present in the Type Bit Maps.". So not even the NSEC3's RRSIG, I think. Show quoted text
> >
> > > > In these cases, the Net::DNS::Zone::Parser->read call fails with
> this
> > message: > > Can't use an undefined value as an ARRAY reference at > > /usr/local/lib/perl5/site_perl/5.10.0/Net/DNS/RR/NSEC.pm line 186, > > <DUMP> line 59. > > > > The problem is with the "bm" array which is empty, and so cannot be > > referenced inside the for condition in the line 187. > > > > In my proof-of-concept patch, I added a line > > return '' unless @typelist; > > after line 163, and then the parser finish with the full zone. > >
> > That makes the code more fault tolerant, but more fault tolerance > provides you with means > to shoot yourself in the foot (i.e. you won't notice your empty > bitmap). > > I've applied the patch but with hesitation.
Thanks a lot. But please don't feel guilty! :) Hugo
Subject: Re: [rt.cpan.org #51778] Type bit map in NSEC3 with empty non-terminal
Date: Fri, 27 Nov 2009 15:00:10 +0100
To: bug-Net-DNS-SEC [...] rt.cpan.org
From: Olaf Kolkman <olaf [...] dacht.net>
Download (untitled) / with headers
text/plain 1.7k
On Nov 27, 2009, at 2:41 PM, Hugo Salgado H. via RT wrote: Show quoted text
> Queue: Net-DNS-SEC > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=51778 > > > On Vie. Nov. 27 04:05:11 2009, OLAF wrote:
>> On Fri Nov 20 14:37:57 2009, HUGUEI wrote:
>>> When you have a NSEC3 signed zone with a empty non-terminal RR, the >>> corresponding NSEC3 hashed name have an empty type bit map.
>> >> Are you sure your signer does the right thing? >>
> > You can never be sure :), that's why I attached the example.test zone > directly copied from RFC5155, appendix A. The NSEC3 RR with the name > ji6neoaepv8b5o6k4ev33abha8ht9fgc.example., belonging to the empty > non-terminal y.w.example, has an empty type bitmap. >
>> I've not went back to the specs at this moment, but if my memory >> doesn't faill than there is >> no reason why empty-non-terminals should get an NSEC3 and even if they >> would the >> bitmap should contain the RRSIG, correct?
> > Nop. In 7.1, second point "Each empty non-terminal MUST have a > corresponding NSEC3 RR, unless the empty non-terminal is only derived > from an insecure delegation covered by an Opt-Out NSEC3 RR." > > And regarding the RRSIG, in 7.1: "The Type Bit Maps field of every > NSEC3 RR in a signed zone MUST indicate the presence of all types > present at the original owner name, *except* for the types solely > contributed by an NSEC3 RR itself. Note that this means that the NSEC3 > type itself will never be present in the Type Bit Maps.". So not > even the NSEC3's RRSIG, I think.
Ah.. see, I should have gone back to the specs. It was indeed spelled out in much detail. Thanks for reminding me of those details. --Olaf Show quoted text
__________________________________________ Ik dacht net... heel even maar.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.