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>
Seems like it specifies a bit TOO much detail, but. This is why it says that it is a suggestion and indicated that the level of detail you choose to use is upto you, however if you adopt some of
I'll post this back to NANOG as others are likely to comment similar ways... Michael J Wise wrote: the more specific detail you should use the less specific detail. ie if you follow it you should as a minimum specify static/dynamic. If you want to add more detail like service type, that is your choice, but you shouldn't specify the service types (eg wifi) without specifying static/dynamic (does that make sense?). Also it should be noted that it is a 'suggested naming scheme for generic records' and therefore not intended to be mandatory, further it says you should indicate the hostname of the machine in preference to generic records. 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. Regards, Mat
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. This is absolutely not expendable and incorrect architecture as RDNS is general concept for use with any number and types of protocols. What needs to be done is that policy record is associated with an address or name itself. The record can be a policy for specific protocol or maybe a general records that can support policies for multiple protocols. 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). 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).
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. -- William Leibzon Elan Networks william@elan.net
I'm not picking on William here; his message was just the last I saw in this thread which has gotten way out of hand. I have not discussed this thread with my fellow list admin team members either, though we can do that... But it would make our (the list admin team's) lives easier, as well as the lives of everyone else who reads nanog@, if people would REFRAIN FROM REPLYING to this thread and take it to a forum that specializes in generating bits by flaming about RBLs. Thank you in advance for your forbearance, ---Rob (member of nanog-admin, the nanog@nanog.org list admin team)
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/
On 8/10/06, Steven Champeon <schampeo@hesketh.com> 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 (ops.lists@gmail.com)
on Thu, Aug 10, 2006 at 08:55:37PM +0530, Suresh Ramasubramanian wrote:
On 8/10/06, Steven Champeon <schampeo@hesketh.com> 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/
On 8/10/06, Steven Champeon <schampeo@hesketh.com> 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
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
At 15:47 +0000 8/10/06, bmanning@vacation.karoshi.com 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.
participants (8)
-
bmanning＠vacation.karoshi.com -
Edward Lewis -
Matthew Sullivan -
Nicholas Suan -
Robert E.Seastrom -
Steven Champeon -
Suresh Ramasubramanian -
william(at)elan.net