Interesting DNS Behaviour

[Kevin Darcy]

Thomas H Jones II wrote:

> I know this will probably result in a "well DUH" type of response, but
> I needed to post any way...
>
> Recently, I received some SPAM emails. While going through the process
> of tracking down who might have actually sent it, i went through the
> following sequence:
>
> $ whois -h whois.arin.net 66.205.218.24
> E Broadband Now Inc. EBROADBANDNOW (NET-66-205-192-0-1)
>                                   66.205.192.0 - 66.205.223.255
> Race Technologies NTBLK-RACE1 (NET-66-205-218-0-1)
>                                   66.205.218.0 - 66.205.218.255
>
> Since the logs indicted that the address may be forged, even though
> it did not show any hostnames:
>
>         from mx3.finehost.net ( [66.205.218.24] (may be forged))
>                                ^
> (I didnt immediately notice the " " between the opening paren and the
> opening square bracket). So, I did an nslookup on the IP:
>
>    $ nslookup 66.205.218.24
>    Server:  ns2.xanthia.com
>    Address:  199.248.145.12
>
>    Name:
>    Address:  66.205.218.24
>
> I was a bit taken aback at this 'null' response. So, i randomly checked
> IPs withing the netblock that the original IP belonged to. Same results.
> I was thinking, "ok, this is odd, maybe I should complain to their DNS
> admins and possibly their parent network provider". Then it occurred to
> me that both netblocks were run by the same people. Sure enough, I checked
> some IPs in the parent network and got the same behaviour.
>
> I couldnt immediately figure out why someone would bother to set up
> "PTR ." records for reverse lookups, rather than just leaving them blank.
> Then it occurred to me: some MTA's will refuse to accept emails if they
> cannot get a PTR lookup response. This would allow SPAMmers to get by
> such rules. Further, it would be somewhat challenging to write a regex
> based rule for stopping mails from 'null' sources.
>
> This all seems RATHER unfriendly. Somehow strikes me that "." should
> not be a valid value for a PTR record.

It's bad protocol practice to have special, content-specific restrictions
like that. Your "cure" is worse than the disease.

The root (excuse the pun) cause of this problem is the use of PTR records as
a form of "authentication" by mail servers. Obviously the spammers are
getting more sophisticated as time goes by; they'll all have the necessary
PTRs in place before too long, at which time the PTR-existence check will
just end up being a gigantic waste of time and resources.


- Kevin