rDNS naming conventions (was: Re: SORBS Contact)

Thu Aug 10 14:21:45 UTC 2006

on Thu, Aug 10, 2006 at 01:11:50AM -0700, william(at)elan.net wrote:
> 
> 
> >>On Aug 9, 2006, at 1:06 PM, Matthew Sullivan wrote:
> >>
> >>>This is also why I took the time to create:
> >>>
> >>>    <http://www.ietf.org/internet-drafts/draft-msullivan-dnsop-generic-naming-schemes-00.txt>
> 
> The reason I do not like RDNS naming scheme is because it forces
> one particular policy as part of the name.

Fair enough. FWIW, I've seen a wide variety of naming schemes (I've
got a project that collects these as an antispam/anti-botnet measure,
and so far we've got around 16K conventions documented for 11K domains).

I've read and commented on the ID above; I think Mat's heart is in the
right place but his hopes are too high. Not just because his approach is
too English-focused (what of correo for mail? what of other i18n
variants for 'static' or 'dynamic'?) but because I've seen so many bad
examples of people using rDNS for nothing useful at all, I doubt they'll
suddenly wake up and realize "hey! I could have encoded something
useful and meaningful into my PTR!" But it's a start.

Among my favorites are those who feel it necessary to add 'rev',
'reverse', 'ptr', 'ip', etc. to the PTR along with some encoding of the
IP itself. People, we *know* it's a PTR. If we didn't know the IP, we
couldn't have looked it up, so it's rather fruitless to encode it in the
PTR, don't you think? I'm guilty of the same thing, as the IP does
provide a differentiator as well as a way to say "{something}.domain",
or "this IP is not used for anything in particular", but it's still
an area in need of some inquiry.

Ideally, speaking as a mail admin, I'd prefer that any given PTR have
some indication of:

 - the assignment type and duration (short-term pool, long-term dyn,
   static, etc.)
 - the technology in use (dialup, cable, dsl, wireless, etc.)
 - whether it's assigned for 'business' or 'personal' use (yeah, I
   know, lousy distinction, but suggest a better one)

These are all useful for those who have to make judgement calls about
whether to trust output from a given source; this is true regardless of
protocol. It just happens that for some, email is in high relief; for
others, it might be IRC or Web spammers or SMS or ssh dictionary attacks
or whatever. 

Of the 16K naming conventions I've got handy, over 100 refer to IPs
that are labeled in one manner or another as unassigned. Of course,
I collected them from spam I received here, but they're officially not
in use. Thanks! I guess I'll refuse all mail from them.

Over half are classified as 'generic' - namely, there is so little
useful information in them we can't tell whether they're dynamic,
static, residential, dialup/dsl/cable/wireless, or anything. Many,
in fact, just start with 'host' and end with some variant of the
IP address encoded into the PTR. 

Only 682 of ~16K provide us enough information for us to judge them as
plainly 'static'. (There are a few other classifications that may
suggest static assignment, such as 'nat', 'vlan', 'lan', 'colo',
'webhost', etc. but that's just guesswork - 'dhcp' may strongly denote
dynamic, as may 'pool', but we've seen static DHCP as well as static
"pools", whatever they are.) The most popular approach beyond the simple
"host-foo" seems to involve encoding geographic information into the
PTR; after that is perhaps advertising "hosted.by.superwebhost!" or
redundancy "bigisp-foo-bar-baz.dyn.bigisp.net". Worst among those who
actually provide rDNS in SE Asia is probably tm.net.my, who name all of
their customer PTRs 'tm.net.my'. Hm. Maybe encoding the IP in the PTR
ain't such a bad idea after all, especially for tracking down mass
mailing viruses that HELO with the value of their PTR through NATs.

On the bright side, people seem to have mostly woken up to the idea
that if you're going to put static/dynamic identifiers into the PTR,
you need to do it rightwards, rather than leftwards e.g.

 1-2-3-4.east-campus.resnet.dhcp.pool.dyn.miskatonic.edu

rather than

 dyn-pool.dhcp.resnet-1-2.east.3-4.campus.miskatonic.edu

as the former is easily collected in formats such as sendmail's
access.db and doesn't require expensive regex overhead or many, many
entries to cover a single class of listing. I'm definitely seeing a
shift towards the former approach from the latter, though there are
always the jokers like 'dynamic_dsl_client.dsl.gol.net.gy' who woke up
and changed their _s to -s one day this year, but left the positional
aspects as is. And yes, that's the *full name* of the PTR, so at
least you can block it all with an access.db entry.

Your point below about having different schemes for policies in
different realms is on target, but doesn't mitigate the responsibility
of all ISPs to provide some useful information about their services to
remote systems; a well-designed PTR can do that as a first-stage effort
while we wait for $PROTOCOL's $ENHANCEMENT to stop $ABUSE to wend its
way through the standards committees and implementation.

> My preference is that you lookup RDNS name and they do additional 
> lookup when you do need a policy information (this can for example
> be done with SPF record).

My preference is that my first line of defense against botnets and
other outbreaks should be refusing mail from hosts with generic PTRs.
It works very well, and doesn't require the introduction and field
testing of new TXT formats and parsers or other RRs. And for the most
part, user/admin education can quickly mitigate any issues with those
who think that running a mail server as "dyn-1-2.home.consumerisp.net"
is just as good as running as "mail01.$mydomain".

> Others have advocated putting policy record as TXT directly in IN-ADDR
> zone which is ok as well though I think PTR name is better because it
> allows to collect related names together and list with one policy
> (kind of like common static name schemes in fact).

Perhaps.

> >The idea being a common but extensible naming scheme for organisations
> >want to specify generic/generated records rather than go to the hassle 
> >of creating  individual records for each customer/host.
> 
> If you generate a record you might as well generate some other record
> to go along with it, not that difficult.

Except that for every other record you need to touch when you update a
PTR, there's more maintenance overhead and likelihood of error or failure
to do so, so then you end up with out of synch records that people are
relying on for policy decisions, rather than just single out of date
records that people are relying on for policy decisions. <shrug>

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/
rambling, amusements, edifications and suchlike: http://interrupt-driven.com/