Skip Menu |

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

Report information
The Basics
Id: 84553
Status: rejected
Priority: 0/
Queue: Net-DNS

People
Owner: Nobody in particular
Requestors: thomas.sturm [...] yahoo.de
Cc:
AdminCc:

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



Subject: Fatal error upon invalid SPF record
Date: Wed, 10 Apr 2013 17:16:44 +0200
To: bug-net-dns [...] rt.cpan.org
From: Thomas Sturm <thomas.sturm [...] yahoo.de>
There is a domain with a SPF record like mydomain.com. 3600 IN TXT "v=spf1 include:.anotherdomain.com ~all" This is obviously invalid, but things like that happen out there. Now there is a mailserver, which is checking SPF records using some perl daemon, which is using Mail::SPF. For this, Mail::SPF then performs DNS lookups using Net::DNS. This fails with a record like above, and, end of the story, the perl daemon crashes. I tried to find out where exactly the fatal operation is performed, and by sniffing the TCP traffic between postfix and the perl daemon, it turned out this happens in Net::DNS::Packet. Please see the full trace below: *** FATAL PROGRAM ERROR!!\x09Unknown method 'default'\x0a*** which the program has attempted to call for the object:\x0a***\x0a*** ; EDNS Version \x09 UDP Packetsize: IN\x0a; EDNS-RCODE:\x09 ()\x0a; EDNS-FLAGS:\x090x0000\x0a\x0a***\x0a*** This object does not have a method 'default'. THIS IS A BUG\x0a*** IN THE CALLING SOFTWARE, which incorrectly assumes that the\x0a*** object would be of a particular type. The type of an object\x0a*** should be checked before calling any of its methods.\x0a at /usr/lib/i686-linux-thread-multi/Net/DNS/Packet.pm line 183\x0a\x09Net::DNS::Packet::data('Net::DNS::Packet=HASH(0x86dadc8)') called at /usr/lib/i686-linux-thread-multi/Net/DNS/Resolver/Base.pm line 500\x0a\x09Net::DNS::Resolver::Base::send('Net::DNS::Resolver=HASH(0x86d3db0)', 'mta.mydomain.com', 'TXT') called at /usr/lib/i686-linux-thread-multi/Mail/SPF/Server.pm line 564\x0a\x09Mail::SPF::Server::dns_lookup('Mail::SPF::Server=HASH(0x83d3ee0)', 'mta.mydomain.com', 'TXT') called at /usr/lib/i686-linux-thread-multi/Mail/SPF/Server.pm line 461\x0a\x09Mail::SPF::Server::__ANON__() called at /usr/lib/i686-linux-thread-multi/Error.pm line 419\x0a\x09eval {...} called at /usr/lib/i686-linux-thread-multi/Error.pm line 411\x0a\x09Error::subs::try('CODE(0x86da9b8)', 'HASH(0x86daae8)') called at /usr/lib/i686-linux-thread-multi/Mail/SPF/Server.pm line 470\x0a\x09Mail::SPF::Server::select_record('Mail::SPF::Server=HASH(0x83d3ee0)', 'Mail::SPF::Request=HASH(0x86d4110)') called at /usr/lib/i686-linux-thread-multi/Mail/SPF/Server.pm line 323\x0a\x09Mail::SPF::Server::__ANON__() called at /usr/lib/i686-linux-thread-multi/Error.pm line 419\x0a\x09eval {...} called at /usr/lib/i686-linux-thread-multi/Error.pm line 411\x0a\x09Error::subs::try('CODE(0x86da1d8)', 'HASH(0x86da668)') called at /usr/lib/i686-linux-thread-multi/Mail/SPF/Server.pm line 344\x0a\x09Mail::SPF::Server::process('Mail::SPF::Server=HASH(0x83d3ee0)', 'Mail::SPF::Request=HASH(0x86d4110)') called at /usr/bin/policy-spf.pl line 263\x0a\x09main::sender_policy_framework('attr', 'HASH(0x8305940)', 'cache', 'HASH(0x86d42e0)') called at /usr/bin/policy-spf.pl line 168.\x0a
From: rwfranks [...] acm.org
On Wed Apr 10 11:17:05 2013, thomas.sturm@yahoo.de wrote: Show quoted text
> There is a domain with a SPF record like > mydomain.com. 3600 IN TXT "v=spf1 > include:.anotherdomain.com ~all" > > This is obviously invalid, but things like that happen out there. >
The trace indicates that this was a failure to construct a query packet caused by OPT.pm either missing or apparently not loaded. There is a growing suspicion that constructs like eval{ ... }; if ($@) { ... } is unsafe when using threads. As a precaution, this has been written out of the module loading code in RR.pm. We cannot be certain that this will solve the problem. What we can be certain about is that this has nothing to do with the correctness, or otherwise, of the SPF information in a TXT record. Net::DNS regards that as a text string, and knows nothing about SPF processing. There is too little hard evidence to justify keeping this bug report open. However, if the problem reappears using 0.73, please raise another report with complete supporting evidence.