rDNS naming conventions (was: Re: SORBS Contact)
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
Re: rDNS naming conventions (was: Re: SORBS Contact)
On 8/10/06, Steven Champeon [EMAIL PROTECTED] wrote: 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 There's at least one vietnamese ISP that has / had till recently set localhost as rDNS for all their IPs. -- Suresh Ramasubramanian ([EMAIL PROTECTED])
Re: rDNS naming conventions (was: Re: SORBS Contact)
On Thu, Aug 10, 2006 at 10:21:45AM -0400, Steven Champeon wrote: 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). first... as a draft, it carries ZERO weight. -IF- it becomes an RFC, its targeted status in INFORMATIONAL, e.g no standard of any kind. So no one is going to -force- you to implement it. hum... why does this draft remind me of the (in)famous WKS RR? what is WKS? you know, that RR type that specified the well known services running on/at the particular lable. WKS was depricated, in part due to the fact that black hats would use WKS to groom thair attack profiles. Use of the conventions outlined in this draft would be very useful in building targeted attacks. To paraphrase Randy Bush, I encourage all my competition to implement these guidelines. --bill
Re: rDNS naming conventions (was: Re: SORBS Contact)
At 15:47 + 8/10/06, [EMAIL PROTECTED] wrote: On Thu, Aug 10, 2006 at 10:21:45AM -0400, Steven Champeon wrote: 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: 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). first... as a draft, it carries ZERO weight. -IF- it becomes an RFC, its targeted status in INFORMATIONAL, e.g no standard of any kind. So no one is going to -force- you to implement it. hum... why does this draft remind me of the (in)famous WKS RR? what is WKS? you know, that RR type that specified the well known services running on/at the particular lable. WKS was depricated, in part due to the fact that black hats would use WKS to groom thair attack profiles. Use of the conventions outlined in this draft would be very useful in building targeted attacks. To paraphrase Randy Bush, I encourage all my competition to implement these guidelines. Piling on here ... The effort is to infer the intent of a packet based on ancillary data. The twin dangers here are inference of intent and exposure of the ancillary data. The first part is like asking would I want to have security research done by a company on Glenwood Road or on Shady Lane? (Ya, know shady in security.) Legend has it that one research company moved it's location because of this, or maybe it was a joke that came afterwards. The second part is what ancillary data is exposed. You can require, you can request, or you can assume you won't get the data you need. Sometimes you won't get it because the giver doesn't want the headache of providing it or because the giver is afraid of the ancillary data going to nefarious uses. My point is that inferring intent based on incomplete data is faulty, but it seems to be useable in real life. However, once heuristics get encoded in deterministic algorithms, the results generally are not so good - mostly because the encoding of the heuristics fails. The answer is to include things like RFC 3514, (Note the pub date.) or ancillary data. But the solution of adding ancillary data maybe worse than the disease. This is just one of the hard problems. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Soccer/Futbol. IPv6. Both have lots of 1's and 0's and have a hard time catching on in North America.
Re: rDNS naming conventions (was: Re: SORBS Contact)
on Thu, Aug 10, 2006 at 08:55:37PM +0530, Suresh Ramasubramanian wrote: On 8/10/06, Steven Champeon [EMAIL PROTECTED] wrote: 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 There's at least one vietnamese ISP that has / had till recently set localhost as rDNS for all their IPs. IIRC, that was fpt.vn; they replaced 'localhost' with the incredibly useful: adsl-pool-xxx.fpt.vn adsl-fix-xxx.fpt.vn dialup-xxx.fpt.vn adsl-dynamic-pool-xxx.fpt.vn \d+-\d+-\d+-xxx-dynamic.hcm.fpt.vn host-\d+-xx.hcm.fpt.vn \d+-\d+-\d+-xxx-dynamic.hcm.fpt.vn Yes, the 'xxx's are literals. e.g., $ host 210.245.14.143 143.14.245.210.in-addr.arpa domain name pointer dialup-xxx.fpt.vn. Or it may have been hnpt.com.vn, who replaced it with e.g., adsl.hnpt.com.vn Again, not terribly useful for tracking leakage via NATs. $ host 203.210.213.149 149.213.210.203.in-addr.arpa domain name pointer adsl.hnpt.com.vn. But hey, at least they *have* rDNS, I suppose that's something. I agree that judgements based entirely on rDNS are troublesome. So, too, are the side effects of chemotherapy. But we're trying to save the patient before the miracle cures arrive, and right now email is very, very sick indeed. And rDNS is a useful tool especially in a scoring-based environment. -- 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/
Re: rDNS naming conventions (was: Re: SORBS Contact)
On 8/10/06, Steven Champeon [EMAIL PROTECTED] wrote: on Thu, Aug 10, 2006 at 08:55:37PM +0530, Suresh Ramasubramanian wrote: There's at least one vietnamese ISP that has / had till recently set localhost as rDNS for all their IPs. IIRC, that was fpt.vn; they replaced 'localhost' with the incredibly useful: There seem to be a couple in the area that do it: As of 5 minutes ago: % dig +short -x 203.160.1.3 -x 203.160.1.35 localhost. localhost. inetnum: 203.160.0.0 - 203.160.1.255 netname: VNPT-VNNIC-VN country: VN
