You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2009/11/05 17:41:30 UTC

[Bug 6232] New: Net::DNS inconsistent in use of presentation/wire format in packets, breaks DnsResolver

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6232

           Summary: Net::DNS inconsistent in use of presentation/wire
                    format in packets, breaks DnsResolver
           Product: Spamassassin
           Version: SVN Trunk (Latest Devel Version)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Libraries
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: Mark.Martinec@ijs.si


As Warren Togami reported, URIBL queries with non-ascii labels break the
DnsResolver.pm. The effect is that when an answer packet is received from
a resolver, its query section fails to match the id with which we created
and remembered the query and the reply packet is ignored, while the query
is still pending until it eventually times out, without providing an answer.
This delays URIBL resolving up to rbl_timeout seconds.

The core of the problem seems to in Net::DNS, which is inconsistent in
its choice between raw (wire) bytes vs. ascii-ized (presentation) form
for data in its Net::DNS::Packet object, specifically in its 'question'
field. It allows a caller to supply arbitrary bytes when creating
a packet (which is fine, DSN is fully transparent for any bytes),
but when an answer packet is received, it ascii-izes its query section
and stores it in the object, instead of keeping it in the raw format.

The following test program illustrates the problem, displaying the
first (the only) entry in the 'question' section, both for our generated
query packet, and also for the question section of a reply packet:

#!/usr/bin/perl
use strict;
use Net::DNS;
sub query($) {
  my($query_domain) = @_;
  my($packet) = Net::DNS::Packet->new($query_domain, "A", "IN");
  my($res)    = Net::DNS::Resolver->new;
  my($answer) = $res->send($packet) or die "send failed: $!";
  printf("\n%s\n", $query_domain);
  printf("query: %s\n", ($packet->question)[0]->qname);
  printf("reply: %s\n", ($answer->question)[0]->qname);
}
query("example.jp.multi.uribl.com");
query("\xE6\x97\xA5\xE6\x9C\xAC\xE8\xAA\x9E.jp.multi.uribl.com");

and the result:

  example.jp.multi.uribl.com
  query: example.jp.multi.uribl.com
  reply: example.jp.multi.uribl.com

  æ¥æ¬èª.jp.multi.uribl.com
  query: æ¥æ¬èª.jp.multi.uribl.com
  reply: \230\151\165\230\156\172\232\170\158.jp.multi.uribl.com

The first one is fine, the question section on the answer packet exactly
matches the question section of a query packet. The second case is a
mismatch, the question section of an answer packet has characters
converted into their *decimal* code (which is a habit in DSN zones).

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6232] Net::DNS inconsistent in use of presentation/wire format in packets, breaks DnsResolver

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6232

--- Comment #2 from Mark Martinec <Ma...@ijs.si> 2009-11-05 09:04:45 UTC ---
Here is a quick and ugly fix, for the time being:

--- lib/Mail/SpamAssassin/DnsResolver.pm        (revision 833030)
+++ lib/Mail/SpamAssassin/DnsResolver.pm        (working copy)
@@ -317,7 +317,7 @@
   $self->connect_sock_if_reqd();
   my $packet;
   eval {
-    $packet = Net::DNS::Packet->new($host, $type, $class);
+    $packet = Net::DNS::Packet->new(Net::DNS::stripdot($host), $type, $class);

     # a bit noisy, so commented by default...
     #dbg("dns: new DNS packet time=%s host=%s type=%s id=%s",


Bug 6232, a quick workaround hack to Net::DNS inconsistency
Sending        lib/Mail/SpamAssassin/DnsResolver.pm
Committed revision 833081.

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 6232] Net::DNS inconsistent in use of presentation/wire format in packets, breaks DnsResolver

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6232

Mark Martinec <Ma...@ijs.si> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Undefined                   |3.3.0

--- Comment #1 from Mark Martinec <Ma...@ijs.si> 2009-11-05 08:49:57 UTC ---
A possible trick is to convert our query domain into its presentation form
when creating a Net::DNS::Packet object, by using undocumented procedure
presentation2wire or stripdot in Net::DNS.  The following change
to the above test program appears to provide consistent results:

query(Net::DNS::stripdot(
  "\xE6\x97\xA5\xE6\x9C\xAC\xE8\xAA\x9E.jp.multi.uribl.com"));

result:
  \230\151\165\230\156\172\232\170\158.jp.multi.uribl.com
  query: \230\151\165\230\156\172\232\170\158.jp.multi.uribl.com
  reply: \230\151\165\230\156\172\232\170\158.jp.multi.uribl.com

Now, the question is, what was meant by authors of Net::DNS.
To me it seems more logical to keep raw bytes in the Net::DNS::Packet
object, and do the decoding/encoding in the interface routines
if necessary. If that is indeed the case, the above workaround
would break this, and a potential fix to Net::DNS could break our
workaround.

Do we have any contacts with Net::DNS guys?

-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.