on Thu, Dec 10, 2009 at 07:43:36AM -0800, Dave CROCKER wrote:
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?
That draft has a few issues; perhaps foremost is the Anglocentric choice of names. Why should a Pole care to name his poczta "mail"? Or a Brazilian name his "correio" using an English term? But that's a minor point, and there aren't *that* many variations on "mx" vs "mail" vs "smtp", etc in non-English languages. If anything, I'd have liked to have seen a more widespread use of the protocol as a canonical name for a box providing service for that protocol, but www's ship sailed a long time ago... M. Sullivan's proposals for the most part, however, conform to the best of current practice as far as I can determine from having looked at several hundred thousand hosts and tens of thousands of naming conventions over the past few years. There are probably ways the proposals could be expanded to cover other edge cases or to conform to current practices (properly naming NATs, VPN hosts, University resnets, "vps" instead of "shared", perhaps, dealing with "cloud" computing, Web and other proxies). And there are certainly plenty of other network situations that might be covered in a future draft, certainly more than I could describe here. The bottom line is that people *are* using rDNS/PTR naming as a means to help them determine policy. It's not abstract, it's happening. I'd love to see some way to define emission policies for a given netblock that could be queried in real-time, by the receiving services, but I suspect that's a long way off. Until then, clear and informative labeling is the best way to go. Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/