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/