on Thu, Mar 26, 2009 at 01:22:17AM -0400, Steven Champeon wrote: > on Thu, Mar 26, 2009 at 10:26:59AM +1030, Tom Wright wrote: > > Don't be afraid to create zones for each > > location, DNS lends itself to this kind of > > hierarchy naturally. > > > > I find this is tidier than lengthy A records. > > > > I.e, hostname.location.domain > > And yet makes it more difficult for anyone else to simply set > aside ALL of your dynamics as offlimits using simple substrings > (say, in sendmail's access.db or using postfix check_client_access). > > Don't be that guy. > > > W: http://www.internode.on.net > > Oh, yeah. You already are (quick! guess which of these are actually > dynamic, and which static, who's residential, who's business, etc.):
As there seems to have been some misunderstanding as to what I was advocating, to the extent that some people have accused me of calling Tom and Internode out for criticism for their leaky network, etc. etc., I'll try to explain again. Due to the botnet problem, generic reverse DNS is a useful indicator of the risk involved in accepting email from a given source. I have a large (~36K patterns) collection of regexes that attempt to classify said rDNS into assignment type and various other subtypes, as well as the technology in use, on the grounds that certain types of names are highly correlated to spambot-infected hosts, or their relative likelihood of being/staying infected, anyway. I personally don't care if every ISP on the planet uses vague and uninformative PTR naming, as long as they do so consistently. It's actually in my interest to have the names be impenetrably obtuse, as we license the patterns to various appliance and reputation service providers and ISPs, etc. I am also aware, however, that many folks do not have such a collection of regexes for classified PTR naming conventions, and so whenever the subject of naming comes up, I try to point out reasons why there are best practices that should be followed, if only for the sake of mail admins being able to collectively block all mail from dynamics or generics on a certain source network in a reliable manner. First among those practices is to indicate dynamicity /first/; in Tom's example, you might even set up zones for each of your allocations - one for dynamics, and one for statics. What Tom was actually recommending, though, was to use geographies as the first (rightmost) token, which while it may have certain merits in offloading management responsibility, makes it difficult for everyone else, as it multiples the number of substrings you need to throw into your MTA filtering config. When I mentioned "spewing spam and viruses", I wasn't necessarily singling out Tom or Internode for irresponsibility, and as it turns out their volumes here are relatively low compared to others (and may, in fact, be the fault of customers whose networks they don't control at all, if they're all statically assigned). I was merely saying that it will be much more favorably received by a mail admin who is seeing high volumes of crud from a given network if said admin can block it all with one rule, instead of having to collect dozens. Nonetheless, there are inconsistencies in the on.net naming; some hosts have 'static' as a token, some others are apparently static but lack that token, and so forth. So, if I've looked at millions of hostnames and classified tens of thousands of patterns and I can't tell whether a given host is static or dynamic, I can't expect someone with little experience in global DNS label/token meanings to be able to, either. In the subsequent thread, we saw that Internode port blocks outbound 25, so some substrings I had considered dynamic may well not be. I've asked for more information and hope that I can correct my classifications. Given that most of my patterns came from hostnames who've tried to send me spam, it may be that my patterns pre-date their port 25 blocks. I have no way of knowing. I've got patterns going back six years or more, and just because I have a pattern doesn't mean I've seen traffic from a host matching the pattern recently. We also saw that padsl could mean "personal ADSL", or "private access DSL / VPN"; that "LNS" may be a network management tool, an L2TP Network Server, or a PPPoE node served *by* that server, and may well mean something else entirely (Lancaster Airport, Laboratory for Nuclear Science, and so forth). The main point still stands: clarity in naming, especially of end user nodes, is important. If I gave anyone the wrong impression about Tom or Internode, or their relative responsibility as network operators, I apologize. I had no such intent. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
