To:
<dnsop@cafax.se>
CC:
<ietf@ietf.org>
From:
"Curtis Kularski" <Curtis@Kularski.net>
Date:
Wed, 12 Sep 2001 23:00:09 -0400
Reply-To:
<Curtis@Kularski.net>
Sender:
owner-dnsop@cafax.se
Subject:
re: My first rough draft of my first I-D
I'm sorry, I forgot the attachment. Here it is. -- Curtis M. Kularski Curtis@Kularski.net http://PERSONAL.C-M-K.COM http://TECH.C-M-K.COM Microsoft Associate Expert http://microsoft.com/windowsxp/expertzone Ask Jeeves AnswerPoint Enthusiast (Bronze level) http://answerpoint.ask.com --
C. Kularski Internet Draft Document: draft-nameconventions-KULARSKI-00.txt Expires: March 2002 September 2001 Additional Naming Conventions for End-user Convenience Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document will describe some naming conventions, that if introduced as standards could make the Internet more user friendly. These conventions will have very little impact on the Internet as a whole, because many of these conventions are already in place. Table of Contents (TODO: complete TOC once document finished) Status of this Memo................................................1 Abstract...........................................................1 Overview...........................................................1 Formal Syntax....................................................... Security Considerations............................................. References.......................................................... Author's Addresses.................................................. Conventions for Convenience Overview This document contains recommended conventions for naming within the DNS system. These conventions should be used to increase the accessibility and overall ease-of-use for the end-user. In addition to helping the end-user, this document is also to make domain administration simpler for administrators, as well as substitute administrators that may replace an organizations administrator. Conventions used in this document In this document, objectives, explanations, and most options are numbered. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Conventions for Simplifying E-mail 1.1) ABUSE alias. The alias “Abuse” used in the form of “Abuse@Foo.com” should be attached to every domain name. The “abuse” alias should be directed to a person that is affiliated with the organization that maintains the e-mail systems for the domain name (ex. The Postmaster of Foo.com) or someone who has the power to investigate hostile e-mail attacks that originate from the e-mail system. If the managing party is a hosting provider, not affiliated with the organization or persons that own the domain name, then the “Abuse” alias should be forwarded to the hosting provider’s own “abuse” address, or to their responsible party handling hostile attacks. The reason for doing so is to decrease the amount of hostile attacks that are originating from domains setup specifically for the purpose of sending SPAM (unsolicited e-mail). As an additional feature of the “Abuse” alias, an auto-responder may be added that contains additional information that can help the end- user prevent SPAM attacks. 1.2) POSTMASTER alias. This document contains information about this alias only to provide additional backing and support of RFC-822 [5]. 1.3) WEBMASTER alias. To be used as a line of communication between the end-users and a website’s development team or support staff. The alias can be useful in receiving reports of system failures from end-users. If other specialized aliases are not setup, then the “WEBMASTER” alias should be used as a “catch all” address for all other inquiries from the website. 1.4) HOSTMASTER alias. To be used as a support alias for the DNS (Domain Name System) Servers / Name Servers residing under the domain name. If standardized Internet-wide, this alias could become helpful in receiving problem reports when something doesn’t work correctly, due to a DNS malfunction. The HOSTMASTER alias SHOULD NOT be used for any purposes not affiliated with DNS management, due to KULARSKI Informational-Expires March 2002 2 Conventions for Convenience the alias’s long standing recognition as a support system for DNS /NS servers. If the domain does not contain any name servers of its own, then the alias SHOULD NOT be used, or should be used in conjunction with an Auto-Responder, with a message stating that the domain contains no name servers and the message should also include additional contact information for how to communicate with the domain’s support staff. 1.5) Banning the “.” (dot) character in e-mail addresses. The dot character is sometimes used to replace the “@” (at) symbol in e-mail addresses when they are stored in a file to be read by a machine. If the dot character is used in the user-name portion of an e-mail address, the part after the dot will be added AFTER the @ sybol. Ex. John.smith@mail.foo.com becomes John@smith.mail.foo.com once converted back into normal text. One of the systems that read e-mail addresses like that is ISC’s BIND DNS, which serves as the DNS server software for some of the Root-Zone servers. BIND is also in use by thousands of other DNS servers which keep the Internet’s DNS system running. When a request is received for an e-mail address that uses the dot character, the request should be rejected. When the application is rejected, a suitable alternative that may be suggested is the same address, but with the dot character(s) being replaced with hyphen character(s), if that type of mechanism is available. In addition to the affect on machines already in place, removal of the dot character from the “username” (part before the @) will help lower user confusion and prevent a small percentage of “bounce- backs” that are handled by SMTP servers. Subdomain Usage Conventions 2.1) The WWW Subdomain. WWW is the most common subdomain used currently on the Internet. The WWW subdomain should only be used for data transmission on the Hyper Text Transport Protocol (HTTP) or Gopher protocols. Normally the content should be produced in some document standard that has been created by the Word Wide Web Consortium (W3C). If a domain isn’t used for the purpose of providing information on the HTTP or Gopher protocols, then the WWW subdomain should exist as an index of services for the domain. The index page should contain an organized list of services offered by the domain, and instructions on how to access those resources. In addition to an index of resources, the page should also contain some type of contact information for the domain, if none is available, then the data from the domain’s WHOIS record is acceptable. The purpose of providing these resources on a domain that would not normally be “worthy” of a WWW subdomain is because most of the Internet’s current audience (end-users) judge whether a domain is “registered” or “active” by visiting the WWW subdomain of that domain. KULARSKI Informational-Expires March 2002 3 Conventions for Convenience 2.2) The FTP subdomain. The FTP Subdomain should be the primary access point for content available for transfer using the File Transfer Protocol. If the FTP protocol is not utilized by the domain it is not necessary to provide the FTP subdomain, because many web- browsers and other software will only check access the FTP subdomain using the FTP Protocol and port 21. 2.3) The MAIL subdomain. The MAIL subdomain should be used for providing information about accessing e-mail, a CNAME record to the POP or IMAP server, the actual IP address of the POP or IMAP server, as the address of an E-mail Gateway, or as a location for additional e-mail tools. When used for providing information about accessing e-mail on the domain, the HTTP protocol and TCP Port 80 should be used. The information provided should include: incoming server address, port and protocol; outgoing server address, port and protocol; the correct format for UserID and Password entry; contact information of the postmaster; and how to deal with any SPAM that may be received on the account. Using the MAIL subdomain as a CNAME record of the existing e-mail servers is not the best utilization of the sub-domain, but it is more useful than the sub-domain not existing. The best way to utilize the MAIL subdomain is an e-mail gateway service. Since most e-mail gateway services run on the HTTP protocol, it is possible to use the sub-domain to provide information for how to access the domain’s e-mail systems. The E- mail Gateway itself should allow users to access their e-mail that is on the POP or IMAP servers, without removing it. Some E-mail Gateway software will also allow for the user to access e-mail on other domains, without interfering with the operation of that domain’s e-mail system. Using such as system gives end-users the ability to not be tied to one e-mail client or computer for accessing e-mail. Additional e-mail tools that may be offered on the MAIL subdomain can include tools for reporting SPAM that was received from that domain. The additional e-mail tools should be accessible on the HTTP protocol, allowing the ability to provide information about accessing the e-mail servers. 2.4) The WAP subdomain. The WAP subdomain should be established and maintained on any domain that offers access for cellular phones, personal digital assistants (PDAs), and other devices that can utilize “The Wireless Web” with the WAP access protocols. The subdomain should serve only documents that are readable by WAP enabled devices. The subdomain hasn’t been necessary in previous years, but now is with the growing number of WAP enabled devices available and in current use. 2.5) The NEWS subdomain. The NEWS subdomain should be used and established for use with NNTP and other Newsgroup servers. Newsgroups and their predecessors (Bulletin Board Systems) are a big KULARSKI Informational-Expires March 2002 4 Conventions for Convenience part of the success of the Internet. Newsgroups are also a powerful communication tool that is used by many of the developers and administrators that help keep the Internet flowing, and it is essential that the systems be easy to find and connect to. Newsgroup servers are normally operated by Internet Service Providers for their clients, but also by companies that use newsgroups as a “communication lifeline”. 2.6) The IPv6 subdomain. The subdomain of IPV6 is already in place in some domains that have access to IPv6 hardware, 6BONE and an IPv6 IP Address block. The IPv6 subdomain MUST only be used by IPv6 Address records (AAAA) attached to active IPv6 IP Addresses. This subdomain can help to distinguish between IPv6 and IPv4 networks during the transition to the new IPv6 system throughout the Internet. This subdomain should contain subdomains below it for HTTP (WWW), FTP, and other traffic. This part of this document should be retired once IPv6 is the standard. 2.7) The LIST or Opt-In subdomain. The LIST or OPT-IN subdomain should be used for Opt-In e-mailing lists. When using either of these subdomains, you SHOULD make a CNAME to the one you plan to use from the other. Establishing a LIST subdomain is simply a convenience for users, it has no real impact on how the systems operate. Most users are used to having all of an organization’s opt- in lists operate in a similar manor. Using the LIST subdomain will allow you to maintain all of the lists in an organized fashion. Instead of creating many problems for the e-mail system by loading it down with new aliases that support various lists, a separate could be added to the LIST subdomain. Rather than having 50 addresses in the form of “listA-post@foo.org” you would be able to use “A-POST@list.foo.org” therefore simplifying the process for the end-users. Subdomain Usage as it applies to IP Addresses specified in RFC 1918 3.1) The LOCAL subdomain. The LOCAL subdomain should be used with the IP Addresses that are covered in RFC1918, regarding IP Addresses for Private Internets. All record types should be supported for use on and under the LOCAL subdomain. The purpose for such a convention is to allow easier access to resources within an organization, by using the DNS system. For organizations that share real IP address by using a NAT Router, or other such IP address sharing systems; this is helpful because on most devices, when an inside user tries to access a resource using the outside address, the device’s HTML/HTTP based management system is all that is accessible. Using this subdomain can lower the amount of traffic going out on the data lines, and can speed up access times for users within the organization. For an average domain it takes less than 300MB of transfer each year for DNS records, but those domains can use that amount of transfer in a single day for HTTP, FTP, E-mail and other servers. For data to be downloaded from a server to a workstation that is sitting beside of it, it takes very little time when using KULARSKI Informational-Expires March 2002 5 Conventions for Convenience its internal address. However, when that same server is accessed by that same workstation using its external IP address, that data MAY have to go out of the building, down the road a few miles (to the ISP) and then back again to the workstation, which takes more time. Glossary SPAM – E-mail that is sent maliciously to many persons, whose e-mail addresses were added to a list and distributed without their express consent. This type of e-mail is normally generated for the purpose of promoting a product or service, normally pornography. Auto-Responder – An auto-mated mechanism attached to an e-mail system that receives messages and then immediately responds with a pre-created document. The system may or may not save a copy of the e-mail for human review. Formal Syntax The formal definition of RFC format is defined in RFC-2223 [2] and Internet Draft instructions are available at [3]. Security Considerations Because these conventions rely on existing technology, no additional risk is added. Item 1.1 helps decrease the threat of a SPAM attack to another domain, therefore improving security. References 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 RFC 2223 3 {I-D instruction page} 4 RFC 1918 5 RFC 822 Author's Address Curtis M. Kularski 219 Best St Phone: 1-704-629-2498 Bessemer City, NC 28016 Email: curtis@kularski.net USA KULARSKI Informational-Expires March 2002 6