Bug #41076 for Net-DNS: inconsistent handling of qname with special chars (wire presentation or not)

Wed Nov 19 16:54:58 2008 Steffen_Ullrich [...] genua.de - Ticket #41071: Ticket created

Subject:

inconsistent handling of qname with special chars (wire presentation or not)

sometimes the wire presentation is used, sometimes the text presentation, depending if the packet was created from data or not: use Net::DNS; use strict; my $pkt1 = Net::DNS::Packet->new( "spa ce","A","IN" ); my $pkt2 = Net::DNS::Packet->new( \$pkt1->data ); warn "pkt1.q.qname='".($pkt1->question)[0]->qname."'\n"; warn "pkt2.q.qname='".($pkt2->question)[0]->qname."'\n"; ---- gives: pkt1.q.qname='spa ce' pkt2.q.qname='spa\032ce' This was found when using the SPF test suite which uses DNS names with spaces to check implementation BTW, I cannot find any documentation that not the raw data (wire presentation) are given, about the kind of text presentation used and I find it strange that in the text presentation \032 means chr(32) and not chr(oct(32)) like one would expect from perl strings

Wed Nov 19 18:15:53 2008 Steffen_Ullrich [...] genua.de - Ticket created

Subject:

Net::DNS::RR for type AAAA handles short records wrong (like ffff::1)

use strict; use Net::DNS; my $pkt1 = Net::DNS::Packet->new('e3.example.com','AAAA','IN'); $pkt1->push( answer => Net::DNS::RR->new( name => 'e3.example.com', type => 'AAAA', address => 'CAFE:BABE::1' )); my $pkt2 = Net::DNS::Packet->new( \$pkt1->data ); warn "pkt1.answer=".($pkt1->answer)[0]->string."\n"; warn "pkt2.answer=".($pkt2->answer)[0]->string."\n"; ---- gives: pkt1.answer=e3.example.com. 0 IN AAAA CAFE:BABE::1 pkt2.answer=e3.example.com. 0 IN AAAA cafe:babe:0:1:0:0:0:0 In Net::DNS::RR::new_from_hash the only special handling is done for OPT records, so the address gets saved like given. But Net::DNS::RR::AAAA::rr_data assumes, that the address is in the form %x:%x:%x:%x:%x:%x:%x:%x.

Thu Nov 20 08:24:11 2008 olaf [...] dacht.net - Ticket #41071: Correspondence added

Subject:	Re: [rt.cpan.org #41071] inconsistent handling of qname with special chars (wire presentation or not)
Date:	Thu, 20 Nov 2008 07:23:43 -0600
To:	bug-Net-DNS [...] rt.cpan.org
From:	Olaf Kolkman <olaf [...] dacht.net>

On Nov 19, 2008, at 3:55 PM, Steffen Ullrich via RT wrote: Show quoted text

> Wed Nov 19 16:54:58 2008: Request 41071 was acted upon. > Transaction: Ticket created by SULLR > Queue: Net-DNS > Subject: inconsistent handling of qname with special chars (wire > presentation or not) > Broken in: 0.63 > Severity: Normal > Owner: Nobody > Requestors: Steffen_Ullrich@genua.de > Status: new > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=41071 > > > > sometimes the wire presentation is used, sometimes the text > presentation, depending if the packet was created from data or not: > > use Net::DNS; > use strict; > my $pkt1 = Net::DNS::Packet->new( "spa ce","A","IN" ); > my $pkt2 = Net::DNS::Packet->new( \$pkt1->data ); > warn "pkt1.q.qname='".($pkt1->question)[0]->qname."'\n"; > warn "pkt2.q.qname='".($pkt2->question)[0]->qname."'\n"; > ---- > gives: > pkt1.q.qname='spa ce' > pkt2.q.qname='spa\032ce' > > This was found when using the SPF test suite which uses DNS names with > spaces to check implementation > > > BTW, I cannot find any documentation that not the raw data (wire > presentation) are given, about the kind of text presentation used > and I find it strange that in the text presentation \032 means > chr(32) and not chr(oct(32)) like one would expect from perl strings

FWIW: spa\032ce is the correct representation (zonefile format) specified in RFC1035 section 5.1: \DDD where each D is a digit is the octet corresponding to the decimal number described by DDD. The resulting octet is assumed to be text and is not checked for special meaning. In other words 'spa ce' is the buggy variety of the two and one could argue that the code should just throw an error when seeing such domain name (lets not go there yet :-) ). I'll look into why these two representations are different, but I suspect this is because it is we do not do any processing on the domain name when it has not (yet) been transformed to wire format (and back). --Olaf

