INTERNET-DRAFT A. Costanzo draft-costanzo-dns-gl-05.txt AKC Computer Services Corp. Expires: Feburary 2002 August 2001 Definition of the DNS GL Resource Record used to encode Geographic Locations 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. 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. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast, or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. 2. Abstract This document defines the format of a new Experimental Resource Record (RR) namely GL for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code (decimal). This definition deals with associating geographical host location mappings to host names within a domain within a geopolitical area (a country). 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. Costanzo [Page 1] EXPIRES IN SIX MONTHS August 2001 3. Introduction [NOTE: This draft has been modified from its previous draft version specifically for use with Internet Telepony applications and specifically at the request of a number of people including members of the working group & the RFC Editor - all of whom had a number of concerns with the previous version(s) of the draft. Whilst ALL of the concerns have been addressed in version 5, it is the authors hope that the draft may be reconsidered by the working group for publication. The GL resource records usage has been simplified as well. The author welcomes all comments. ] The ideal way to manage and maintain a database of information, such as a geograpic location of an Internet host, is to delegate responsibility to local domain administrators. This document resolves the problem of relating host information within the DNS to geographical locations. This definition has been designed to be easy for the person who administrates DNS for a domain. NOT requiring longitude, latitude and elevation information and merely being able to enter address information, as you would address a postal letter, will mean broad acceptance and use of the GL resource record. By making the location geopolitical, the addressing mechinism should be received well globally. There is a growing demand for postal address information to be listed within a DNS record. Specifically, with the growing use of the public Internet to complete Long Distance telephone calls, there is now a need to know the physical locations of the hops with the final destinations locations position most important to agencies such as police and fire departments for 911 information. The availability of geographical location information will immediately be able to benefit applications in network management, which would enhance and supplement various network tools which currently exist. The Domain Name System is ideally suited to provide geographic location information. The information we desire to make available globally needs to be maintained and updated locally (perfect for DNS). Although there are other location resourse records defined, that attempt to allow location information on host to be stored and distributed, such as LOC and GPOS, none have either gained acceptance on a wide scale or made allowance for location information that is not within the confines of the planet Earth. 4. The GL format GL has the following format: GL 4.1 Rdata Format Rdata has the following format: The format of the RDATA field is two varying length strings separated by a space character. The first, the hierarchical locator, then an address string. Each is quoted (like all strings) only when it has spaces in it, which will never be true for the first string, and almost always for the second. Costanzo [Page 2] EXPIRES IN SIX MONTHS August 2001 4.1.1 The Hierarchical Locator The Hierarchical Locator contains the following components (each separated by a period "."): Country Code - (REQUIRED) The country code specifies the country the host computer resides in, or in the case of an astronomical location other than "S3" (Earth), the country which owns the device and/or machine. The code is a two character fixed length string. These codes are defined in document ISO 3166-1. "US" for United States for example. Postal Zone - (OPTIONAL) This rdata component supplies the postal code (Zip Code) for the location the host computer resides. For countries that have a multi-segmented postal coding system, the segments should be separated by period(s) ".". This field may be omitted only if the country in which the host machine resides does not use a postal coding system otherwise the data MUST be supplied. When all three Hierarchical Locator components exist for an DNS entry, the position being defined is considered to be a "precise position". 4.2 The Visual Address String This string should be entered as you would enter an address on a postal letter within the country specified by the Hierarchical Locator. The country code information MUST NOT be included within the quoted string. This string is always required and must be present in the RDATA field. The visual address string may be used for both visual reference of the physical address as well as by a software application to help determine a more precise location of the host machine (if the Hierarchical Locator lacks sufficient precision). Costanzo [Page 3] EXPIRES IN SIX MONTHS August 2001 The only instance in which any application should attempt to interpret the visual address string is in a case where the country code defines a country that does not use, or has not implemented a postal code system. No software or application should attempt to override a precise position defined by the Hierarchical Locator with information defined within the quoted string data. 5. Example(s) Example 1 (with a postal zone defined): donuts A 192.188.192.1 GL US.45420.1910 "1425 Arbor Avenue, Dayton OH" Example 2 (no postal zone): lorinda A 129.122.1.1 GL SR "Marthastrasse 64, Shawproject, Uitvlug, Parimaribo" Example 3 ; Authoritative data for akc.net. ; ; note in this example: ; uspring, diana and martha (even though the complete postal code was ; not entered) are precisely defined ; ; lorinda, resides in the country of SURINAME, which has not implemented ; a postal coding system. ; ; THIS IS ONLY AN EXAMPLE ; @ IN SOA forme.akc.net. postmaster.akc.net. ( 99071100 ; Serial (yymmddnn) 10800 ; Refresh (3 hours) 3600 ; Retry (1 hour) 3600000 ; Expire (1000 hours) 86400 ; Minimum (24 hours) ) IN NS ns.akc.net. uspring IN A 192.188.192.2 IN MX 5 mail IN HINFO Vax VMS IN GL US.45420.1910 "1425 Arbor Avenue, Dayton OH" ftp IN CNAME uspring Costanzo [Page 4] EXPIRES IN SIX MONTHS August 2001 diana IN A 192.188.192.3 IN MX 5 mail IN HINFO Vax VMS IN GL US.07204.1367 "808 Chestnut Street, Roselle Park, NJ" www IN CNAME diana martha IN A 192.188.192.4 IN MX 5 mail IN HINFO Vax VMS IN GL US.07204 "815 Chestnut Willis Place, Roselle Park, NJ" lorinda IN A 129.122.1.1 IN GL SR "Marthastrasse 64, Shawproject, Uitvlug, Parimaribo" 6. Why in in the DNS specifically? It serves no useful purpose! It has been mentioned to the Author over and over again for the need of this resource record for internet telephone applications and how the use of other Internet Directory style services are not appropriate. DNS is standardized and a required application for ISPs, other directory services are not. It has also been mentioned that since the there is a one-to-one relationship between the host and the GL data it is appropriate for inclusion as a DNS resource record. As already mentioned in the draft, the physical location of a computer is becomming extremely important for government agencies such as police and fire. 7. Other possible uses for GL It has been mentioned to the Author over and over again for the need of this resource record for internet telephone applications and how the use of other Internet Directory style services are not appropriate. The use of postal codes also is exactly what is needed for credit card address authentication. Sites could (quietly) compare GL info provided on entries from ISPs to what someone enters for additional verification purposes. We also were told that this resource record would be helpful in tracking down hackers. (although the use of DHCP and dynamic addressing may limit its usefulness if ISPs did not maintain the GL record properly. 8 Why GL and not TXT records? TXT records do not have a specific order to them. It would be extremely unwise to to entrust 911 emergency calls to TXT records. Other resource records such as LOC and GPOS are not appropriate for use with emergency service units as police and fire departments 9. Security Consideration Since this resource record is not required in the DNS there are no security consideration. If someone such as the Department of Defense did not want the whereabouts of there computer system to be know, they would merely omit it. Costanzo [Page 6] EXPIRES IN SIX MONTHS August 2001 10. Author's Address Al Costanzo AKC Computer Services Corp. P.O. Box 4031, Roselle Park, NJ 07204-0531 www.AKC.com Phone: +1 908 298 9000 Email: AL@AKC.COM Costanzo [Page 7]