Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NetBSD/dist/bind/doc/draft/draft-macgowan-dnsext-label...

803 lines
39 KiB
Plaintext
Raw Blame History

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 <20>TM<54> 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<65>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, <20>P<EFBFBD> for
Postal code, <20>G<EFBFBD> for Global Satellite Positioning and <20>S<EFBFBD> for street
address. For example, P83706 would represent the author<6F>s postal code,
GP0445004N1162498 (since the <20>+<2B> key is not valid, <20>p<EFBFBD> and <20>n<EFBFBD>
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 <20>hit<69>
list. An option on the browser could determine the number of requests
specified by the user. The <20>hits<74> 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 <20>computer<65>, 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 <20>.<2E> Group Root <20>.<2E>Type
| |
| |
<20>H<EFBFBD> TLD TLD <20>Computer<65>
| |
| |
--- Authority for..HP.computer.US2081234567.SChinden12----
| |
| |
<20>US208<30> TLD TLD <20>SChi<68>
| |
| |
Root <20>.<2E> Global Root <20>.<2E>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 <20>?<3F> and reserves the <20><> for
the root. The <20>*<2A> could replace the singe character wildcard <20>?<3F> and
the word <20>null<6C> could be used in lieu of <20><>. 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 T G L Result
* * * * * * reject
* any any any any any reject
* * any any any any reject
* * * any any any submit to T, G, or L
* * * * any any submit to G, or L
* * * * * any submit to L
any * * * * * reject
any any * * * * reject
any any any * * * submit to group
any any any any * * submit to group, or T
any any any any any * submit to group, T, or G
any any any any any any submit to any
any * any any any any submit to any
any * * any any any submit to T, G, or L
any * * * any any submit to any G, or L
any * * * * any submit to any L
any any * any any any submit to any T, G, or L
any any * * any any submit to any G, or L
any any * * * any submit to any L
any any any * any any submit to any group, G, or L
any any any * * any submit to any group, or L
any any any any * any submit to any group, T, or L
any any any any * * submit to any group, or T
* * * * * * 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 T, G, or L
* * * * any*any any*any submit to G, or L
* * * * * any*any submit to L
any*any * * * * * reject
any*any any*any * * * * reject
any*any any*any any*any * * * submit to group
any*any any*any any*any any*any * * submit to group, or T
any*any any*any any*any any*any any*any * submit to group, T, or G
any*any any*any any*any any*any any*any any*any reject
any*any * any*any any*any any*any any*any reject
any*any * * any*any any*any any*any submit to T, G, or L
any*any * * * any*any any*any submit to any G, or L
any*any * * * * any*any submit to any L
any*any any*any * any*any any*any any*any reject
any*any any*any * * any*any any*any submit to any G, or L
any*any any*any * * * any*any submit to any L
any*any any*any any*any * any*any any*any reject
any*any any*any any*any * * any*any submit to any group, or L
any*any any*any any*any any*any * any*any submit to any group, T, or L
any*any any*any any*any any*any * * submit to any group, or T
* * * * * * reject
* any* any* any* any* any* reject
* * any* any* any* any* reject
* * * any* any* any* reject
* * * * any* any* submit to G, or L
* * * * * any* submit to L
any* * * * * * reject
any* any* * * * * reject
any* any* any* * * * reject
any* any* any* any* * * reject
any* any* any* any* any* * reject
any* any* any* any* any* any* reject
any* * any* any* any* any* reject
any* * * any* any* any* submit to T, G, or L
any* * * * any* any* submit to any G, or L
any* * * * * any* submit to any L
any* any* * any* any* any* reject
any* any* * * any* any* submit to any G, or L
any* any* * * * any* submit to any L
any* any* any* * any* any* reject
any* any* any* * * any* submit to any group, or L
any* any* any* any* * any* reject
any* any* any* any* * * submit to any group, or T
?any ?any ?any ?any ?any ?any reject
?any any any any any any reject
?any ?any any any any any reject
?any ?any ?any any any any submit to T, G, or L
?any ?any ?any ?any any any submit to G, or L
?any ?any ?any ?any ?any any submit to L
any ?any ?any ?any ?any ?any reject
any any ?any ?any ?any ?any reject
any any any ?any ?any ?any submit to group
any any any any ?any ?any submit to group, or T
any any any any any ?any submit to group, T, or G
any any any any any any submit to any
any ?any any any any any submit to any
any ?any ?any any any any submit to T, G, or L
any ?any ?any ?any any any submit to any G, or L
any ?any ?any ?any ?any any submit to any L
any any ?any any any any submit to any T, G, or L
any any ?any ?any any any submit to any G, or L
any any ?any ?any ?any any submit to any L
any any any ?any any any submit to any group, G, or L
any any any ?any ?any any submit to any group, or L
any any any any ?any any submit to any group, T, or L
any any any any ?any ?any submit to any group, or T
any?any any?any any?any any?any any?any any?any reject
any?any any any any any any submit to any
any?any any?any any any any any submit to any
any?any any?any any?any any any any submit to any
any?any any?any any?any any?any any any submit to G, or L
any?any any?any any?any any?any any?any any submit to L
any any?any any?any any?any any?any any?any reject
any any any?any any?any any?any any?any reject
any any any any?any any?any any?any submit to group
any any any any any?any any?any submit to group, or T
any any any any any any?any submit to any
any any any any any any submit to any
any any?any any any any any submit to any
any any?any any?any any any any submit to any
any any?any any?any any?any any any submit to any G, or L
any any?any any?any any?any any?any any submit to any L
any any any?any any any any submit to any
any any any?any any?any any any submit to any G, or L
any any any?any any?any any?any any submit to any L
any any any any?any any any submit to any
any any any any?any any?any any submit to any group, or L
any any any any any?any any submit to any
any any any any any?any any?any submit to any group, or T
any? any? any? any? any? any? reject
any? any any any any any submit to any
any? any? any any any any submit to any
any? any? any? any any any submit to any
any? any? any? any? any any submit to any
any? any? any? any? any? any submit to any
any any? any? any? any? any? submit to any
any any any? any? any? any? submit to any
any any any any? any? any? submit to any
any any any any any? any? submit to any
any any any any any any? submit to any
any any any any any any submit to any
any any? any any any any submit to any
any any? any? any any any submit to any
any any? any? any? any any submit to any
any any? any? any? any? any submit to any
any any any? any any any submit to any
any any any? any? any any submit to any
any any any? any? any? any submit to any
any any any any? any any submit to any
any any any any? any? any submit to any
any any any any any? any submit to any
any any any any any? any? submit to any
Null any any any any any not valid
any Null any any any any submit to any
any any Null any any any reject
any any any Null any any submit to group, G, L
any any any any Null any submit to group, T, L
any any any any any Null submit to group, T, G
Null Null any any any any not valid
any Null Null any any any reject
any any Null Null any any submit to G, L
any any any Null Null any submit to group, L
any any any any Null Null submit to group, T
Null Null Null any any any not valid
any Null Null Null any any submit to G, L
any any Null Null Null any submit to L
any any any Null Null Null submit to group
Null Null Null Null any any not valid
any Null Null Null Null any submit to L
any any Null Null Null Null not valid
Null Null Null Null Null any not valid
any Null Null Null Null Null not valid
Null Null Null Null Null Null not valid
4. Processing Forest
|--Group Root---|
| |
|---Type Root---|
| |
client->------Resolver ->------| |----Authority->---
return
| |
|--Global Root--|
| |
|--Local Root---|
Once the resolver has determined which root to send the resolution
request to, each tree should be organized according to an exhaustive
replication of each name string on the route to an authority. For
instance, the Group tree would be organized alphabetically with TLDs
<EFBFBD>A<EFBFBD> through <20>Z<EFBFBD> initially. Since there are a lot of organizations with
business name derivations using the word <20>micron<6F>, there might be a
need to reorganize the <20>M<EFBFBD> TLD to accommodate a <20>Mic<69> and a <20>Mid<69> TLD.
Although it would be more efficient to break down each letter according
to the demands of the system, it would be easier to specify one mask
for the entire tree. The number of TLDs becomes a function of the
permutations of the number of masked characters in the available set of
usable characters rather than a select few that are added over time.
The resolver can cache the TLDs and know when to use them based upon
the mask for the tree. If a larger mask is needed to further distribute
the load, the resolvers would have to be updated.
To replicate the current DNS entries under the additional labels
specified in this proposal a number of applications and uses would have
to be accounted for. The ARPA listings would remain unchanged or they
could be replicated under each root by recombining telephone numbers in
a single label under the e164 or padding IP addresses under the inverse
lookup tables without the periods separating the octets.
Since the NNS uses a forest of processing trees and the current system
uses only one tree, a conversion process would have to be developed to
distinguish between DNS requests and NNS requests. This could be
handled using a number of different methods.
A version flag in the request could accomplish this. This way the
resolver would be able to determine which searchable labels were used
and the order of presentation by standardization. The resolver
intelligence would know which labels to use for lookup or in the
preferred embodiment. The resolver could also reorganize the labels to
be presented under the correct processor so that the Global label is
presented at the right of the name string for processing through the
Global tree. Legacy requests without a version would be sent to the
Type tree.
Another method could accomplish the goal by combining the labels the
request for the processing tree. In the previous example, the request
oven.macgowan.private.US2081234567.SOrchard15541 could be recombined by
the submitting processor as
oven.macgowanUS2081234567SOrchard15541.private to be searched under the
Type tree. Similarly it could be recombined as
oven.macgowanprivateUS2081234567.SOrchard15541 to be searched under the
Local tree. If a legacy DNS based system submitted a request for
www.yahoo.com, it might be appended as www.yahoo.com..... The first <20>.<2E>
after com is to end the Type label. The second <20>.<2E> Represents the null
character at the end of the Global label. The third <20>.<2E> is for the
Local label. The fourth <20>.<2E> is for the root. The last <20>.<2E> is for the
end of the sentence. If applications are affected by the reservation of
the <20>.<2E> for the root, the request could be recreated as
www.yahoo.com.null.null..
A final method is to create a hidden label. Hidden labels are discussed
further in extended label uses.
Once the authority for a label is found within the label, the system
must also determine if there are Subgroups. Subgroups can be used for a
number of internal functions and/or divisions within the authority for
an organization. At this point the system would continue to resolve
using subgroup labels as levels as it does under the current system
toward the device at the left of the name string.
The remaining searchable labels would be serviced using a similar
method. The Type tree would be organized as it is in the DNS with TLDs
representing each item in the list. Since the items in the list are
limited by the system, the mask could be set to none. The Global label
should be organized by a mask, which would accommodate at least the
country and area codes. The Local label would mask the PGS items until
enough TLDs are derived to equal processing traffic under the other
trees. Provisions should be made for the non-distinct items like
<EFBFBD>corporate<EFBFBD> that may use characters not reserved for physical
locations. In addition, a null TLD could be used to organize the
remainder of name strings that have omitted labels. The null <20><>
character or the word <20>null<6C> could be used to represent legacy DNS
strings under the new labels until the name strings are updated with
the longer requirements.
The NNS allows a FQDN to be resolved from each searchable label. Please
refer to the previous example,
oven.macgowan.private.US2081234567.SOrchard15541. The authority,
<EFBFBD>Macgowan.private.US2081234567.SOrchard15541<34> is found using the
traditional method of the DNS using a Type item of <20>private<74> (mask of
zero). The authority, <20>Macgowan.private.US2081234567.SOrchard15541<34> is
found through the Group processor under the <20>Mac<61> branch using a mask
of three characters. The <20>Macgowan.private.US2081234567.SOrchard15541<34>
authority is found under <20>US208<30> using a mask of four characters within
the Global processing tree. The
<EFBFBD>Macgowan.private.US2081234567.SOrchard15541<34> authority is also found
under <20>SOr<4F> of the branch masked under the Local tree.
5. Extended Label Uses
The NNS is a simple design which can accommodate the future of Internet
name strings by incorporating additional processing trees and a large
name space organized by labels with a user friendly interface. A search
engine is automatically derived from the organization within labels as
opposed to across labels. In other words, you send the known pieces of
the request to the processing tree that will yield the quickest results
with the least amount of traffic. Once names are bookmarked or selected
from a list of AutoCompletes, requests can be sent to any processing
tree to balance the load on the system.
The present proposal also provides an extensible path for future labels
that may or may not have associated processors. A <20>Contact<63> label
might always be masked during the request for resolution, but provide
additional value to the user with a description about the connection or
a webmaster<65>s email address. This has extreme value in the event a name
can be resolved, but not reached by connection to the IP address. In
addition to adding new labels, a group or association might request a
new item under the Type label or a new area code might be added under
the Group label. Therefore, one result of this system is a combination
of devices and labels which expands exponentially to meet the demand
for namespace with an inherent capability to adjust to future needs.
An additional hidden label (mask of all) adjacent to the root could be
hidden and give information for maintenance of the system and/or the
listing. The most important consideration is keying the order and
number of labels in the string. Or using this method, a hidden security
label could help create a firewall between valid requests from users in
the domain versus outsiders or tie to a public key for the destination.
The hidden label could also be used to pass a request for content
delivered in a specific language. With the addition of the Local and
Global labels it might also be necessary to add a TTL label which could
serve as a timer for the registration or the life of a bookmark or
connection. The client could use this value in a history of valid
connections to make a request for an updated TTL, a new IP address,
and/or a trigger for replacing the name with a new string. This would
allow for a change in address, phone number, new area code, etc. on the
part of the provider. Just as the domain name was an abstraction layer
over the IP address, the current domain string is an abstraction for a
future domain string. A routine could prompt a user to change an entry
in a contact/bookmark list. Services such as WWW could also
automatically update links in the content or reflect changes to related
destinations within the content. In use, the client could compare its
value to the value at the authority. If the authority has a value of
zero, the client would update its name and IP address to the new
pointer returned by the resolver. An electronically updating NNS with
updating links in content is a product of this system.
An example of using this procedure could be applied to finding the best
cell phone plan. A user buys a cell plan. The user emails contact links
to friends and associates. The recipients use their link to dial the
user. The user determines a new provider would be more advantageous and
purchases a new plan with a new number. The user sets their old TTL to
zero in the NNS and creates a new FQDN with the new cell number. Now
when the recipients use the old string, they are pointed to the new
string. The string with the new number is updated in the recipient<6E>s
contact list. The user is not tied to their telephone number and the
recipients do not need to manually adjust their entries.
Hidden labels and masking would also have to be present at the client.
A business might have a lot of phone numbers or locations listed on the
name servers but use a shorter version of the string for making local
connections. This way all the devices under a group could be combined
as a single domain name. The future direction of label intelligence and
the ideas expressed here suggest that there may be numerous ways to
provide abstraction levels within the label string. Even the IP address
might be used as an identifier to search for the rest of the domain
string or an item like the telephone number.
6. IANA Considerations
The focus of the IANA will change considerably. The need to regulate
name hoarders, TM infringement considerations, and the decision to
implement new TLDs will be greatly reduced. The IANA might be used to
determine the relationships between labels as new items are added under
the requirements that provide for fair and equal addition to the Type
label.
7. Security Consideration
Name resolution is an inherent problem for spoofing content, but is
beyond the scope of this proposal. The suggested ability to update name
strings at the client also increases the need to provide secure
communications between the system and the client.
References
[RFC 1034] - "Domain names - concepts and facilities", P.
Mockapetris, 11/01/1987.
[RFC 1035] - "Domain names - implementation and specification", P.
Mockapetris, 11/01/1987.
[RFC 2535] <20> <20>E.164 number and DNS<4E> , P.
P. Faltstrom, 9/1/2000.
Authors Address
Michael L. Macgowan Jr.
15541 Orchard Ave.
Caldwell, ID 83607 USA
Telephone: +1 208.454.1177 (h)
FAX: +1 208.455.0439
EMail: mmacgowa@yahoo.com
Expiration and File Name
This draft expires in August 2001
Its file name is labelmanage.txt
Full Copyright Statement
Copyright (C) The Internet Society (February 2001). All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE."
Michael L. Macgowan Jr. February 2001 [Page 17]
Internet Draft DNS Label Intelligence and Management System
Reference in New Issue View Git Blame Copy Permalink