Download PGP.sig
application/pgp-signature 235b

Message body not shown because it is not plain text.

Thu Nov 20 08:24:14 2008 The RT System itself - Ticket #41071: Status changed from 'new' to 'open'

Thu Nov 20 10:02:55 2008 Steffen_Ullrich [...] genua.de - Ticket #41071: Correspondence added

Subject:	Re: [rt.cpan.org #41071] inconsistent handling of qname with special chars (wire presentation or not)
Date:	Thu, 20 Nov 2008 16:02:28 +0100
To:	"Olaf M. Kolkman via RT" <bug-Net-DNS [...] rt.cpan.org>
From:	Steffen Ullrich <Steffen_Ullrich [...] genua.de>

Hi Olaf, Thanks for your fast reply. Show quoted text

> In other words 'spa ce' is the buggy variety of the two and one could > argue that the code should just throw an error when seeing such domain > name (lets not go there yet :-) ). I'll look into why these two

The section you mention is about the representation of the data in the master files. In my opinion it would be the right thing to quote the qname in things like Net::DNS::RR::string, but not, if one calls qname() directly. Anyway, as long as it is consistent and documented it shouldn't matter and fortunatly these kind of strang qnames are not that common. Regards, Steffen

Tue Dec 16 08:48:02 2008 OLAF [...] cpan.org - Ticket #41071: Merged into ticket #41076

Tue Dec 16 08:48:02 2008 OLAF [...] cpan.org - Merged into ticket #41076

Tue Dec 16 08:48:02 2008 OLAF [...] cpan.org - Subject changed from 'Net::DNS::RR for type AAAA handles short records wrong (like ffff::1)' to 'inconsistent handling of qname with special chars (wire presentation or not)'

Tue Dec 16 08:48:03 2008 OLAF [...] cpan.org - Severity Important changed to Normal

Tue Dec 16 08:58:53 2008 OLAF [...] cpan.org - Correspondence added

Fix rt.cpan.org # 41076 and # 41071 Net::DNS::RR->new_from_hash function would not normalize the content of the data so that a method getting a string representation would get inconsistent results depending on whether a RR was created from a string of from a hash. On the trunk as of SVN revision 730

Tue Dec 16 08:58:53 2008 The RT System itself - Status changed from 'new' to 'open'

Tue Dec 16 08:58:54 2008 OLAF [...] cpan.org - Status changed from 'open' to 'resolved'

Mon Jan 19 15:03:21 2009 Steffen_Ullrich [...] genua.de - Status changed from 'resolved' to 'open'

Mon Jan 19 15:10:48 2009 Steffen_Ullrich [...] genua.de - Correspondence added

On Di. 16. Dez. 2008, 08:58:53, OLAF wrote: Show quoted text

> Fix rt.cpan.org # 41076 and # 41071 > > Net::DNS::RR->new_from_hash function would not normalize the content > of the data so that a method getting a string representation would > get inconsistent results depending on whether a RR was created from > a string of from a hash. > >

Sorry, but 41071 is not fixed. cafe:babe::1 will still be shown as cafe:babe:0:1:0:0:0:0 instead of cafe:babe:0:0:0:0:0:1 The reason is probably, that you use Net::DNS::RR::AAAA::rr_data called from Net::DNS::RR::rdata called from Net::DNS::RR::data called from Net::DNS::Packet::data called from Net::DNS::RR::_normalize_rdata to normalize the data. But Net::DNS::RR::AAAA::rr_data expects an already normalized address because it splits on ':' only, thus cafe:babe::1 will be interpreted as 'cafe','babe',0,1,0,0,0,0. Regards, Steffen

Mon Jan 26 16:38:13 2009 OLAF [...] cpan.org - Status changed from 'open' to 'resolved'