REVERSE DNS Practices.
schampeo at hesketh.com
Fri Mar 27 22:03:09 UTC 2009
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
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.
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/
More information about the NANOG