On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote:
As previously noted in this thread, msullivan@sorbs did a fairly good job of documenting this in an RFC draft. I'd say its still the primary goto to point people at for how to do things the "right way".
http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00
The time to pursue something like this in the IETF is when there is a substantial industry consensus that it is the right approach and that the folks supporting it will actually use it.
Are those of you who have participated in this thread willing to conform to the model specified in this draft?
no, as having PTR records in "dot seperated form" could potentially cause confusion with normal ip addresses in case the search domain is the same. we stick to the "must start with an alphabetic and not contain dots" method, as in "a84-22-123-123" not as in 84.22.123.123.bla.cb3rob.com (which actually are also the host names on the devices on those ips in most cases (although customers are ofcourse free to change that after the control has been given over to them in case of rented out servers). as for the rest of it, i really don't see why we should specifically "mark" static space as being static space as it's simply the de-facto standard, anything else (dhcp, radius, etc) is -optional- and requires extra protocols, so just mark dynamic ip space explicitly instead (if anything) It's also a thing that does not "belong" in dns but rather in whois if anywhere at all. RBLs are neither authorised (EU privacy laws anyone?), nor the appointed authority to keep databases on "whats static or not". RIRs -are-, if anyone should maintain a database on such things, i'd be the rirs (which they have, it's called "whois", it just lacks a field that indicates the type of assignment method used. but i guess that would quickly end the "selling point" of such databases, as who needs Trend Micro if either DNS or whois already contained all required data to just make your mailservers check it in real-time. Anyway, i wish Trend Micro all the luck with maintaining their little database in the age of IPv6 and decaying SMTP use anyway (we nowadays prefer methods like skype, msn, jabber for most of our communications, SMTP has been considered end-of-life for the past 5 years or so over here in our companies, guess why, because it hardly ever works, thanks to companies like Trend Micro just making up their own little standards. it's just a bit annoying for customers that happen to want to send SMTP based (legacy) email to parties that use their RBL, that's all, but indeed, their list will rapidly be removed by any party using it that finds out about their "criteria" to be removed (as they seem to add a lot of stuff by default as being dynamic, kinda the wrong way around ;) spam is -not- what will eventually kill all support for smtp (that can be easily solved by adding a header field with a unique password for each contact you have approved, and bouncing everything that doesnt contain one ;), shitty amateuristic RBL lists and graylisting (so your urgent mail arrives 20 minutes late) is what's killing smtp support. the only reason -we- still run it is that RIPE etc do not support other address types in whois and mailinglists (such as nanog) still use it. as it's neither peer to peer anymore, nor real-time (with a lot of parties blocking port 25), nor very certain that your message actually will be delivered anymore. We prefer the pre-approved contact list method anyway, you may notice our emails have this X-CONTACT-FILTER-MATCH: nanog "header" at the bottom, added by our contact-filter software (kinda like procmail but different) as "nanog" happens to be the "super secret password" for this list. business cards etc all contain a unique password, as when you don't know us and we don't know you, you have no business mailing us, same as on skype and msn "contact lists". methods like that could ofcourse be implemented in the protocol SMTP itself and in all the clients so it could become a proper mail header at one point, removing the need for all the other crap that only slows the exchange of mail down and lessens its reliability and doesn't really stop spam anyway ;). we don't feel that: - dns is the proper place to distinquish between address assignment methods - dns should be relevant for SMTP to work anyway - RBLs should be authorative to maintain databases of address assignment methods (although the EU privacy laws take it a bit too far, prohibiting companies in germany where we are from even storing IP addresses in the first place ;) - RBLs are an effective method to stop spam (it stops -some-.. not -all-) - Making SMTP less reliable and less fast is a good way to go forward if we want to keep the SMTP protocol around in the future. - Making it impossible to use SMTP in a peer-to-peer fashion on eyeball networks and therefore not very real-time anymore is a good idea. furthermore, trend micro is simply on crack, thinking that they can force us to practically work for them for free and maintain their list for them. if they want us to update their -product- as that's what it is with our -information- they should simply pay us for the manhours, which they don't, so there. (not to mention that what trend micro is doing is illegal under german law so we cannot cooperate with them on that ;)
d/
--
Dave Crocker Brandenburg InternetWorking bbiw.net
X-CONTACT-FILTER-MATCH: "nanog"