Subject: [Asrg] 7. BCP. Proposal... dynamic-address-specific rDNS

From: "Walter Dnes" <[email-masked]>
Date: Fri, 14 May 2004 01:12:52 -0400

My ISP allows customers to configure their own smtp-stage filters.  At
first, I figured that DNSbls were the FUSSP.  However, there was a lot
of spam leakage through my filters.  DNSbls are part of the solution,
but not the entire solution.  Additional options have appeared in the
filter rules.  The two most effective ones are blocking of email from
sites with...
  - no/none/zip/zilch/nada rDNS (host/nslookup returns NXDOMAIN)
  - regexp filtering for dynamic-IP-like rDNS, ie...
    [0-9]+-[0-9]+-[0-9]+
    \.dial
    dhcp

  As a single user, my sample size is quite small.  Up to May 12th, my
rules had blocked a grand total of 263 email attempts so far this month.
Lack of hostname accounted for 113, and dynamic-IP-like rDNS stopped 64.
That's just over 2/3rd of all blocking.

  Residential dynamic IP addresses are growing at an explosive rate.
DNSbls have a hard time keeping up with them.  Spam zombies are cranking
out direct-to-MX email in record numbers.  This is currently a very
large part of the unwanted promotional/soliciting email problem, aka
spam.  Blocking this avenue for spammers isn't the FUSSP, but it will
make a major dent in the current problem.

  Therefore, I propose that ISPs assign all dynamic IP addresses an rDNS
that includes a recognizable identifying substring such as "dynamic".
There may be adverse side-effects I'm not aware of with total lack of
rDNS.  If not, null rDNS would be just as good.

  Advantages...

  - no structural changes required to DNS or SMTP, just doing things
    slightly differently.  That's why I'm presenting the idea as a BCP
    proposal rather than in another area.

  - because this proposal merely calls for changes in the practices with
    the current DNS system, there is no need for a new registration or
    certification beauracracy

  - no load on outbound routers/gateways, unlike outbound port-25
    blocking

  - it would also work against assymetric routing attacks which outbound
    port-25 blocking is useless against.  To achieve the same protection
    an ISP would have to block port 25 *IN AND OUTBOUND* to/from
    residential dynamic IP addresses.  The technical requirements, and
    costs of two-way blocking can be significant

  - the receiving ISP can decide whether or not to block inbound email
    from such addresses

  - unlike RMX/SPF, this can be implemented by one ISP and its outbound
    email would be checkable immediately.  There are already a lot of
    email servers that can check rDNS addresses of incoming email.  AOL
    already does this by labeling their dynamic IP addresses with an rDNS
    that includes the string "ipt.aol.com".

  - valid email "From:" personal domains will not be blocked when sent
    via the ISP's MTA, which might be an issue under some implementations
    of RMX/SPF

  - unlike ordinary DNSbls, DOS-attacks can't shut down this system,
    short of taking down DNS entirely.  In that case, email is shut down
    too, because sending systems can't resolve MX IP addresses.

  - ordinary DNSbls of dynamic IP addresses have problems keeping up
    with the growth of new blocks of IP addresses.  My proposal would
    simply "just work".

  Comments, etc ?

-- 
Walter Dnes <[email-masked]>
Email users are divided into two classes;
1) Those who have effective spam-blocking
2) Those who wish they did

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 14 May 2004 11:27:46 -0400

> rDNS.  If not, null rDNS would be just as good.

Take a look at the following:

http://www.ietf.org/internet-drafts/draft-lorenzen-marid-mxout-00.txt

Keep in mind the following:

http://www.ietf.org/internet-drafts/draft-stumpf-dns-mtamark-01.txt

There is also a proposal floated by Phil Hallam Baker expanding on MTA MARK.

Yakov
--
Yakov Shafranovich / asrg <at> shaftek.org
SolidMatrix Technologies, Inc. / research <at> solidmatrix.com
"And this too shall come to pass"

---

From: "Mark E. Mallett" <[email-masked]>
Date: Fri, 14 May 2004 17:55:51 -0400

> There is also a proposal floated by Phil Hallam Baker expanding on MTA MARK.

