draft-macgowan-dnsext-label-intel-manage-00.txt

bind-3.2.

INTERNET-DRAFT           DNS Label Intelligence and Management System
UPDATES RFC 1034                                        February 2001
                                                  Expires August 2001




Domain Name System (DNS) DNS Label Intelligence and Management System
         draft-macgowan-dnsext-label-intel-manage-00.txt



Michael L. Macgowan Jr.


Status of This Document

This draft is intended to become a Proposed Standard RFC. Distribution 
of this document is unlimited. Comments should be sent to the Domain 
Name Server Extensions working group mailing 
list<[e-mail]> or to the author.

This document is an Internet-Draft and is in full conformance with all 
provisions of Section 10 of RFC 2026.  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


A multidimensional array of domain label analysis and extensions are 
offered to overcome a number of issues with the DNS and its use to 
locate resources on the Internet. These goals are accomplished by 
proposing a naming convention to add labels to domain strings. The 
result will be a rational relationship to the content that will provide 
a method for meeting the ever-increasing need to expand the namespace, 
while providing an efficient search system to access content in a user-
friendly manner.

A fundamental problem exists in the design of DNS. A user must know the 
domain name including the Top Level Domain, TLD, and type the Uniform 
Resource Locator, URL, accurately to connect to resources on the 
Internet. The current lookup organization of the DNS uses domain labels 
separated by periods to provide hierarchical levels for a resolver to 
seek in finding a path to an authority. A new masking technique within 
labels is proposed to accommodate lookups based on the request. 
Multiple processing trees are proposed to redistribute the requests 
based on the known pieces of the domain name. Rather than knowing the 
fully qualified domain name, FQDN, the user can search for content 
based upon known pieces of the string like group (business), country, 
area code, phone number, type of organization, street address, zip code 
and/or GPS location, etc.. Intelligence is added for determining the 
fastest route to resolution based on user weighting, number of 
requests, and traffic within the system.

A result of the masking technique is an opportunity to provide a 
completely hidden label(s) for maintenance of the system. A TTL (Time 
to Live), version, and type of request could be keyed into a label to 
provide information, which remains with the client but is normally lost 
after a request is processed. This system could be implemented to 
create automatically updated records and content. Or hidden labels 
could be used to distinguish between version 4 and version 6 requests 
in the TCP/IP, Transmission Control Protocol/ Internet Protocol, 
rollover.

Implementation of the new name system is facilitated by the addition of 
a client interface for building requests. Longer domain names are 
enhanced by smart AutoCompletes and group edit boxes.

Table of Contents

      Status of This Document                                    1
      Abstract                                                   1

      Table of Contents                                          3

      1. Introduction                                            4
      2. Inputting Request for Resolution                        4
      3. Resolution Processing                                   7
      4. Processing Forest                                      13
      5. Extended Label Uses                                    14
      6. IANA Considerations                                    16
      6. Security Considerations                                16

      References                                                16

      Authors Address                                           16
      Expiration and File Name                                  17












1. Introduction

The Domain Name System (DNS) [RFC 1034, 1035] is the global 
hierarchical replicated distributed database system for Internet 
addressing, mail proxy, and other information.  The DNS has been 
extended to phone numbers as described in [RFC 2535]. It is designed to 
accommodate a user-friendly name as an abstraction level over an IP 
address, which provides a path to the physical connection to resources 
and/or content on the Internet. This abstraction allows for changing 
the physical location of the content without an update by the client. 
The design, however, lacks a user-friendly method for assigning TLDs 
and determining which TLD a content provider will be registered under.

According to COMPUTERGRAM INTERNATIONAL: January 08, 2001, over 100 
million hosts are connected to the Internet with over 350 million 
users.  ICANN has submitted plans to increase the number of TLDs to 
accommodate the lack of namespace, but the problem of organization and 
extensibility continues to exist. As the number of TLDs grows, it 
becomes harder for a user to input a user friendly domain name. In 
essence, the user must know what derivations and which TLDs were 
available to a provider at the time the organization chose a domain 
name. The method of one response, in an all or nothing request, forces 
precision on the part of the user that is a distraction to the original 
goal of a user-friendly name. Consider a user that wants to find a new 
theoretical health related company called Healthy Foods. Will the 
company be called Healthyfoods.com? Or will it have an extension like 
healthfoods.net, healthfoods.org, or healthfoods.health? Maybe it will 
be forced to be a derivation like healthf.com, healthf.net, etc. There 
is no user-friendly method to determine what the associated domain name 
might be. This is a central problem of focus and organization. The 
number of iterations a user must try increases with each new TLD that 
is added. If a user forms multiple guesses for the TLD, excess traffic 
is generated and the search is slowed by the inefficient nature of 
human typing. Further, if a system were proposed under the current root 
structure to allow for a search of all possible TLDs, the number of 
requests would grow exponentially with the addition of each new TLD.

2. Inputting Request for Resolution
 


The key to making a New Name System, NNS, is to provide a user 
interface, which will accommodate a friendly method of building name 
requests. AutoComplete and multiple-selection drop-down, group list 
boxes (some editable, some not) will make more complicated names easier 
to input. Consider the previous example of Healthy Foods. Additional 
extensions could be added as labels to make the namespace exponentially 
larger. The web content might be reached at 
www.healthy.food.US2081234567.Fairview101. In this example, www is the 
Device label or content desired by the user. Health is the domain or 
Subgroup/Group name label. Food is the item under the Type label.  
US2081234567 is the item country/area code/number for the Global label. 
Sfairview101 is the street/address of the Local label.

Derivations of this example provide a limitless expansion of the 
namespace within the physical limits of the protocol. A competitor down 
the block might have the same FQDN, except for the street number and 
phone number e.g. www.healthy.food.US2088901234.SFairview990. A second 
type of business could also be run from the same location by changing 
the type e.g. www.healthy.entertainment.US2081234567.SFairview101. A 
parody of the site might be offered at 
www.healthy.parody.us2086669999.SState103.

A method of using less descriptive labels could also be used to 
generalize the content. For example, the site for the regional office 
might use only the country and area code designation e.g. .US208. A 
corporate address might be located at www.healthy.food.US.corporate. 
This way the Global and Local labels are not tied to physical 
locations. Or there may be an 800 or 888 number that could be used for 
multiple sites that are tied to multiple registrations at different 
street addresses in the Local label.

The task of building these longer names with labels can be accomplished 
by updating list items from the NNS and by designing a better 
interface. Instead of waiting for ICANN to vote on the relative merits 
of a proposal for a new TLD, items could be automatically updated and 
added to the system by a list of requirements. This would force a 
relationship between labels but provide a nonbiased method without 
prejudice. For example, a .Bus(iness) item for the Type label would 
require a copy of a business license to be granted by the governing 
authorities for the area specified in the Global label or the address 
specified in the Local label. A 揟M