DNS: The Hierarchical Approach


DNS is a remarkably complex systemone that many fine books are entirely dedicated to explaining. I won't try to explain the intricacy and nuance of the system's operational mechanics in a single chapter. My intent is to simply provide you with an overview of the system as it relates to Internet names and numeric addresses.

The basic concept of DNS was spelled out in RFCs 882 and 883, which were published in November 1983. Numerous updates have been made to this basic description (including RFCs 1034 and 1035) in the nearly 20 years since they were published, but the core of DNS has remained. At its simplest, DNS is a hierarchical, distributed database. The two key aspects of DNS are

  • Hierarchical namespace

  • Distributed server-based architecture to perform name-to-number conversion

Together, they enable a robust, reliable, and highly scalable mechanism for translating unique names into unique numeric addresses. This chapter is entirely focused on the namespace itself, including its hierarchy, uses, and even controversies. The physical architecture that supports name-to-number and number-to-name translations is addressed (if you'll pardon the double entendre!) in the next chapter.

Hierarchical Namespace

The hallmark of the DNS is its hierarchical namespace. Much like numeric host IP addresses, which can be duplicated across different network IP addresses, the introduction of levels of domain naming enabled the reuse of many common host names without compromising the uniqueness so critical for reliable name-to-number translation.

At this stage in the evolution of the Internet, it is difficult to imagine anyone who is not familiar with its namespace. With that familiarity comes an implicit understanding of Internet name construction and use. Such an understanding forms the basis of guessing URLsa common practice among Internet users.

NOTE

A URL is a uniform resource locator. Most people know what it is instinctively even after browsing the Internet just once, even if they don't know the term. However, there is a subtle distinction between a URL and a Fully Qualified Domain Name (FQDN). For example, people can logically guess that the Cisco Systems Web site is www.cisco.com. That string is an FQDN. When you preface an FQDN with protocol-level commands, you get a URL. For example, www.cisco.com is a protocol-level command that uses the Hypertext Transfer Protocol (HTTP) to access the computer that hosts the Cisco Systems Web page.


A URL is a good example to use, because it requires the user to be able to recognize and follow the basic rules governing the Internet's hierarchical namespace. For example, a high school student trying to research colleges might spend an afternoon surfing the Net. One guess might be www.lehigh.edu. This name does, in fact, resolve into the external Web site of my alma mater, Lehigh University. More significantly, it demonstrates a three-level address that adheres to the convention that is broken down in Table 8-1.

Table 8-1. Construction of a Hierarchical Internet Name

Host Name

Subdomain

Domain

www

.lehigh

.edu


As is evident in Table 8-1, the groupings become larger as you move to the right. The .lehigh domain contains numerous hosts; this one just happens to be named www. Similarly, the .edu domain contains innumerable academic institutions. As such, .edu functions as an aggregator for related entities. In the parlance of the Internet, .edu is a top-level domain (TLD). There are numerous TLDs, and all share a common root. The Internet naming system's root is usually denoted with a " . ". This hierarchical effect is best appreciated visually. Figure 8-1 demonstrates the relationship between the root and the Internet's TLDs.

Figure 8-1. Hierarchical Arrangement Within .edu


If this illustration looks familiar, don't be surprised. It is exactly how you would map out the relationship between files, directories, and drives on a computer. In fact, the hierarchy used for the Internet's naming system was based on UNIX concepts, so the similarities are inescapable even though the terminology might differ. For example, the field identified in Table 8-1 as the domain is more precisely identified as a top-level domain, or even a first-level domain. The subdomain is more commonly known as a second-level domain (SLD).

The Internet's hierarchical domain namespace, just like UNIX operating systems, begins with root and branches out in a tree-like manner. This enables the creation of subdivided namespaces within higher-level domain names. The concepts of TLDs and SLDs are further explored in the next few sections.

Top-Level Domains

Jon Postel, the guiding light responsible for so much of the foundation upon which today's Internet was built, issued RFC 1591 in March 1994. Titled "Domain Name System Structure and Delegation," this document focused on TLDs and their administration. Administration of SLDs and host names was regarded as the purview of other entities.

The top-level domain was deemed to have certain generic domains that would be of worldwide applicability. These generic TLDs and their intended roles as listed in RFC 1591 are described in Table 8-2.

Table 8-2. Some TLDs and Their Intended Uses

TLD

Description

.com

Intended as a broad category for all commercial entities, .com has become the single-most immediately recognizable TLD.

.edu

Originally created for all academic and educational institutions, it is not uncommon to find universities, colleges, schools, and even organizations only marginally related to education contained in this domain.

.net

Designed for providers of Internet services, the .net domain has become an unruly collection that almost rivals .com in its breadth of registered names.

.org

Organizations that don't quite fit into any of the other categories need an area of their own. These organizations aren't commercial in nature, aren't educational institutions or government/military agencies, and aren't international. This might sound like a sketchy, poorly conceived basis for a domain, but that is why it was developed!

.int

Probably the least-recognizable TLD, the .int code is reserved for use by organizations established by international treaty or for international databases. One example is www.redcross.int, which is the Web site of the International Red Cross. Many entities that qualify for this domain also supplement their reach with domain names from the more-recognizable TLDs.

.gov

A mnemonic abbreviation of "government." It is reserved for use by the U.S. Federal Government and its subagencies.

.mil

A mnemonic abbreviation of "military." It is reserved for use by the U.S. Armed Forces.


The list presented in Table 8-1 is not comprehensive. Several new TLDs have recently been added, and almost every country enjoys its own unique country code TLD (ccTLD). These are just the more commonly encountered TLDs. The new generic TLDs are examined later, in the section "Newly-Created TLDs."

Figure 8-2 demonstrates the relationship between root and the Internet's generic TLDs.

Figure 8-2. Root and the Generic TLDs


Sharing a common root can easily be taken for granted. However, you must realize that if TLDs didn't share a common origin, each of them would be an island. That is, they would be isolated and separate systems that would be required to resolve names within each TLD. Thus, a common root means that a single hierarchical system (albeit with widely distributed servers) can satisfy name resolution for the entire Internet.

A Special Purpose

It is important to realize that each of these domains was conceived for a specific purpose. The notion of a charter for each domain was never formalized outside the RFC process, and no policing mechanism was ever developed. With the exceptions of .int, .gov, and .mil, virtually anyone could register a name in any TLD. The price of entry was limited to just paying the annual fee for the name registration. Consequently, the original intent became occluded over timeparticularly after the Internet commercialized. At that point, it seemingly became standard operating procedure for companies to register themselves, and all their trademarks, trade names, brands, and so on, in each of the available TLDs. Although this completely violated the original intent of the TLDs, it ensured that no one could defraud the Internet community by pretending to be someone they weren't. This touched off a debate that still rages between technologists and intellectual-property lawyers. For more on this debate, see the sidebar near the end of this chapter.

Global Expansion of the TLD

If you detected a strong U.S. bias in the TLDs outlined in Table 8-1, you are correct. The bias begins with the abbreviations themselvesthey are all mnemonic, but only in the English language. Even more obvious is the reservation of two generic TLDs just for the U.S. Government. In short, these domains reflect the evolution of the ARPANET into the Internet, which was predominantly a U.S.-based internetwork. Clearly, some work needed to be done to ensure the Internet's global scalability.

RFC 1394, published in January 1993, correlated TELEX answer-back codes to international Internet domains. This RFC formed the basis for TLDs to be assigned to each country. The result was an extensive list of ccTLDs. Despite this effort to ensure global consistency of TLDs, problems with the system remain:

  • Trying to achieve consensus on what a country is

  • Lack of standards for subdomains in ccTLDs

These issues are discussed in the following sections.

What's a Country?

Although it might seem simple, and even noble, to ensure that every country gets its own ccTLD, this is deceptively difficult. For example, it isn't difficult to find governments that are recognized as a "country" by some nations but not others. Sometimes the world community is split almost down the middle on this subject, with some countries backing one faction while others back another faction, regardless of who is in power. Thus, it is easy to forgive Internet Corporation for Assigned Names and Numbers (ICANN) for taking the easy way out of this conundrum. They are not in the business of bestowing political recognition on emerging nations. For that reason, it was decided to use standard ISO-3166 from the International Organization for Standardization (ISO) to establish the Internet's country codes.

Standards for SLDs?

The second concern is that there exists only a general sense of cohesiveness with respect to the conventions used to create subdomains inside each ccTLD. The ccTLD operators were left to their own devices when it came to how to use their country code. Given this, it shouldn't be surprising that there is disparity across the ccTLDs. Instead, it should be absolutely stunning that there is any consistency at all!

Some ccTLD operators have mimicked the generic TLDs of the Internet and have created .edu, .com, .net, and so on within their country code. Thus, to access a university in Australia, you would use anycollege.edu.au. Other country code operators have opted to conserve characters by carving out two-letter subdomains that reflect the same functional groupings. For example, Japan uses .co instead of .com and .ac (for academic) instead of .edu. Other subdomains that are frequently encountered within the ccTLDs include .go (government) and .re (research). To continue our fictitious example of anycollege, its domain name in Japan would be anycollege.ac.jp. This example is mapped out in Table 8-3.

Table 8-3. Construction of a Hierarchical Internet Name

Host Name

Subdomain

Second-Level Domain

Top-Level Domain

www

.anycollege

.ac

.jp


This example is important because it demonstrates that international users of the Internet have proven the viability of four-part FQDNs. The lack of absolute standardization for SLDs within ccTLDs hasn't hindered acceptance and/or use. A larger potential flaw lies tacitly in the fact that the very creation of ccTLDs implied that the generic TLDs were all but officially reserved for entities in the United States. Evidence of this bias can be seen in the relatively underutilized .us ccTLD.

The Case for Strong SLDs in the U.S.

Internet users in the United States have become accustomed to three-part addresses (hostname.SLD.TLD). Thus, within each generic TLD is a remarkable flatnessthe very thing we were trying to avoid. This flatness would be OK if it weren't for the lack of enforcement of the original intent. Lacking any enforcement mechanism, the result has been a chaotic and extremely problematic pattern of market behaviors. These behaviors include the following:

  • Financial speculation on domain names Immediately after the Internet was commercialized, individuals began speculating on the future value of specific domain names. For a mere $35 annual fee, risk-taking individuals could reserve well-known names such as Pepsi, BMW, or any other globally recognizable brand name. The individual would gladly surrender the domain name to anyone willing to pay him or her lots of money. No laws prohibited this. This practice has become known as cybersquatting, and the people who do it are cybersquatters.

  • Defending against name/trademark infringement A slightly more insidious game that was often seen amounted to little more than trademark infringement. Entrepreneurs would reserve a well-known name and then use it for their own purposes. Today, it is still quite easy to find online gambling, pornography, and other seedy uses of the Net operating behind domain names that are intentional misspellings of famous names.

  • Defending against name/trademark speculation Owners of famous names and trademarks have found it necessary to proactively defend against the type of abuses just described. Consequently, it is not uncommon to find some large companies that have registered dozens of domain names across the spectrum of available TLDs to protect their image and brands.

The combination of these three forces has resulted in an absolute dearth of good domain names within the generic TLDs. Given the flatness of those TLDs, the result is a general lack of available names.

Follow the Better Example

Other countries have made much better use of their ccTLD and have avoided the flatness trap. Operators of ccTLDs have alleviated global name collisions by carving out the functional equivalents of .com and .edu among other generic TLDs within their ccTLD. For example, a company's domain name in Japan would be mycompany.co.jp rather than simply mycompany.com. More importantly, the same locally-recognized name (mycompany, in this example) could be reused without worry, because .co.jp is a different domain than .com. Alternatively, different companies with the same name could take advantage of the segmentation afforded by this extra hierarchical layer. In effect, the same name is used in different parts of the world without fear of a name collision. This example is shown in tree format in Figure 8-3.

Figure 8-3. Hierarchical Structure of a Domain Name Within a Typical ccTLD


The original generic TLDs made sense. They were neither arbitrary nor capricious, and they served admirably as a logical groupingat least, they did until people stopped following the intent behind their mnemonics. Thus, a credible argument could be made in favor of embracing these generic TLDs as SLDs within the .us country code and then enforcing their original intent.

The .us ccTLD, in comparison to other ccTLDs, is underutilized. You could argue that the cultural reliance of Americans on the generic TLDs has prevented the .us ccTLD from becoming as well-developed as other ccTLD namespaces around the world. Alternatively, you could place the blame squarely on RFC 1480, which was published in June 1993, as the reason for the underutilization of the .us ccTLD. The next section discusses RFC 1480.

RFC 1480

RFC 1480 is remarkable in that it specified a substructure for .us. Other ccTLDs have had no such structure dictated, but it was recommended that the mnemonic functionality of the original generic TLDs be replicated within each ccTLD. In and of itself, this reinforces the parochial thinking of the early Internet and demonstrates just how U.S.-centric it was! This RFC called for the .us ccTLD to be carved up geographically rather than functionally. Thus, it contained more than 50 SLDsone for each state, plus a few others.

Furthermore, RFC 1480 called for a complex array of additional levels of subdomains. Including host names, an FQDN that fully complies with the hierarchical scheme posited in this document can result in a name that contains five or six names! The best way to understand this complex structure is to take it one layer at a time. For the sake of consistency, variable subdomain names appear in parentheses, and constants are explicitly identified.

Table 8-4 identifies SLDs that are direct children of .us. As such, they are parallel to the state's SLD. This relationship to .us and the Internet's root is depicted in Figure 8-4.

Figure 8-4. Hierarchical Structure of SLDs Within the .us ccTLD


Table 8-4. SLDs Within .us and Their Intended Uses

TLD

Description

.fed

Despite the fact that there is already a .gov TLD, RFC 1480 called for the creation of an SLD under the .us TLD that would be reserved for use by the U.S. Federal Government and its myriad branches. A fictitious example (I don't know of any real ones!) is www.fedbranch.fed.us.

.dni

This SLD was created for distributed, but national, institutes within the U.S. Such organizations would span multiple states, municipalities, and so on. Although I can understand why someone would have thought this important, dni is hardly mnemonic, and I can't think of a single example that would showcase this SLD.

.(state)

Each state was given its own SLD, identified by postal abbreviations. For example, PA is Pennsylvania, NY is New York, and so on. This SLD branches into a complex array of subdomains that extend for several levels.


Of the various SLDs within .us presented in Table 8-4, the most interesting and complex is the .(state) variable name. The .(state) subdomains are explained in Table 8-5, and their hierarchical relationship is shown in Figure 8-5.

Figure 8-5. Hierarchical Structure of Subdomains Within the .(state).us Domain


Table 8-5. Subdomains Under .(state).us and Their Intended Uses

TLD

Description

.state

Just to make things challenging for newbies (OK, so maybe it just feels that way), a .state subdomain was created under the .(state) SLD for use by that state's government branches. To better illustrate this, Pennsylvania's official state Web site is www.state.pa.us. The .(state) SLD is a variable; in this example it takes the value of .pa. Directly below .pa is the subdomain with the constant name of .state. This naming convention applies for all 50 states. This naming convention, though counterintuitive, complies with RFC 1480. Anyone accustomed to thinking logically would presume that pa is a subset of state.us rather than state's being a subset of pa.us.

(locality)

A wildcard subdomain of .(state) is .(locality). Not every government branch is part of the state government. There are county, municipal, and city government branches. These can be identified explicitly under .(state) directly, rather than appearing as a child of .state.

Valid "localities" can include cities, counties, parishes, and townships. An additional sublayer of domain names exists in the form of the reserved names .ci and .co. These names are constants, just like .state, and they let city and county government agencies be explicitly identified in an FQDN. A fictitious example that identifies the Web site of the police department of the city of Easton, Pennsylvania might be www.police.ci.easton.pa.us.

Alternatively, a county might be too rural to support well-developed cities. Another fictitious example of a police department in Pike County, Pennsylvania might be www.police.co.pike.pa.us.

The real question is, does the specificity afforded by these types of hierarchical names provide value to the organizations that the hierarchy was developed for? The answer appears to be no. Those organizations appear to prefer shorter, more-succinct, but less-specific domain names.

.gen

Conceived as a catchall for any organizations that don't fall neatly into any of the other RFC 1480 domains or subdomains, .gen refers to general independent entities. I have never been able to find any domain names created within this subdomain. If there were such a name, the domain name for Acme Products (I always root for the Coyote) in Arizona would be acme.gen.az.us.

.lib

Libraries, too, were given a reserved subdomain under .(state).us. Not many libraries use the .lib.(state).us domain. One library that does is the Hunterdon County Library in New Jersey. Its URL is www.hunterdon.lib.nj.us.

.cc

The .edu TLD has had a checkered past. It was originally set aside for all educational organizations, but then it shifted to just colleges and universities in the U.S. that conferred baccalaureate and/or masters degrees. This left out community colleges! Ostensibly, this was done to minimize the potential for name collisions among U.S.-based institutions of higher learning, but it relegated two-year schools to a subdomain under the .us ccTLD. Under this scheme, Raritan Valley Community College (another of my alma maters!) would have a Web presence at www.rvcc.cc.nj.us.

Although this isn't a terrible domain name, it is much more difficult to remember than www.raritanval.edu (the actual Web site). Over time, U.S. colleges have demonstrated their preference for shorter, less-complex domain names by registering for mnemonic names in the .edu TLD.

.tec

Similar to community colleges, vocational and technical schools were also given a subdomain of their own. A typical school in New York might use the Web site www.vo-tech.tec.ny.us. Then again, they would be more likely to just register a domain name in .edu!

.k12

Yet another branch of education is kindergarten through 12th grade. In theory, schools in this category can register domain names in this subdomain. A fictitious example might be www.(school-name).k12.nj.us. Some public schools use this branch of the .us ccTLD, but you would have to search to find them.


Given this convoluted structure, the mnemonic nature of domain names becomes lost. Names defined inside .us have the potential to be up to six levels deep. At that level of complexity, you're better off just using raw IP addresses! OK, so maybe IP addresses are a bit of a stretch, but the fact remains that the .us ccTLD is underutilized. Entities that qualify for names within its stipulated substructure prefer shorter, more mnemonic names within the .org, .com, and even .net TLDs. Only government agencies seem to still use the structure set forth in RFC 1480. Even those agencies don't completely use the .us TLD. It is relatively easy to find such agencies with domains in .edu, .gov, .org, and even .com.

The irony hidden in the wreckage of RFC 1480-inspired domain names is that technological advances have diminished the significance of names as a means of accessing Internet sites. Search engines and sophisticated algorithms for gathering, categorizing, indexing, and keyword searching make it easier than ever to find information on the Internet, regardless of how simple or convoluted a host's domain name might be.

A recent interesting development that might obsolete RFC 1480 and rejuvenate the .us namespace is that Neustar, Inc. (www.neustar.com/) was recently awarded a contract to manage the .us namespace. Neustar has proposed expanding the .us ccTLD to allow registrations of domain names in the second level of .us. Simultaneously, they have proposed opening this namespace for competition between registrars. Together, these efforts are intended to create a more meaningful use of this namespace. Whether it will be successful remains to be seen.

Newly-Created TLDs

After a protracted debate, ICANN accepted a recommendation to expand the Internet's TLD namespace. Numerous issues were explored, but all parties generally agreed that there was pent-up demand for additional namespace. The areas of disagreement tended to be the following:

  • Which new TLDs would generate the greatest benefit for the Internet's user community

  • Who gets granted the right to sell names in any given new TLD and how that is decided

  • How to protect the trademarks, trade names, and other publicly visible forms of intellectual property owned by any given company in an expanded Internet namespace

After vigorous, and thorough, debate, the working group assigned by ICANN to explore this issue offered a recommendation to expand the Internet's namespace with seven new TLDs. Of these seven, three would be sponsored. That is, they would be intentionally designed to serve a specific niche, and appropriate mechanisms would be developed to ensure that people and/or organizations attempting to register any names within that sponsored TLD met the criteria set forth in advance.

Table 8-6 identifies the new TLDs, specifies whether they are sponsored, and describes their intended purposes.

Table 8-6. Newly-Sanctioned TLDs

TLD

Sponsored?

Purpose

.aero

Yes

Air-transport industry

.biz

No

Businesses (an alternative to .com)

.coop

Yes

Cooperative organizations

.info

No

Not defined or restricted

.museum

Yes

Chartered museums only

.name

No

Individual people and families

.pro

No

Professionals such as accountants, lawyers, physicians, and so on


Not all of these currently can accept name registrations. Over time, all are expected to become operational. For more details, and up-to-date information on the status of these TLDs, refer to www.icann.org/tlds.

Sponsored Versus Unsponsored

The notion of a sponsored namespace actually isn't a very new concept. The original, generic TLDs were selected for specific niches, albeit very broad ones. In other words, they had a charter. Unfortunately, no one enforced their charter, and they became increasingly generalized over time. Many of the problems that have directly contributed to the near-depletion of meaningful names in the original generic TLDs can be attributed to the lack of enforcement mechanisms.

A direct corollary can be seen in the telephone system. The 800 toll-free number range was nearing depletion, so a plan was formulated to deploy 888 as an additional range of toll-free numbers. Unfortunately, many companies and organizations that had an 800 number (along with a fair bit of money invested in its advertisement) felt compelled to protect their investment by claiming the same number in the new range. Thus, the new range was nearly depleted shortly after it was put into service. Consequently, the 877 number range was opened for the same purpose, but it too suffered a similar premature depletion. Recently, 866 was assigned for toll-free calling. It seems likely that duplication of numbers from 877, 888, and 800 will prematurely exhaust even this new supply of numbers.

The same problem awaits TLD expansion. The only way to avoid this is to craft TLDs for a narrow, specific purpose and have a highly mnemonic name. Yet even this won't completely mitigate the problems that plague the Internet's namespace. Additional protective measures must include sentinels that watch over each portion of the namespace. Such sentinels, better known as sponsors, enter into agreements with ICANN for specific TLDs and operate them in a manner consistent with ICANN's goals. TLDs that lack sponsorship will continue to experience the same set of cybersquatting versus counter-cybersquatting market dynamics that have plagued the original generic and unsponsored TLDs.

Clever ccTLD Reuses

ccTLDs offer some potential for clever dual uses. Moldava, for example, uses the .md ccTLD. This character string lends itself nicely to the medical field in English-speaking parts of the world. It doesn't take tremendous imagination to see why a physician would prefer a domain name within .md as opposed to the same name in .pro or even .com. Simply stated, .md immediately, specifically, and unambiguously conveys their profession.

Another ccTLD that enjoys a highly mnemonic character string is Tuvalu. That country uses the .tv ccTLD, which also suggests a dual use in the Anglo-speaking world. The television industry could benefit tremendously from registering certain names within that country code.

Carving out mnemonic niches can be a potential source of revenue for emerging countries via the use of an underutilized asset. Linguistic differences also likely mean that the opportunity for name collisions to occur is remarkably small despite the domain's dual use. Unfortunately, the mnemonic value of a ccTLD varies greatly from country to country. Thus, not every nation recognized with a ccTLD will be able to successfully remarket name registrations to specialty niches.

Obtaining Your Very Own Namespace

Thanks to the mechanics of a free-market economy, obtaining your own namespace has never been easier. Your friendly neighborhood Internet service provider (ISP) can usually accommodate your request for a domain name on your behalf.

Alternatively, numerous entities are willing to sell the rights to use a namespace (caveats!) directly to you on an annual basis. Frequently, a valid credit card lets you complete this process online. ICANN currently recognizes about 90 legitimate registrars around the world. Dozens more companies have completed the accreditation process but have not yet become operational as domain name registrars. For a complete list of registrars, visit www.icann.org/registrars/accredited-list.html.

Be careful when selecting a registrarthey are not functional clones. Some registrars are chartered for only certain countries, and others are limited to selling namespace within specific top-level domains. Thus, it is imperative that you understand your particular needs and then conduct some research before attempting to register your own namespace.

Resolving Conflicts

Unfortunately, conflicts over name ownership happen far more often than I care to admit. Only in rare cases does a domain name actually reflect a truly global brand name that is so recognizable as to defy infringement. For example, Coca-Cola, AT&T, and IBM are well-recognized brand names in all corners of the world. Other names, such as "White House," are much more ambiguous. This can identify everything from the building located at 1600 Pennsylvania Avenue in Washington, DC to a fruit juice maker to an Internet pornographer. The question is, who has the legal right to the Internet name? This remarkably simple question is excruciatingly painful to answer.

Boiled down to its simplest, "White House" is a fictitious name under which an entity seeks to do business. Fictitious name registrations are obtained from the state within which a U.S.-based company is incorporated or headquartered. Those local government branches only verify that the name is unique within their purview; they do not attempt to establish a name's global uniqueness before granting the local rights to use it.

In the old days (before Al Gore invented the Internet), this made perfect sense. Today, however, even small companies can legitimately have global aspirations. So who gets whitehouse.com? And should that entity also have dibs on every possible permutation of that name? Would white-house.com, whitehouse.net, or even whithouse.com be confusing? (Note that last intentional misspelling. Many Web site operators intentionally select SLD names that are a simple typo away from large, well-traveled sites in the hopes of luring unsuspecting visitors.) Could someone claim brand infringement? Again, these are easy questions to ask, yet they all but defy answering.

ICANN has bogged down under the crushing weight of the legal and political entanglements of these superficially simple questions. It has embraced a Uniform Domain-name Dispute-Resolution Policy (UDRP). (OK, so the acronym doesn't quite fit the name. I didn't make it up!) This policy, although not intended to obviate conflicts over names, provides a framework for resolving the inevitable conflicts. Essentially, it placates owners of trademarks and other famous names by protecting them from cybersquatters. ICANN's policy can be found at www.icann.org/udrp/.




IP Addressing Fundamentals
IP Addressing Fundamentals
ISBN: 1587050676
EAN: 2147483647
Year: 2002
Pages: 118
Authors: Mark Sportack

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net