Those are in the same universe as a naming standard for dynamically
assigned IP addresses, but not the same thing.  I think a dynamic-IP
RDNS naming standard would be a positive thing.  It wouldn't
necessarily cure anything, but a reasonable BCP recommendation for
this would encourage providers to adhere to a well-known naming system
for this one specific thing rather than everyone coming up with
something different; and this practice would help others (such
as filter users).

I think the string needs to be a little more formally specified than
just including the substring "dynamic" though-- that's too much of a
common word.  If it specifically matched the IP number in some way,
the name could be tested against the IP number to give an assurance
that one has found a self-declared dynamic IP address.  e.g., something
like: for any IPv4 IP address canonically represented by a.b.c.d, the
leftmost part of the RDNS name shall match the string "a-b-c-d-dynamic."

mm

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 14 May 2004 17:24:10 -0700 (PDT)

> leftmost part of the RDNS name shall match the string "a-b-c-d-dynamic."

Actually I've been thinking about this for a while as well as testing 
various forms and records in rdns. Take a look the following idea given
in example manner:

------------------------------------
$ nslookup -query=ANY -silent 216.151.192.3

3.192.151.216.in-addr.arpa      name = rdns1.elan.net.
3.192.151.216.in-addr.arpa      name = 
_smtp._tcp._sir.maintest.192.151.216.in-addr.arpa.

$ nslookup -query=ANY -silent _smtp._tcp._sir.maintest.192.151.216.in-addr.arpa.

Name:   _smtp._sir.maintest.192.151.216.in-addr.arpa
Address: 127.0.0.2

_smtp._tcp._sir.maintest.192.151.216.in-addr.arpa    text = "v=spf1 -all"
------------------------------------

In this case the idea is to specify additional dns pointer record (but not 
primary one - there are very good reasons why ISP may want to use its own 
specific naming convention for its reverse ips, its bad idea to specially
say you must name it that way) in a special way. I preliminary called it
"service information record pointer" which provides pointer on where 
additional information maybe obtained regarding outgoing service 
connections that may (or may not) be expected from that ip. That service
maybe provided by SRV or similar future protocol or maybe through some
form of dns authorization protocol (SPF is used in my example).

Additionally specific meaning is given to "A" record for such PTR record
which may be 127.0.0.1 meaning such connections are to be expected from
that ip (which is default) or 127.0.0.2 which indicates that ip would
not make outgoing connections like that and if you see it, you can safely
deny it (i.e. expect that either ip is not authorized to do what it does
or that the actual ip packet is forged, though this might have more meaning
for udp services).

Now the good thing about this is that doing it as above requires 0 changes
to network infrastracture and pretty easy to implement at the SMTP server
level to check for such records and connections can be rejected before SMTP
session even starts, it does however require additional dns lookup (i.e. 
when you see a pointer with _sir, it thereafter must be resolved).

Another option I played around with is here:
--------------
$ nslookup -query=ANY -silent 2.192.151.216.in-addr.arpa.

2.192.151.216.in-addr.arpa      name = unix.elan.net.
2.192.151.216.in-addr.arpa      text = "v=spf1 ptr -all"

Name:   2.192.151.216.in-addr.arpa
Address: 127.0.0.5
--------------

In this case TXT and A records are entered directly in addition to PTR to 
specific IN-ADDR record. The good thing about this is that it requires
no additional dns lookups since doing query on "ANY" record will provide
all of it and many mail servers already do lookup on PTR record of 
incoming ip address. However at the same time it can be noted that ANY
lookup for in-addr is unusual and most dns resolver libraries would 
interpret lookup on ip address (i.e. 216.151.192.2 in this example) as 
lookup of PTR on in-addr of that ip address:

--------------
$ nslookup -query=ANY -silent 216.151.192.2
Server:         216.151.192.1
Address:        216.151.192.1#53

2.192.151.216.in-addr.arpa      name = unix.elan.net.
--------------

