Bug 7338 - Unexpected parenthesis in DNS RR
Summary: Unexpected parenthesis in DNS RR
Status: RESOLVED DUPLICATE of bug 7231
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.4.1
Hardware: PC Linux
: P2 normal
Target Milestone: 3.4.2
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-08-02 19:25 UTC by Curtis Smith
Modified: 2017-01-13 18:26 UTC (History)
4 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Curtis Smith 2016-08-02 19:25:18 UTC 
In module URIDNSBL.pm

When Net::DNS returns a resource record, especially for domains with really long names, the RR has parentheses in the results. Routines complete_ns_lookup and complete_a_lookup don't handle the parentheses very well.

For example:
Instead of returning

hostname.org. IN A 192.168.0.1

sometimes a result returns:

hostname.org. IN A ( 192.168.0.1 )

My fix was to remove the parentheses:

*** URIDNSBL.pm.orig    2016-08-02 14:37:56.131847168 -0400
--- URIDNSBL.pm 2016-08-02 15:12:28.534143316 -0400
***************
*** 942,947 ****
--- 942,948 ----
      next unless (defined($str) && defined($dom));
      dbg("uridnsbl: got($j) NS for $dom: $str");
  
+     $str =~ s/[()]//g;
      if ($str =~ /IN\s+NS\s+(\S+)/) {
        my $nsmatch = lc $1;
        $nsmatch =~ s/\.$//;
***************
*** 1026,1031 ****
--- 1027,1033 ----
      dbg("uridnsbl: complete_a_lookup got(%d) A for %s: %s", $j,$hname,$str);
  
      local $1;
+     $str =~ s/[()]//g;
      if ($str =~ /IN\s+A\s+(\S+)/) {
        $self->lookup_dnsbl_for_ip($pms, $ent->{obj}, $1);
      }
Comment 1 Benny Pedersen 2016-08-02 19:40:38 UTC 
what dns server do this ?
Comment 2 Benny Pedersen 2016-08-02 20:49:41 UTC 
; <<>> DiG 9.10.3-P4 <<>> hostname.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55936
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;hostname.org.			IN	A

;; ANSWER SECTION:
hostname.org.		236	IN	A	104.24.97.69
hostname.org.		236	IN	A	104.24.96.69

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: tir aug 02 21:47:33 BST 2016
;; MSG SIZE  rcvd: 73

unless you can provide what dns server that does it, it will be possible be marked as invalid
Comment 3 Curtis Smith 2016-08-02 21:01:12 UTC 
It's not a DNS server. It Perl. Perl craziness. And it's Perl/Net::DNS specific.

Here's an sample

$ ./sample.pl
1.01
www.associationofconstructionanddevelopment.net.        300     IN      A      ( 
        104.18.61.69 )
www.associationofconstructionanddevelopment.net.        300     IN      A      ( 
        104.18.60.69 )

code:

use strict;

use Net::DNS;
print Net::DNS->version, "\n";

my $res = Net::DNS::Resolver->new;
my $reply = $res->search('www.associationofconstructionanddevelopment.net');
if ($reply) {
        foreach my $rr ($reply->answer) {
                next unless ($rr->type eq 'A');
                print $rr->string, "\n";
        }
}

When I run this on my Ubuntu 16.04 host, with Net::DNS version 0.81, it does not happen:

$ ./sample.pl
0.81
www.associationofconstructionanddevelopment.net.        277     IN      A      104.18.60.69
www.associationofconstructionanddevelopment.net.        277     IN      A      104.18.61.69
Comment 4 Benny Pedersen 2016-08-02 21:25:48 UTC 
1.04
www.associationofconstructionanddevelopment.net.	24	IN	A	( 
	104.18.61.69 )
www.associationofconstructionanddevelopment.net.	24	IN	A	( 
	104.18.60.69 )

; <<>> DiG 9.10.3-P4 <<>> www.associationofconstructionanddevelopment.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 155
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.associationofconstructionanddevelopment.net. IN A

;; ANSWER SECTION:
www.associationofconstructionanddevelopment.net. 24 IN A 104.18.61.69
www.associationofconstructionanddevelopment.net. 24 IN A 104.18.60.69

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: tir aug 02 22:20:00 BST 2016
;; MSG SIZE  rcvd: 108


same happen on gentoo

this perl module needs fixing
Comment 5 Benny Pedersen 2016-08-02 21:45:30 UTC 
https://bugs.gentoo.org/show_bug.cgi?id=590338
Comment 6 Mark Martinec 2016-08-02 22:31:50 UTC 
The bug is in the SA plugin, it uses $rr->string instead of $rr->address.

In old version of Net::DNS these happened to produce the same thing,
but need not.
Comment 7 Benny Pedersen 2016-08-02 22:39:05 UTC 
the sample.pl here does not use spamassassin
Comment 8 Mark Martinec 2016-08-02 22:50:15 UTC 
(In reply to Benny Pedersen from comment #7)
> the sample.pl here does not use spamassassin

... but it uses $rr->string for type A record.
The string() method produces a valid dns zone file syntax,
which may or may not include parenthesis.

To obtain an address from a record of type A or AAAA,
the proper method is $rr->address. Some parts of
SpamAssassin have already been adjusted to do the right
thing, unfortunately not all, or so it seems.

It is unfortunate that old version of Net::DNS
did not provide a method address(), so fixing it involves
some compatibility measures.
Comment 9 Benny Pedersen 2016-08-02 23:57:56 UTC 
it was now clear to me why i have long time not seen any uridnsbl hits here, when i changed from spamassassin to rspamd i could see this was not a local dns problem i had, so goodt to find this is possible the problem in spamassassin here
Comment 10 Mark Martinec 2016-08-03 15:50:14 UTC 
Actually this has all been fixed in the trunk version since about
a year ago. It would probably make sense do backport to 3.4(.2).
Comment 11 Marcin 2016-08-29 11:26:33 UTC 
(In reply to Mark Martinec from comment #10)
> Actually this has all been fixed in the trunk version since about
> a year ago. It would probably make sense do backport to 3.4(.2).

And the all SA 3.4.x users are missing for this backport:)
Comment 12 Bill Cole 2017-01-13 18:26:45 UTC 
Bug #7231 includes patches that have been applied to both the 3.4 branch and trunk to use the Net::DNS::RR methods available (rdatastr or address) to avoid the need to parse a text representation in zonefile format of the full DNS RR, which is inherently fragile.

*** This bug has been marked as a duplicate of bug 7231 ***