Commit 16f07b53 authored by Andreas Gustafsson's avatar Andreas Gustafsson
Browse files

added

parent e911387b
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<namedroppers@ops.ietf.org> 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 ôTMö item could separate the
Intellectual Property of Trademarks and Copyrights from other
registered listings issued from the government specified by the country
code in the Global label. Additionally, the Academy of Motion Pictures
might request an Oscar item, which would restrict membership to
nominees or recipients of the coveted award.
Just as the resolver gets an updated list of root servers upon first
connection, the resolver could also receive an updated list of items in
the Type label and return them to the client. The list could be updated
by a TTL trigger and should not be editable from the userÆs standpoint.
The user interface should allow for multiple selections, which could be
used to form separate requests for resolution. Finally, the
implementation should begin with at least a list that is equal to a
subject list found in the yellow pages of the phone book. This will
provide a well-known classification that will greatly reduce
competition for names of organizations, which are similar but provide
for very different products/services. Delta.airline is readily
distinguished from Delta.homeimprovement.
The device label would remain largely unaffected. A list of previously
connected items such as www, toasters, lock, refrigerator, etc. would
facilitate input. The list would be editable. As the number of devices
connected to the Internet grows, this method will be invaluable.
Consider mail and faxes being sent directly to
printer.mybusiness.computer.us2081234567.sfairview101. A user that
needs to send a fax to a satellite office might also be able to try
searching for mybusiness at its other street address or telephone
number eg., printer.mybusiness.computer.us714*.sPensylvaiaave2345.
Wildcards and searching are discussed in the next section.
The items under the Groups/Subgroups labels would also be a list of
previously connected to domains (less the TLD) such as sales.business
or kitchen.home. The list would contain a history of previous
connections and be editable.
The Global label would have two characters to represent the country
code followed optionally by all or part of a representative telephone
number or mask for identifying the voice number(s) associated as items
in the domain. An international code would require a rational
relationship with world organizations. The interface would contain the
country codes and/or area codes, but the numbers would have to be
added.
The Local label would require a single character to represent the type
of information presented, followed by the information in a standardized
form. The following codes are proposed for the Local label, ôPö for
Postal code, ôGö for Global Satellite Positioning and ôSö for street
address. For example, P83706 would represent the authorÆs postal code,
GP0445004N1162498 (since the ô+ö key is not valid, ôpö and ônö
represent positive and negative) would represent the GPS position of
the author with padding to standardize degrees/min/sec or SOrchard15541
would represent the Street address (house number at the end). Note each
of these would require a separate name registration. The editable list
box could be a fly out list box with one of the designators specified,
while the remainder would be user input.
+------------------+
|Street |
| Fairview101 |
State101 |
|Postal |
|GPS |
+------------------+
The added labels would exponentially expand the name space. This may
cause an undesired relation to a Global or Local designation. This
could hamper changes to an organization or business in the future.
Hence a business might want to use a CNAME entry to reference users to
a non-distinct item in a label. For instance, a corporation might want
to register mybusiness.bus.In(ternational).corporate so that the
corporate office could be used for email addresses and bookmarking.
Content might be located at each mybusiness.bus.country.location where
the company does business. This way a corporation does not have to be
penalized for moving to a new physical location. The goal of the DNS
was to remove a physical relationship to the network, but the need of
the users is for some content to have a physical relationship to the
content; which is why, in part, the NNS is proposed. The concept of an
update is also discussed in section 5.
The system would need to distinguish between the need for a request for
a connection to single IP address versus multiple requests. In an
application like a browser, traditional requests for IP resolution are
all or none. Either an IP address is connected to or not. If wildcards
are added to the request, multiple entries could be returned as a ôhitö
list. An option on the browser could determine the number of requests
specified by the user. The ôhitsö should also be weighted. For
instance, if a user wanted to find all the movie theatres in the local
area he/she might submit a request for www.*.movies.US8370*.*. She/he
would be more inclined to desire additional theatres at different
nearby area codes than derivations of different domain names or Local
label derivations for a single theatre. A simple listing of each label
with an associated numerical value in an advanced option field could
determine how the responses are weighted against one another. The NNS
could also take into account the number of requests on the system and
further limit the number of responses based upon traffic.
For registration, the content provider might want to register a more
global entry to be displayed on a restrictive search e.g. loans.US*.*.
A business content provider might want to register mybusiness.com.US*
so that requests for www.mybusiness.com.US208.* and
www.mybusiness.com.us714.* both resolve to mybusiness. A process would
have to be in place to copy an entry with wildcards to each of the
associated branches of the processing trees as discussed in section 4.
Similarly wildcard registrations should meet the rational requirements
required for the known item with the generalized scope. In the previous
example the provider would have to be licensed as a financial
institution in each of the states of the United States.
3. Resolution Processing
The key to expanding the DNS is to provide for a name space, which can
be accessed quickly and efficiently. Organization is key to this
process. The current DNS has one root organized by TLDs of the Type
label combined with Country TLDs. If a user does not know the extension
for the name, requests must be created for each one until a match is
found. The NNS creates separate roots for each label that can be used
for a search (see graphic on next page, description of TLDs is in
section 5). Instead of one tree, a forest is created, connected by a
common list of authorities for devices in the zones requested. Requests
can be organized by the known piece(s) of information. For instance, if
a user is trying to find Hewlett Packard and does not know that content
is provided at HP, a search of www.H*.*.US*.* should be returned
alphabetically from the Group label, not the Type label. However, if
the type item is known to be ôcomputerö, a search of the Type tree
would be fastest. If a user wants to find a local voice number for
Microsoft he/she could submit a request generalized request within the
local area code for www.Microsoft.software.US208*.*. The authority
would best be located by the Global processor, which might list
www.Microsoft.software.US5041234567.SState123 and
www.Microsoft.software.US5044567890.SredmondAve123. If the request for
www.Microsoft.software.US504*.* were sent to the Local processor, every
TLD would have to be queried. The result might be one phone number with
separate Local label listings for the street address, GPS, and postal
code. This would create unwanted traffic on the system.
Root ô.ö Group Root ô.öType
| |
| |
ôHö TLD TLD ôComputerö
| |
| |
--- Authority for..HP.computer.US2081234567.SChinden12----
| |
| |
ôUS208ö TLD TLD ôSChiö
| |
| |
Root ô.ö Global Root ô.öLocal
In addition to determining which label(s) to process the request, the
system would also have to take into account the weighting by the user
and the traffic on the system as discussed in the previous section.
When the FQDN is specified, the resolver would query the processor with
the fastest expected response time. A FQDN can be resolved from any of
the search processor trees. In the example
oven.macgowan.private.US2081234567.SOrchard15541, it does not matter
whether the request is sent to the Group, Type, Global, or Local
processing tree. Each leads to the authority,
macgowan.private.us2081234567.SOrchard15541.
If wildcards or null characters exist in the request, the system should
take into account the number of requests that might be generated.
Currently the DNS does not account for the ô?ö and reserves the ôö for
the root. The ô*ö could replace the singe character wildcard ô?ö and
the word ônullö could be used in lieu of ôö. The following table could
be used to determine which processing tree should be the most desirable
under such conditions:
any =
any combination of characters displayed in
request
reject=
no preferred processor
*=
match any combination of characters for
response
?=
match any single character for response
null=
no character specified
Device
Sub
Group
Type
Global
Local
Result
*
*
*
*
*
*
reject
*
any
any
any
any
any
reject
*
*
any
any
any
any
reject
*
*
*
any
any
any
submit to type, global, or local
processor
*
*
*
*
any
any
submit to global, or local
processor
*
*
*
*
*
any
submit to local processor
any
*
*
*
*
*
reject
any
any
*
*
*
*
reject
any
any
any
*
*
*
submit to group processor
any
any
any
any
*
*
submit to group, or type
processor
any
any
any
any
any
*
submit to group, type, or global
processor
any
any
any
any
any
any
submit to any processor
any
*
any
any
any
any
submit to any processor
any
*
*
any
any
any
submit to type, global, or local
processor
any
*
*
*
any
any
submit to any global, or local
processor
any
*
*
*
*
any
submit to any local processor
any
any
*
any
any
any
submit to any type, global, or
local processor
any
any
*
*
any
any
submit to any global, or local
processor
any
any
*
*
*
any
submit to any local processor
any
any
any
*
any
any
submit to any group, global, or
local processor
any
any
any
*
*
any
submit to any group, or local
processor
any
any
any
any
*
any
submit to any group, type, or
local processor
any
any
any
any
*
*
submit to any group, or type
processor
*
*
*
*
*
*
reject
*
any*any
any*any
any*any
any*any
any*any
reject
*
*
any*any
any*any
any*any
any*any
reject
*
*
*
any*any
any*any
any*any
submit to type, global, or local
processor
*
*
*
*
any*any
any*any
submit to global, or local
processor
*
*
*
*
*
any*any
submit to local processor
any*any
*
*
*
*
*
reject
any*any
any*any
*
*
*
*
reject
any*any
any*any
any*any
*