Such interpretation means additional records (TXT and A) would not be 
checked and mail servers must be modified to do its own conversion of ip 
address into inaddr form for lookup. It also means quite a number of 
basicly the same kind of records may have to be entered as you can't
provide cname redirection, which btw also breaks RFC2317 (not that I 
support this badly thought of RFC). But at the same time, the PRO to this
direct approach is that there no necessity to do extra dns lookup
(but as people from SPF community will tell you, dns lookups are "cheap",
spf seems to be designed to cause dozen of extra lookups in some cases)

Anyway I'm the point that I actually started working on draft on the first
PTR procedure (very slow so far, this has been low priority among many 
research and public projects I get involved in). I guess I'm asking to 
know if you think this is actually worth doing because there seems to be 
so little support for MTA-MARK like proposals from anti-spam and marid 
community which contines to be focused on rmx and dmp methods.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Seth Breidbart <[email-masked]>
Date: Fri, 14 May 2004 20:02:17 -0400 (EDT)

The problem with specifying dynamic is that it isn't what we care
about.

Really, I don't care if an IP address is dynamic, however that's
defined.  (Changes daily?  weekly?  There are DHCP-assigned addresses
that change less often than some supposedly "fixed" IP addresses.)
What I care about is whether or not the IP address owner thinks that
email should ever emanate from that IP address.

For instance, I'd want "This is a webserver that's not supposed to
emit email directly" on the list, while "This is a business-class
service customer who is welcome to emit email directly" not to be on
the list.

The general case, of course, is to list precisely which protocols the
IP address ought (not) to be initiating in general; one possible
reason for handling this via something suggestive (rather than just
blocking the port) is to allow sufficiently-clued servers to accept
connections (with authentication, perhaps) even though the general
case is otherwise.

Besides, when I'm feeling sufficiently paranoid, I'll do things like
run sshd on Port 25 with a banner that looks like a mailserver, just
in case somebody finds an exploit against the version of sshd I'm
running, how likely are they to try it against every mailserver they
see?

Seth

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 15 May 2004 19:29:51 +0200

On 2004-05-14 17:24:10 -0700, william(at)elan.net wrote:
> incoming ip address.

Unfortunately, no. ANY just means "any", not "all". If a DNS cache (at
least bind, but I suspect others work the same) receives a request of
type ANY, it will return the records it has in its cache, if there are
any, and only forward the query if there are no matching records. For
example:

$ dig -x 216.151.192.2
    ;; QUESTION SECTION:
    ;2.192.151.216.in-addr.arpa.    IN      PTR

    ;; ANSWER SECTION:
    2.192.151.216.in-addr.arpa. 86400 IN    PTR     unix.elan.net.

$ dig 2.192.151.216.in-addr.arpa. any
    ;; QUESTION SECTION:
    ;2.192.151.216.in-addr.arpa.    IN      ANY

    ;; ANSWER SECTION:
    2.192.151.216.in-addr.arpa. 86293 IN    PTR     unix.elan.net.

As you can see, only the PTR record is returned.

$ dig 2.192.151.216.in-addr.arpa. a  
    ;; QUESTION SECTION:
    ;2.192.151.216.in-addr.arpa.    IN      A

    ;; ANSWER SECTION:
    2.192.151.216.in-addr.arpa. 86400 IN    A       127.0.0.5

When we explicitely ask for the A record, we get it, and

$ dig 2.192.151.216.in-addr.arpa. any
    ;; QUESTION SECTION:
    ;2.192.151.216.in-addr.arpa.    IN      ANY

    ;; ANSWER SECTION:
    2.192.151.216.in-addr.arpa. 85960 IN    A       127.0.0.5
    2.192.151.216.in-addr.arpa. 85837 IN    PTR     unix.elan.net.

Now we have get both the A and the PTR (but still no TXT) record.

So to be safe you have to make absolutely sure that all clients of your
caching dns server make only ANY requests (pretty much impossible in the
general case) or explicitely query for any record type you need.

	hp

-- 
   _  | Peter J. Holzer    | I think we need two definitions:
|_|_) | Sysadmin WSR       | 1) The problem the *users* want us to solve
| |   | [email-masked]         | 2) The problem our solution addresses.
__/   | http://www.hjp.at/ |    -- Phillip Hallam-Baker on spam