Internet DRAFT - draft-costanzo-dns-gl
draft-costanzo-dns-gl
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 <tba> (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:
<owner> <ttl> <class> GL <Rdata>
4.1 Rdata Format
Rdata has the following format:
<string> <string>
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]
