Bug #119126 for Net-DNS: Bug: scalar $rr->txtdata returns strings joined with spaces

Mon Dec 05 08:38:40 2016 johnpc [...] xs4all.net - Ticket created

Subject:	Bug: scalar $rr->txtdata returns strings joined with spaces
Date:	Mon, 5 Dec 2016 14:38:18 +0100
To:	bug-Net-DNS [...] rt.cpan.org
From:	Jan-Pieter Cornet <johnpc [...] xs4all.net>

Subject:	Bug: scalar $rr->txtdata returns strings joined with spaces
To:	bug-Net-DNS [...] rt.cpan.org
From:	Jan-Pieter Cornet <johnpc [...] xs4all.net>

Hi Net::DNS team, The scalar variant of Net::DNS::RR::TXT->txtdata returns the individual strings from the TXT record separated with spaces, instead of glued together as specified in https://tools.ietf.org/html/rfc6376#section-3.6.2.2 and https://tools.ietf.org/html/rfc4408#section-3.1.3 Example: $ perl -MNet::DNS -le 'print "Net::DNS version $Net::DNS::VERSION"; $rr = Net::DNS::RR->new(q{name IN TXT "very long " "string here"}); print scalar $rr->txtdata' Net::DNS version 1.04 very long string here That is supposed to print "very long string here" in the last line, not "very long string here" with 2 spaces between "long" and "string". Patch attached. -- Jan-Pieter Cornet <johnpc@xs4all.net> Systeembeheer XS4ALL Internet bv www.xs4all.nl

Message body is not shown because sender requested not to inline it.

Download signature.asc
application/pgp-signature 931b

Message body not shown because it is not plain text.

Mon Dec 05 19:45:36 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Mon Dec 05 08:38:40 2016, johnpc@xs4all.net wrote: Show quoted text

> Hi Net::DNS team, > > The scalar variant of Net::DNS::RR::TXT->txtdata returns the > individual strings from the TXT record separated with spaces, instead > of glued together as specified in > https://tools.ietf.org/html/rfc6376#section-3.6.2.2 and > https://tools.ietf.org/html/rfc4408#section-3.1.3 >

The TXT RR is defined in RFC1035. Neither RFC6376 nor RFC4408 updated RFC1035. RFC6376 and RFC4408 imposed entirely separate usages of TXT RRs. It is the responsibility of DKIM and SPF applications to concatenate multiple strings in the manner described in those documents.

Mon Dec 05 19:45:37 2016 The RT System itself - Status changed from 'new' to 'open'

Tue Dec 06 02:59:12 2016 johnpc [...] xs4all.net - Correspondence added

Subject:	Re: [rt.cpan.org #119126] Bug: scalar $rr->txtdata returns strings joined with spaces
Date:	Tue, 6 Dec 2016 08:58:43 +0100
To:	bug-Net-DNS [...] rt.cpan.org
From:	Jan-Pieter Cornet <johnpc [...] xs4all.net>

Subject:	Re: [rt.cpan.org #119126] Bug: scalar $rr->txtdata returns strings joined with spaces
To:	bug-Net-DNS [...] rt.cpan.org
From:	Jan-Pieter Cornet <johnpc [...] xs4all.net>

On 6-12-16 01:45, Dick Franks via RT wrote: Show quoted text

>> The scalar variant of Net::DNS::RR::TXT->txtdata returns the >> individual strings from the TXT record separated with spaces, instead >> of glued together as specified in >> https://tools.ietf.org/html/rfc6376#section-3.6.2.2 and >> https://tools.ietf.org/html/rfc4408#section-3.1.3 >>

> > The TXT RR is defined in RFC1035. Neither RFC6376 nor RFC4408 updated RFC1035. > > RFC6376 and RFC4408 imposed entirely separate usages of TXT RRs. > It is the responsibility of DKIM and SPF applications to concatenate multiple strings in the manner described in those documents.

Joining multiple TXT strings together without any space seems to be common practice in all examples that I've seen, even the ones that do not discuss SPF/DKIM. Those standards didn't explicitly update RFC1035, but they did set a common practice, apparently. If you deviate from that standard, you should at least document it. The current documentation doesn't mention at all how the individual strings are joined. -- Jan-Pieter Cornet <johnpc@xs4all.net> Systeembeheer XS4ALL Internet bv www.xs4all.nl

Download signature.asc
application/pgp-signature 931b

Message body not shown because it is not plain text.

Tue Dec 06 05:45:12 2016 NLNETLABS [...] cpan.org - Correspondence added

Also, we cannot change this behaviour because we have to maintain backwards compatibility. Being more specific in the documentation makes sense to me yes Also note that recent standards (RFC6844 for the CAA RR-type and RFC7553 for the URI RR-type) introduce a new rdata field for long strings, which has a much clearer one-on-one mapping of rdata and the value it represents.

Tue Dec 06 11:58:25 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Tue Dec 06 05:45:12 2016, NLNETLABS wrote: Show quoted text

> Also, we cannot change this behaviour because we have to maintain > backwards compatibility. > > Being more specific in the documentation makes sense to me yes

I agree Show quoted text

> Also note that recent standards (RFC6844 for the CAA RR-type and > RFC7553 for the URI RR-type) introduce a new rdata field for long > strings, which has a much clearer one-on-one mapping of rdata and the > value it represents.

Both these RFC avoid the issue by defining new RRtypes. The TYPE99 SPF implementation concatenates the text elements without intervening spaces, but the proponents of SPF refused to use it. The present DKIM/SPF mess is entirely self-inflicted.

Fri Dec 09 12:41:59 2016 rwfranks [...] acm.org - Correspondence added

From:

rwfranks [...] acm.org

On Tue Dec 06 02:59:12 2016, johnpc@xs4all.net wrote: Show quoted text

> The current documentation doesn't mention at all how the individual > strings are joined.

Revised documentation on trunk

Fri Dec 23 10:33:15 2016 NLNETLABS [...] cpan.org - Status changed from 'open' to 'resolved'