[PLUG] The problem with DNS blacklists...

Michael C. Robinson plug_1 at robinson-west.com
Wed Aug 17 18:16:46 UTC 2011


On Wed, 2011-08-17 at 09:34 -0700, Russell Johnson wrote:
> On Aug 16, 2011, at 11:20 PM, Michael C. Robinson wrote:
> 
> > Is it
> > legitimate for their to be no reverse record when one site is hosted on
> > the IP block of another?
> 
> Unfortunately, there are a lot of DNS admins out there that don't reverse list their forward tables.
> 
> Russell Johnson
> russ at dimstar.net

I think my Postfix implementation uses a third party SPF checking Perl
script already where I question whether SPF checks are simple enough to
do for a should we close the door or not script.  Remember, I'm a Perl
novice where one of my goals is to write something that a fellow Perl
novice would pick up.

To improve my script, I've written a second function and I've moved the
Net::DNS stuff to it.  I have the standard is the IP listed check and
I've added a call to my function when the answer is NO.  I try a
PTR record check on the IP where failing that, the DNS test passes.  
On success, I take the host name answer and do an A record query.  
If the IP I started with for the PTR query shows up when the A 
query is done, there is a match.  If no match and a PTR record exists,
this test fails.

I noticed doing DNS checking that the PTR record is sometimes absurd.
The worst I have seen is localhost.  Is it sensible to reject based on
there being an absurd PTR record?

There is more than just SPF checking, there are encrypted signatures
where you use public key cryptography...  This is beyond simple, but
is there anything I can use???  If I can provide an English explanation
that a novice would be able to follow, I think I can bend the simple
rule a bit.

My other thought is, there has to be an MX record to tell you where to
reply to.  Okay, can I use that information somehow in deciding whether
or not to close the door?  In other words, is it more informative to
look at MX records than PTR records?




More information about the PLUG mailing list