Internet security & antispam
« new pats posted - 20090611 (maintenance pats release) | Main | Links Roundup »
Though there are certain edge cases and complex situations in which DNS name assignment requires some skill and forethought, for those hosts we are most concerned about here - mostly dynamic end user nodes, or "leaf nodes" - the problem is really quite simple. Once you've made the decision to actually provide reverse DNS (PTR) records for your leaf nodes, you have to decide how to dole out responsibility for zones, what information to provide as part of the name(s), who your "audience" is for that quasi-encoded information, how security affects those decisions, and what operational concerns come into play.
As with everything else in human endeavor, the distribution of that rare element known euphemistically as "clue" is uneven at best. Worse, even those blessed with an abundance of "clue" may not be similarly blessed with a broad scope and understanding of the effects their decisions may have on contexts completely out of their control. What may make perfect sense to a NOC netadmin in one organization may be impenetrable gibberish to another with a different skillset or application or context. And what may make an overworked and undervalued mail server administrator happy may well be considered as a breach of corporate security by someone else. And some people, well, let's just say their sense of humor or what is considered clever is pretty much guaranteed to annoy someone else.
Let's use a few examples. My all-time favorite PTR naming convention, by far, has to be this gem from the folks at wobline.de:
dont-blame-admin-its-a-dsl-pool-251-41.wobline.de
They do a similar thing for generic dynamic pools. What I love about this is that is so clearly illustrates the abdication of responsibility on the part of the administrator for any and all abuse coming from their network. Responsibility for abuse they could control, through port blocking, walled gardens, and various other tricks, has been shunted to the recipient - who is expected to ignore it, because after all, the IP has been dynamically allocated and everyone knows those are IPs used by the end user, the customer, and we all know they're the Untouchables of the Internet.
Oh, and instead of simply using dynamic.wobline.de, which one can stick into a sendmail access.db or postfix check_ptr_access hash table, they stuck the last two octets of the IP on the right hand side of the hostname, requiring regular expressions in order to block them wholesale. Thanks, guys!
Another fine example of the use of the DNS for protest, this time of a different sort, comes from alameda.net:
alameda.net.has.not.owned.this.ip.for.more.then.four.years
Yes, for some reason, obviously not that admin's fault, ARIN hadn't updated their records, or someone hadn't properly managed the in-addr.arpa allocation, for several years. Obviously, someone at alameda.net received complaints about IP space they no longer controlled, and wanted to make a statement to that effect. Fortunately, it seems this has finally been fixed. The sample IP I had with that PTR no longer resolves, and whois says currently belongs to Level3.
But more important than protest and humor in the DNS comes an understanding of the basic concepts. A DNS label should point to the resource or resources it identifies, and vice versa, so that an IP can resolve to a PTR, the corresponding A for which hopefully resolves to the IP in question. This is for use in knowing which host corresponds to which IP, for use in many contexts, though our concern here is email abuse. When an ISP chooses to allow very stupid things to happen via their DNS zones, it reflects on their sense of responsibility for the traffic that is emitted from nodes on their networks.
For example, Beam Cable Systems, an Indian firm in Hyderabad, has chosen to assign a single PTR to all, or most, of their end user nodes:
beamcablesystem.in
When you look up the IP for that host, you expect to get a big bucket of cold fail. To your surprise, you actually get the IP 123.176.37.2. The problem with this is that when every other IP in your netblocks also has the PTR beamcablesystem.in, that means that only one IP will not be considered forged by mail systems around the world. Now, one could argue that by deliberately providing recipients of abuse from such systems such clear evidence of the shadiness and unreliability of the sending IPs, you're doing them all a favor. But I think that's the wrong way to read this.
As of mid-May, there were some two thousand IPs listed by the CBL with the PTR beamcablesystem.in. This is admittedly less than four percent of the hosts in their /16 considered actively infected over a period of a few days, or however long the CBL keeps IP data before expiring it. And if they are dynamically assigned (though they also provide services to businesses, with static IPs, it's not clear whether they also provide custom PTRs for those static IPs) it's possible that some of them are being rapidly cycled through by smart bots, so the actual number of hosts infected is impossible to say with certainty.
The problem comes in when someone with an interest in blocking traffic from such infected hosts at the edge of their network, or early in their spam filtering solution, wants to block them efficiently, using their name rather than a possibly stale list of IP addresses in a DNSBL somewhere. By refusing to provide a differentiator between any of their customers, they effectively force us to deny service to all of their customers or accept abuse from the subset of their customers who are infected. Neither is an acceptable solution.
tm.net.my did the exact same thing for a long time, though I'm pleased to say that they seem to have come to their senses. Hopefully, Beam Cable System will as well.
Posted by schampeo at June 11, 2009 2:08 PM