Domain names

Domain name

This article primarily discusses registered domain names. See the Domain Name System article for technical discussions about general domain names and the hostname article for further information about the most common type of domain name.

The main purpose of a domain name is to provide a recognizable names to mostly numerically addressed Internet resources. This abstraction allows any resource (e.g., website) to be moved to a different physical location in the address topology of the network, globally or locally in an intranet, in effect changing the IP address.

Registered domain names are restricted to using the same characters as all other hostnames, as such they typically can only use ASCII letters, numbers, the hyphen (-), with the dot (.) used to separate DNS labels. Since this definition does not allow the use of many characters commonly found in non-English languages, and no multi-byte characters necessary for most Asian languages, the Internationalized domain name (IDN) system has been developed and is now in testing stage with a set of top-level domains established for this purpose.

The underscore character is frequently used to ensure that a domain name is not recognized as a hostname, as with the use of SRV records, for example, although some older systems such as NetBIOS did allow it. To avoid confusion and for other reasons, domain names with underscores in them are sometimes used where hostnames are required.

Domain names are often referred to simply as domains and domain name registrants are frequently referred to as domain owners, although domain name registration with a registrar does not confer any legal ownership of the name, only an exclusive right of use.

As a general rule, the IP address and the server name are interchangeable. For most Internet services, the server will not have any way to know which was used. However, the explosion of interest in the Web means that there are far more Web sites than servers. To accommodate this, the hypertext transfer protocol (HTTP) specifies that the client tells the server which name is being used. This way, one server with one IP address can provide different sites for different domain names. This feature goes under the name virtual hosting and is commonly used by web hosts.

When a request is made, the data corresponding to the hostname requested is provided to the user.

Every domain name ends in a top-level domain (TLD) name, which is always either one of a small list of generic names (three or more characters), or a two-character territory code based on ISO-3166 (there are few exceptions and new codes are integrated case by case). Top-level domains are sometimes also called first-level domains.

Below the top-level domains in the domain name hierarchy are the second-level domain (SLD) names. These are the names directly to the left of .com, .net, and the other top-level domains. As an example, in the domain en.wikipedia.org, wikipedia is the second-level domain.

Next are third-level domains, which are written immediately to the left of a second-level domain. There can be fourth- and fifth-level domains, and so on, with virtually no limitation. An example of a working domain with four domain levels is www.sos.state.oh.us. The www preceding the domains is a host name of the World-Wide Web server. Each level is separated by a dot, or period symbol. 'sos' is said to be a sub-domain of 'state.oh.us', and 'state' a sub-domain of 'oh.us', etc. In general, Sub-domains are domains subordinate to their parent domain. An example of very deep levels of subdomain ordering are the IPv6 reverse resolution DNS zones, e.g., 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa, which is the reverse DNS resolution domain for the IP address of a loopback interface, or the localhost name.

Second-level (or lower-level, depending on the established parent hierarchy) domain names are often created based on the name of a company (e.g., microsoft.com), product or service (e.g., gmail.com). Below these levels, the next domain name component has been used to designate a particular host server. Therefore, ftp.wikipedia.org might be an FTP server, www.wikipedia.org would be a World Wide Web server, and mail.wikipedia.org could be an email server, each intended to perform only the implied function. Modern technology allows multiple physical servers with either different (cf. load balancing) or even identical addresses (cf. anycast) to serve a single hostname or domain name, or multiple domain names to be served by a single computer. The latter is very popular in Web hosting service centers, where service providers host the websites of many organizations on just a few servers.

The Internet Corporation for Assigned Names and Numbers (ICANN) has overall responsibility for managing the DNS. It administers the root domain, delegating control over each TLD to a domain name registry. For ccTLDs, the domain registry is typically installed by the government of that country. ICANN has a consultation role in these domain registries but cannot regulate the terms and conditions of how domain names are delegated in each of the country-level domain registries. On the other hand, the generic top-level domains (gTLDs) are governed directly under ICANN, which means all terms and conditions are defined by ICANN with the cooperation of each gTLD registry.

Domain names are often seen in analogy to real estate in that (1) domain names are foundations on which a website (like a house or commercial building) can be built and (2) the highest "quality" domain names, like sought-after real estate, tend to carry significant value, usually due to their online brand-building potential, use in advertising, search engine optimization, and many other criteria.

A few companies have offered low-cost, below-cost or even cost-free domain registrations with a variety of models adopted to recoup the costs to the provider. These usually require that domains be hosted on their website within a framework or portal that includes advertising wrapped around the domain holder's content, revenue from which allows the provider to recoup the costs. Domain registrations were free of charge when the DNS was new. A domain holder (often referred to as a domain owner) can give away or sell infinite number of subdomains under their domain name. For example, the owner of example.edu could provide subdomains such as foo.example.edu and foo.bar.example.edu to interested parties.

As domain names became interesting to marketers because of their advertising and marketing potential, rather than just being used to label Internet resources in a technical fashion, they began to be used in manners that in many cases did not reflect the intended purpose of the label of their top-level domain. As originally planned, the structure of domain names followed a hierarchy in which the TLD indicated the type of organization (commercial, governmental, etc.), and addresses would be nested down to third, fourth, or further levels to express complex structures, where, for instance, branches, departments and subsidiaries of a parent organization would have addresses in subdomains of the parent domain. Also, hostnames were originally intended to correspond to actual physical machines on the network, generally with only one name per machine.

As the World Wide Web became popular, site operators frequently wished to have memorable addresses, regardless of whether they fit properly into the structure; thus, because the .com domain was the most popular and therefore most prestigious, even noncommercial sites began to obtain domains directly within that gTLD, and many sites desired second-level domain names in .com, even if they were already part of a larger entity where a subdomain would have been logical (e.g., abcnews.com instead of news.abc.com).

The popularity of domain names also led to uses which were regarded as abusive by established companies with trademark rights; this has become known as cybersquatting, in which a person registers a domain name that resembles a trademark in order to profit from visitors looking for that address. To combat this, various laws and policies were enacted to allow abusive registrations to be forcibly transferred, but these were sometimes themselves abused by overzealous companies committing reverse domain hijacking against domain users who had legitimate grounds to hold their names. Such legitimate uses could include the use of generic words that are contained within a trademark, but used in a particular context within the trademark, or their use in the context of fan or protest sites with free speech rights of their own.

As of 2008, the four major Registrars have all sub-contracted their expiring domain lists to certain reseller and auctioneer partnerships, for the purpose of keeping the domain name at the original registrar and continuing to extract revenue off the renewal of premium registered names. Since this policy is not explicitly banned at ICANN, the practice has become more commonplace and as a result, complaints from individual registrants about losing their domains has tracked higher over the past two years .

Laws that specifically address domain name conflicts include the Anticybersquatting Consumer Protection Act in the United States and the Trademarks Act of 1999 in India. Alternatively, domain registrants are bound by contract under the UDRP to comply with mandatory arbitration proceedings should someone challenge their ownership of a domain name.

Within a particular TLD, parties are generally free to register an undelegated domain name on a first come, first served basis, resulting in Harris's lament, all the good ones are taken. For generic or commonly used names, this may sometimes lead to the use of a domain name which is inaccurate or misleading. This problem can be seen with regard to the ownership or control of domain names for a generic product or service. By way of illustration, there has been tremendous growth in the number and size of literary festivals around the world in recent years. In the current context, a generic domain name such as literary.org is available to the first literary festival organization that is able to obtain the registration, even if the festival in question is very young or obscure. Some critics argue that there is greater amenity in reserving such domain names for the use of, for example, a regional or umbrella grouping of festivals. Related issues may also arise in relation to noncommercial domain names.

Due to the rarity of one-word dot-com domain names, many unconventional domain names, domain hacks, have been created. They make use of the top-level domain as an integral part of the Web site's title. Two popular domain hack Web sites are cr.yp.to and blo.gs, which spell out "crypto" and "blogs", respectively.

Unconventional domain names are also used to create unconventional email addresses. Non-working examples that spell 'James' are j@m.es and j@mes.com, which use the domain names m.es (of Spain's .es) and mes.com, respectively.

In the business of marketing domain names, "premium" domain names are often valuable, and have particular characteristics. For example, the names are short and memorable, or may contain words that are regularly searched on search engines, or keywords that help the name gain a higher ranking on search engines. They may contain generic words, so the word has more than one meaning, and they may contain common typos.

The business of resale of previously registered domain names is known as the "domain aftermarket".

Various factors influence the perceived value or market value of a domain name. They include 1) the natural or "organic" traffic that can be attributed to web surfers typing in a domain name in their web browser as opposed to doing a search for the site through a search engine. 2) Branding Opportunity. The ability to have a term recognized and easily recalled as a brand for a company or entity. 3) Re-sale value. The ability to spot trends and predict the value of a name based on its length (short is preferred), clarity, and commercial use. The word loan is far more valuable than the word sunshine.

Generic domain names have sprung up in the last decade. Certain domains, especially those related to business, gambling, pornography, and other commercially lucrative fields of digital world trade have become very much in demand to corporations and entrepreneurs due to their importance in attracting clients.

There are disputes about the high values of domain names claimed and the actual cash prices of many sales such as Business.com. Another high-priced domain name, sex.com, was stolen from its rightful owner by means of a forged transfer instruction via fax. During the height of the dot-com era, the domain was earning millions of dollars per month in advertising revenue from the large influx of visitors that arrived daily. The sex.com sale may have never been final as the domain is still with the previous owner. Also, that sale was not just a domain but an income stream, a web site, a domain name with customers and advertisers, etc. Two long-running U.S. lawsuits resulted, one against the thief and one against the domain registrar VeriSign . In one of the cases, Kremen v. Network Solutions, the court found in favor of the plaintiff, leading to an unprecedented ruling that classified domain names as property, granting them the same legal protections. In 1999, Microsoft traded the name Bob.com with internet entrepreneur Bob Kerstein for the name Windows2000.com which was the name of their new operating system.

One of the reasons for the value of domain names is that even without advertising or marketing, they attract clients seeking services and products who simply type in the generic name. This is known as Direct Navigation or Type-in Traffic. Furthermore, generic domain names such as movies.com (now owned by Disney) or Books.com (now owned by Barnes & Noble) are extremely easy for potential customers to remember, increasing the probability that they become repeat customers or regular clients. In the case of Movies.com, Disney has built a stand-alone portal featuring branded content. More and more large brands are beginning to employ a more comprehensive domain strategy featuring a portfolio of thousands of domains, rather than just one or two.

Although the current domain market is nowhere as strong as it was during the dot-com heyday, it remains strong and is currently experiencing solid growth again. Annually tens of millions of dollars change hands in connection with the resale of domains. Large numbers of registered domain names lapse and are deleted each year. On average, more than 25,000 domain names drop (are deleted) every day.

It is important to remember that a domain (name, address) must be valued separately from the website (content, revenue) that it is used for. The high prices have usually been paid for the revenue that was generated from the website at the domain's address (URL.). The intrinsic value of a domain is the registration fee. It is difficult to appraise a current market value for a domain. The Fair Market Value of a domain can be anything from nearly nothing to millions of dollars. Factors involved may include previous sales data of similar domains, however a single letter difference can completely alter the value. The value of the domain (or any sum resp. division etc.) are usually added to the current or expected revenue from the web content (advertising, sales, etc.). The price of a domain (name + ext.) should not be confused with that of a website (content + revenue).

An estimate by an appraiser is always the addition of what they would like a domain to be worth together with the effective/expected/desired revenue from the web content. Some people put value on the length of the SLD (name) and other people prefer description capability, but the shorter an SLD is, the less descriptive it can be. Also, if short is crucial, then the TLD (extension) should be short too. It is less realistic to get a domain like LL.travel or LL.mobi than a domain travel. LL or mobi. LL. This illustrates the relativity of domain value estimation. It is safe to say that the revenue of web (content) can be easily stated, but that the value of a domain (SLD.TLD aka name.ext) is a matter of opinion and preference. In the end, however, any sale depends on the expectations of the domain seller and the domain buyer.

A webmaster creating a new web site either buys the domain name directly from a domain name registrar, or indirectly from a domain name registrar through a domainer. People who buy and sell domain names are known as domainers. People who sell value estimation services are known as appraisers.

Domain name sales occurring in the aftermarket are frequently submitted to the DN journal. The sales are listed weekly and include the top aftermarket resellers which include but are not limited to Sedo, Traffic (auctions), Afternic, NameJet, Moniker and private sales.

The week ending January 27, 2008, DNJournal reported that CNN, a cable news channel purchased iReport.com for $750,000. This signifies another turning point in domain name sales. This name has neither organic traffic, nor does it have a dictionary term alone. Instead it is a highly brandable domain name utilizing the second most popular prefix for a "dictionary" and commercial word.

In addition to a domain placing value on the shortness of the word, ease in spelling, commercial appeal, and organic capacity to generate natural traffic, today's domain names are being valued for the branding potential. The domain name sale iReport although not an organic or dictionary term alone, is actually preferred as a highly brandable term, in that it is has a popular pre-fix "i" which indicates the "report" to be online.

The prefixes and dashes between words were once considered second, but now due to brandability, if the term is a commercial term, a prefix is often preferred. Example eLoans markets with an e to indicate to its potential customers that a loan may be obtained online.

The two primary prefixes are "E", for electronic, and "I", for Internet. Both indicate the word or phrase to be accessible online. Because of that, in terms of branding, an i or e combined with a commercial term are highly desirable. In domain sales typically an e has been preferred, and i slightly less in terms of demand. eBrooklyn sold for approximately $2500 whereas once it would have been available to register at the price of a domain name (which ranges from $8 to $30 us dollars depending on the registrar). The rapidly increasing use of prefixes in conjunction with main dictionary and or commercial terms is here and for some predominantly internet based companies, or high technology, high profile companies, the prefix is now preferred.

One of the details that make a domain with a prefix more valuable for a brand, is the ability to simply promote the name without the use of ".com" in the promotion. If a domain owner had report.com he would be forced to use the .com to indicate it was on the net at that address, however a domain name with a one letter prefix does not need to use the ".com".

Someone could promote "iReport" as a brand, and assuming it was a world class brand, visitors would know they could find it at "iReport.com without seeing the .com. However if it was a .net, it would be wise to state iReport.net. This option to simply state the name of the company or entity is particularly valuable in that it is brief and clear in indicating that a report can be either made or found on the "i"nternet.

Some alternative domains that avoid the use of ".com" in their promotion are "WebMD" as the word web as a prefix suffice to indicate the information is online and likely at a .com extension.

Brands are greatly affected by the ability of the company to obtain the matching domain name. If a company builds a brand around a name to which it does not own the domain name, it can end up directing traffic to another domain owner's site. If it is a competitor, this would be a problem.

Today's advertising development of a great brand is strictly confined to the availability to synchronize the brand with a domain name. Any confusion might result in a competitor gaining valuable internet traffic and possible customers.

Intercapping is often used to clarify the meaning of a domain name. However, DNS is case-insensitive, and some names may be misinterpreted when converted to lowercase. For example: Who Represents, a database of artists and agents, chose whorepresents.com, which can be misread as whore presents dot com. Similarly, a therapists' network thought therapistfinder.com looked good. Other examples include cummingfirst.com, the website (as of August 2007) of the Cumming First United Church in Cumming, GA and powergenitalia.com, the website of an Italian Power Generator company. In such situations, the proper wording can be clarified by use of hyphens. For instance, Experts Exchange, the programmers' site, for a long time used expertsexchange.com, but ultimately changed the name to experts-exchange.com.

Leo Stoller threatened to sue the owners of StealThisEmail.com on the basis that, when read as stealthisemail.com, it infringed on claimed trademark rights to the word "stealth". There is no word mark for "stealth" in the USPTO trademark database and Leo Stoller's trademarks on this term were cancelled.

To the top

Domain Name System Security Extensions

Some of these problems are in the process of being resolved, and deployments in various domains have begun to take place.

The original design of the Domain Name System (DNS) did not include security, instead it was designed to be a scalable distributed system. The Domain Name System Security Extensions (DNSSEC) attempts to add security, while maintaining backwards compatibility. RFC 3833 attempts to document some of the known threats to the DNS and how DNSSEC responds to those threats.

DNSSEC was designed to protect Internet resolvers (clients) from forged DNS data, such as that created by DNS cache poisoning. All answers in DNSSEC are digitally signed. By checking the digital signature, a DNS resolver is able to check if the information is identical (correct and complete) to the information on the authoritative DNS server. While protecting IP addresses is the immediate concern for many users, DNSSEC can protect other information such as general-purpose cryptographic certificates stored in CERT records in the DNS. RFC 4398 describes how to distribute these certificates, including those for email, making it possible to use DNSSEC as a world-wide public key infrastructure for email.

DNSSEC does not provide confidentiality of data, in particular, all DNSSEC responses are authenticated but not encrypted. DNSSEC does not protect against DoS attacks directly, though it indirectly provides some benefit (because signature checking allows the use of potentially untrustworthy parties). Other standards (not DNSSEC) are used to secure bulk data (such as a zone transfer) sent between DNS servers. As documented in IETF RFC 4367, some users and developers make false assumptions about DNS names, such as assuming that a company's common name plus ".com" is always its domain name. DNSSEC cannot cure false assumptions; it can only authenticate that the data is truly from or not available from the domain owner.

The DNSSEC specifications (called DNSSEC-bis) describe the current DNSSEC protocol in great detail. See RFC 4033, RFC 4034, and RFC 4035. With the publication of these new RFCs (March 2005), RFC 2535 has become obsolete.

DNSSEC works by digitally signing answers to DNS lookups using public-key cryptography. To do this, several new DNS record types were created, including the RRSIG, DNSKEY, DS, and NSEC DNS records. When DNSSEC is used, each answer to a DNS lookup will contain a RRSIG DNS record, in addition to the record types that were requested. The RRSIG record is a digital signature of the answer DNS resource record set. The digital signature can be verified by locating the correct public key found in a DNSKEY record.

From the results, a security-aware DNS resolver can then determine if the answers it received was correct (secure), whether the authoritative name server for the domain being queried doesn't support DNSSEC (insecure), or if there is some sort of error. The correct DNSKEY record is found via an Authentication Chain, starting with a known good public key for a Trust Anchor. This public key can then be used to verify a designated signer (DS) record. A DS record in a parent domain (DNS zone) can then be used to verify a DNSKEY record in a subdomain, which can then contain other DS records to verify further subdomains.

Say that you want to get the IP addresses (A records) of the domain 'www.example.com'.

The process starts when a security-aware resolver sets the 'DO' flag bit in a DNS query. Since the DO bit is in the extend flag bits defined by EDNS, all DNSSEC transactions must support EDNS. EDNS support is also needed to allow for the much larger packet sizes that DNSSEC transactions require.

When the resolver receives an answer via the normal DNS lookup process, it then checks to make sure that the answer is correct. In theory, the security-aware resolver would start with verifying the DS and DNSKEY records at the DNS root. Then, in our example, it would use the DS records for the 'com' top level domain found at the root to verify the DNSKEY records in the 'com' zone. From there, it would see if there is a DS record for the 'example.com' subdomain in the 'com' zone, and if there was, it would then use the DS record to verify a DNSKEY record found in the 'example.com' zone. Finally, it would verify the RRSIG record found in the answer for the A records for 'www.example.com'.

There are several exception cases with the above example.

First, if 'example.com' does not support DNSSEC, you will not get a RRSIG record in the answer and there will not be a DS record for 'example.com' in the 'com' zone. If there is a DS record for 'example.com', but no RRSIG record in the reply, something is wrong and maybe a man in the middle attack is going on, stripping the DNSSEC information and modifying the A records. Or, it could be a broken security-oblivious name server along the way that stripped the DO flag bit from the query or the RRSIG record from the answer. Or, it could be a configuration error.

Next, it may be that there isn't a domain name named 'www.example.com', in which case instead of returning a RRSIG record in the answer, you will get either an NSEC record or an NSEC3 record. These are "next secure" records that allow the resolver to prove that a domain name does not exist. The NSEC/NSEC3 records have RRSIG records, which can be verified as above.

Finally, it may be that the 'example.com' zone implements DNSSEC, but either the 'com' zone or the root zone do not and you have an Island of Security. These islands of security need to be validated some other way. In practice, As of 2009, neither the root nor the 'com' domains are currently signed.

In order to be able to prove that a DNS answer is correct, you need to know at least one key that is correct form sources other than the DNS. These starting points are known as Trust Anchors and are typically obtained with the operating system or via some other trusted source. When DNSSEC was originally designed, it was thought that the only Trust Anchor that would be needed is for the DNS root. However, As of 2009 the root has not yet been signed, which has lead to the Deployment of alternative trust anchors to the DNS root.

An Authentication Chain is a series of linked DS and DNSKEY records, starting with a Trust Anchor to the authoritative name server for the domain in question. Without a complete Authentication Chain, a answer to a DNS lookup can not be securely authenticated.

DNSSEC involves many different keys, stored both in DNSKEY records, and from other sources to form Trust Anchors.

DNS is a critical and fundamental Internet service, yet in 1990 Steve Bellovin discovered serious security flaws in it. Research into securing it began, and dramatically increased when his paper was made public in 1995. The initial RFC 2065 was published by the IETF in 1997, and initial attempts to implement that specification led to a revised (and believed fully workable) specification in 1999 as IETF RFC 2535. Plans were made to deploy DNSSEC based on RFC 2535.

Unfortunately, the IETF RFC 2535 specification had very significant problems scaling up to the full Internet; by 2001 it became clear that this specification was unusable for large networks. In normal operation DNS servers often get out of sync with their parents. This isn't usually a problem, but when DNSSEC is enabled, this out-of-sync data could have the effect of a serious self-created denial of service. The original DNSSEC required a complex six-message protocol and a lot of data transfers to perform key changes for a child (DNS child zones had to send all of their data up to the parent, have the parent sign each record, and then send those signatures back to the child for the child to store in a SIG record). Also, public key changes could have absurd effects; for example, if the ".com" zone changed its public key, it would have to send 22 million records (because it would need to update all of the signatures in all of its children). Thus, DNSSEC as defined in RFC 2535 could not scale up to the Internet.

The IETF fundamentally modified DNSSEC, which is called DNSSEC-bis when necessary to distinguish it from the original DNSSEC approach of RFC 2535. This new version uses "delegation signer (DS) resource records" to provide an additional level of indirection at delegation points between a parent and child zone. In the new approach, when a child's master public key changes, instead of having to have six messages for every record in the child, there is one simple message: the child sends the new public key to its parent (signed, of course). Parents simply store one master public key for each child; this is much more practical. This means that a little data is pushed to the parent, instead of massive amounts of data being exchanged between the parent and children. This does mean that clients have to do a little more work when verifying keys. More specifically, verifying a DNS zone's KEY RRset requires two signature verification operations instead of the one required by RFC 2535 (there is no impact on the number of signatures verified for other types of RRsets). Most view this as a small price to pay, since it changes DNSSEC so it is more practical to deploy.

Although the goal of DNSSEC is to increase security, DNSSEC as defined in RFCs 4033 through 4035 introduces a new problem that many believe is a new security vulnerability: the zone enumeration (aka zone walking) issue. DNSSEC forces the exposure of information that by normal DNS best practice is kept private. NSEC3 (RFC 5155) was developed to address this issue; it was released in March 2008.

Arguably even more important than controlling who can query your name server is ensuring that only your real slave name servers can transfer zones from your name server. Users on remote hosts... can only look up records (e.g., addresses) for domain names they already know, one at a time... It's the difference between letting random folks call your company's switchboard and ask for John Q. Cubicle's phone number sending them a copy of your corporate phone directory.

In addition, the information from an enumerated zone can be used as a key for multiple WHOIS queries; this would reveal registrant data which many registries are under strict legal obligations to protect under various contracts.

It is unclear whether DNSSEC is legal to deploy at all in many countries, unless such lists can be kept private. DENIC has stated that DNSSEC's zone enumeration issue violates Germany's Federal Data Protection Act, and other European countries have similar privacy laws forbidding the public release of certain kinds of information.

DNSSEC introduces the ability for a hostile party to enumerate all the names in a zone by following the NSEC chain. NSEC RRs assert which names do not exist in a zone by linking from existing name to existing name along a canonical ordering of all the names within a zone. Thus, an attacker can query these NSEC RRs in sequence to obtain all the names in a zone. Although this is not an attack on the DNS itself, it could allow an attacker to map network hosts or other resources by enumerating the contents of a zone.

There is an "obvious" solution, called a split-horizon DNS, which is how DNS without DNSSEC is sometimes deployed – but this approach does not work well with DNSSEC. In the "split-horizon DNS" approach, the DNS server denies the existence of names to some clients, and provides correct information to other clients. However, since DNSSEC information is cryptographically signed as authoritative, an attacker could request the signed "does not exist" record, then retransmit the record to cause a denial of service. DNSSEC fundamentally changes DNS so it can provide authoritative information; thus, it does not work well with methods based on providing false information to some users.Research has produced recommendations to properly combine these two DNS features.

The reason DNSSEC introduced this problem is because it must be able to report when a name is not found. Most believe DNS servers supporting DNSSEC must be able to sign that not-found report – otherwise a not-found report could be easily spoofed. Yet for security reasons the signing key should not be online. As a result, DNSSEC was designed to report a signed message that reports that a given range of names does not exist, which can be signed ahead-of-time offline. Unfortunately, this information is enough for an attacker to gain much more information than would have been available to them otherwise – it is enough to enable an attacker to quickly gather all the names in a zone, and then through targeted queries on the names to reconstruct all or most of a zone's data.

Many of the participants on the IETF DNS Extensions working group originally stated that zone enumeration was not a significant problem, arguing that the DNS data was—or should be—public. However, registrars and many large organizations told the working group members that DNSSEC as currently defined was unacceptable, and that they would not or legally could not deploy it.

After deliberation, an extension was developed: "DNSSEC Hashed Authenticated Denial of Existence" (informally called "NSEC3"). In this approach, DNSSEC-aware servers can choose to send an "NSEC3" record instead of an NSEC record when a record is not found. The NSEC3 record is signed, but instead of including the name directly (which would enable zone enumeration), the NSEC3 record includes a cryptographically hashed value of the name. The NSEC3 record includes both a hash after a number of iterations and an optional salt. Salt, where used, increases the number of pre-computed dictionaries that an attacker using a pre-computed dictionary attack would need to create, increasing iteration values raise the computational cost of computing a dictionary. In March 2008, NSEC3 was formally defined in RFC 5155.

VeriSign was running an NSEC3 DNSSEC Pilot to provide others with operational experience with NSEC3 at the top-level-domain level and an independent implementation of the authoritative server component. This pilot provided a DNSSEC signed version of .com and .net using the NSEC3 record. The pilot is now defunct.

The Internet is considered a critical infrastructure by many, yet it was originally based on the fundamentally insecure DNS. Thus, there is strong incentive to secure DNS, and deploying DNSSEC is generally considered to be a critical part of that effort. For example, the U.S. National Strategy to Secure Cyberspace specifically identified the need to secure DNS. Widescale deployment of DNSSEC could resolve many other security problems as well, such as secure key distribution for e-mail addresses.

However, the DNSSEC specification has been challenging to develop. NSEC3, one of its critical pieces, was only formally defined in an RFC in March 2008, and it is not yet widely deployed.

In addition, DNSSEC deployment in large-scale networks is also challenging. DNSSEC can be deployed at any level of a DNS hierarchy, but it must be widely available in a zone before many others will adopt it. DNS servers must be updated with software that supports DNSSEC, and DNSSEC data must be created and added to the DNS zone data. A TCP/IP-using client must have their DNS resolver (client) updated before it can use DNSSEC's capabilities. What is more, any resolver must have, or have a way to acquire, at least one public key that it can trust before it can start using DNSSEC. Ozment and Schechter observe that DNSSEC (and other technologies) has a "bootstrap problem": users typically only deploy a technology if they receive an immediate benefit, but if a minimal level of deployment is required before any users receive a benefit greater than their costs, it risks remaining undeployed.

To address these challenges, significant effort is ongoing to deploy DNSSEC, because the Internet is so vital to so many organizations.

Early adopters include Brazil (.br), Bulgaria (.bg), Czech Republic (.cz), Puerto Rico (.pr) and Sweden (.se) who use DNSSEC for their country code top-level domains,, RIPE NCC,who have signed all the reverse (in-addr.arpa) that are delegated to it from IANA , and VeriSign. TDC was the first ISP to implement this feature in Sweden.

VeriSign was running a pilot project to allow .com and .net domains to register themselves to do DNSSEC NSEC3 experiments, as noted above.

A wide variety of pilot projects and experiments are and have been performed. dnssec.net maintains a list of such projects. There is also a Google Map of World Wide DNSSEC Deployment.

On February 24, 2009, VeriSign announced that they would deploy DNSSEC across all their top level domains (.com, .net, etc.) within 24 months.

Many are interested in deploying DNSSEC at the root level. If deployed widely at the root level, DNSSEC could support distribution of public keys associated with any arbitrary domain name, countering many spam and spoof attacks. Having a few DNS root-level DNSSEC public keys would greatly simplify the deployment of DNSSEC resolvers, since those few keys could be the basis for any other key. However, root level deployment may be delayed for a variety of reasons.

ICANN has described its DNS root zone signing as simply to "determine timetable, coordination requirements and costs for full deployment" instead of actual deployment, suggesting that it may be a long time before DNSSEC is deployed at the root (global) level of DNS.

The Public Interest Registry announced in July, 2008 that it will begin using DNSSEC in a then-unspecified deployment timetable. It further detailed on September 26, 2008, that the first phase, involving large registrars it has a strong working relationship with ("friends and family") will be the first to be able to sign their domains, beginning "early 2009". In September, ICANN and VeriSign each published implementation proposals and in October, the National Telecommunications and Information Administration, a part of the U.S. Department of Commerce, asked the public for comments.

Due to delays with signing the root, there have been several proposed and deployed alternative trust anchors.

The Science and Technology Directorate of the U.S. Department of Homeland Security (DHS) sponsors the "DNSSEC Deployment Initiative". This initiative encourages "all sectors to voluntarily adopt security measures that will improve security of the Internet's naming infrastructure, as part of a global, cooperative effort that involves many nations and organizations in the public and private sectors." DHS also funds efforts to mature DNSSEC and get it deployed inside the U.S. federal government.

The National Institute of Standards and Technology (NIST) published NIST Special Publication 800-81 Secure Domain Name System (DNS) Deployment Guide on May 16, 2006, with guidance on how to deploy DNSSEC. NIST intended to release new DNSSEC Federal Information Security Management Act (FISMA) requirements in NIST SP800-53-R1, referencing this deployment guide. U.S. agencies would then have had one year after final publication of NIST SP800-53-R1 to meet these new FISMA requirements. However, at the time NSEC3 had not been completed. NIST had suggested using split domains, a technique that is known to be possible but is difficult to deploy correctly, and has the security weaknesses noted above.

To the top

Domain Name System

The Domain Name System (DNS) is a hierarchical naming system for computers, services, or any resource participating in the Internet. It associates various information with domain names assigned to such participants. Most importantly, it translates domain names meaningful to humans into the numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices world-wide. An often used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example, www.example.com translates to 208.77.188.166.

The Domain Name System makes it possible to assign domain names to groups of Internet users in a meaningful way, independent of each user's physical location. Because of this, World-Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. Internet domain names are easier to remember than IP addresses such as 208.77.188.166 (IPv4) or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). People take advantage of this when they recite meaningful URLs and e-mail addresses without having to know how the machine will actually locate them.

The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers for their sub-domains. This mechanism has made the DNS distributed, fault tolerant, and helped avoid the need for a single central register to be continually consulted and updated.

In general, the Domain Name System also stores other types of information, such as the list of mail servers that accept email for a given Internet domain. By providing a world-wide, distributed keyword-based redirection service, the Domain Name System is an essential component of the functionality of the Internet.

Other identifiers such as RFID tags, UPC codes, International characters in email addresses and host names, and a variety of other identifiers could all potentially utilize DNS .

The Domain Name System also defines the technical underpinnings of the functionality of this database service. For this purpose it defines the DNS protocol, a detailed specification of the data structures and communication exchanges used in DNS, as part of the Internet Protocol Suite (TCP/IP). The DNS protocol was developed and defined in the early 1980s and published by the Internet Engineering Task Force (cf. History).

The practice of using a name as a more human-legible abstraction of a machine's numerical address on the network predates even TCP/IP. This practice dates back to the ARPAnet era. Back then, a different system was used. The DNS was invented in 1983, shortly after TCP/IP was deployed. With the older system, each computer on the network retrieved a file called HOSTS.TXT from a computer at SRI (now SRI International). The HOSTS.TXT file mapped numerical addresses to names. A hosts file still exists on most modern operating systems, either by default or through configuration, and allows users to specify an IP address (eg. 208.77.188.166) to use for a hostname (eg. www.example.net) without checking DNS. Systems based on a hosts file have inherent limitations, because of the obvious requirement that every time a given computer's address changed, every computer that seeks to communicate with it would need an update to its hosts file.

The growth of networking required a more scalable system that recorded a change in a host's address in one place only. Other hosts would learn about the change dynamically through a notification system, thus completing a globally accessible network of all hosts' names and their associated IP Addresses.

At the request of Jon Postel, Paul Mockapetris invented the Domain Name System in 1983 and wrote the first implementation. The original specifications appear in RFC 882 and RFC 883. In November 1987, the publication of RFC 1034 and RFC 1035 updated the DNS specification and made RFC 882 and RFC 883 obsolete. Several more-recent RFCs have proposed various extensions to the core DNS protocols.

In 1984, four Berkeley students—Douglas Terry, Mark Painter, David Riggle and Songnian Zhou—wrote the first UNIX implementation, which was maintained by Ralph Campbell thereafter. In 1985, Kevin Dunlap of DEC significantly re-wrote the DNS implementation and renamed it BIND—Berkeley Internet Name Domain. Mike Karels, Phil Almquist and Paul Vixie have maintained BIND since then. BIND was ported to the Windows NT platform in the early 1990s.

BIND was widely distributed, especially on Unix systems, and is the dominant DNS software in use on the Internet. With the heavy use and resulting scrutiny of its open-source code, as well as increasingly more sophisticated attack methods, many security flaws were discovered in BIND. This contributed to the development of a number of alternative nameserver and resolver programs. BIND itself was re-written from scratch in version 9, which has a security record comparable to other modern Internet software.

Administrative responsibility over any zone may be divided, thereby creating additional zones. Authority is said to be delegated for a portion of the old space, usually in form of sub-domains, to another nameserver and administrative entity. The old zone ceases to be authoritative for the new zone.

A domain name usually consists of two or more parts (technically labels), which are conventionally written separated by dots, such as example.com.

The Domain Name System is maintained by a distributed database system, which uses the client-server model. The nodes of this database are the name servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the root nameservers: the servers to query when looking up (resolving) a top-level domain name (TLD).

The client-side of the DNS is called a DNS resolver. It is responsible for initiating and sequencing the queries that ultimately lead to a full resolution (translation) of the resource sought, e.g., translation of a domain name into an IP address.

The resolver (or another DNS server acting recursively on behalf of the resolver) negotiates use of recursive service using bits in the query headers.

Resolving usually entails iterating through several name servers to find the needed information. However, some resolvers function simplistically and can communicate only with a single name server. These simple resolvers rely on a recursive query to a recursive name server to perform the work of finding information for them.

In theory a full host name may have several name segments, (e.g ahost.ofasubnet.ofabiggernet.inadomain.example). In practice, full host names will frequently consist of just three segments (ahost.inadomain.example, and most often www.inadomain.example). For querying purposes, software interprets the name segment by segment, from right to left. At each step along the way, the program queries a corresponding DNS server to provide a pointer to the next server which it should consult.

The diagram illustrates this process for the real host www.wikipedia.org.

The mechanism in this simple form has a difficulty: it places a huge operating burden on the root servers, with every search for an address starting by querying one of them. Being as critical as they are to the overall function of the system, such heavy use would create an insurmountable bottleneck for trillions of queries placed every day. In practice caching is used to overcome this problem, and in actual fact root nameservers deal with very little of the total traffic.

Name servers in delegations appear listed by name, rather than by IP address. This means that a resolving name server must issue another DNS request to find out the IP address of the server to which it has been referred. Since this can introduce a circular dependency if the nameserver referred to is under the domain that it is authoritative of, it is occasionally necessary for the nameserver providing the delegation to also provide the IP address of the next nameserver. This record is called a glue record.

For example, assume that the sub-domain en.wikipedia.org contains further sub-domains (such as something.en.wikipedia.org) and that the authoritative name server for these lives at ns1.something.en.wikipedia.org. A computer trying to resolve something.en.wikipedia.org will thus first have to resolve ns1.something.en.wikipedia.org. Since ns1 is also under the something.en.wikipedia.org subdomain, resolving ns1.something.en.wikipedia.org requires resolving something.en.wikipedia.org which is exactly the circular dependency mentioned above. The dependency is broken by the glue record in the nameserver of en.wikipedia.org that provides the IP address of ns1.something.en.wikipedia.org directly to the requestor, enabling it to bootstrap the process by figuring out where ns1.something.en.wikipedia.org is located.

DNS also supports wildcard DNS records that will match requests for non-existent domain names. A wildcard DNS record is specified by using a "*" as the left most label (part) of a domain name, e.g. *.example.com. The exact rules for when a wild card will match are specified in RFC 1034, but the rules are neither intuitive nor clearly specified. This has resulted in incompatible implementations and unexpected results when they are used.

Because of the huge volume of requests generated by a system like DNS, the designers wished to provide a mechanism to reduce the load on individual DNS servers. To this end, the DNS resolution process allows for caching (i.e. the local recording and subsequent consultation of the results of a DNS query) for a given period of time after a successful answer. How long a resolver caches a DNS response (i.e. how long a DNS response remains valid) is determined by a value called the time to live (TTL). The TTL is set by the administrator of the DNS server handing out the response. The period of validity may vary from just seconds to days or even weeks.

As a noteworthy consequence of this distributed and caching architecture, changes to DNS do not always take effect immediately and globally. This is best explained with an example: If an administrator has set a TTL of 6 hours for the host www.wikipedia.org, and then changes the IP address to which www.wikipedia.org resolves at 12:01pm, the administrator must consider that a person who cached a response with the old IP address at 12:00noon will not consult the DNS server again until 6:00pm. The period between 12:01pm and 6:00pm in this example is called caching time, which is best defined as a period of time that begins when you make a change to a DNS record and ends after the maximum amount of time specified by the TTL expires. This essentially leads to an important logistical consideration when making changes to DNS: not everyone is necessarily seeing the same thing you're seeing. RFC 1912 helps to convey basic rules for how to set the TTL.

Note that the term "propagation", although very widely used in this context, does not describe the effects of caching well. Specifically, it implies that when you make a DNS change, it somehow spreads to all other DNS servers (instead, other DNS servers check in with yours as needed), and that you do not have control over the amount of time the record is cached (you control the TTL values for all DNS records in your domain, except your NS records and any authoritative DNS servers that use your domain name).

Many people incorrectly refer to a mysterious 48 hour or 72 hour propagation time when you make a DNS change. When one changes the NS records for one's domain or the IP addresses for hostnames of authoritative DNS servers using one's domain (if any), there can be a lengthy period of time before all DNS servers use the new information. This is because those records are handled by the zone parent DNS servers (for example, the .com DNS servers if your domain is example.com), which typically cache those records for 48 hours. However, those DNS changes will be immediately available for any DNS servers that do not have them cached. And any DNS changes on your domain other than the NS records and authoritative DNS server names can be nearly instantaneous, if you choose for them to be (by lowering the TTL once or twice ahead of time, and waiting until the old TTL expires before making the change).

Users generally do not communicate directly with a DNS resolver. Instead DNS-resolution takes place transparently in client-applications such as web-browsers, mail-clients, and other Internet applications. When an application makes a request which requires a DNS lookup, such programs send a resolution request to the local DNS resolver in the local operating system, which in turn handles the communications required.

The DNS resolver will almost invariably have a cache (see above) containing recent lookups. If the cache can provide the answer to the request, the resolver will return the value in the cache to the program that made the request. If the cache does not contain the answer, the resolver will send the request to one or more designated DNS servers. In the case of most home users, the Internet service provider to which the machine connects will usually supply this DNS server: such a user will either have configured that server's address manually or allowed DHCP to set it; however, where systems administrators have configured systems to use their own DNS servers, their DNS resolvers point to separately maintained nameservers of the organization. In any event, the name server thus queried will follow the process outlined above, until it either successfully finds a result or does not. It then returns its results to the DNS resolver; assuming it has found a result, the resolver duly caches that result for future use, and hands the result back to the software which initiated the request.

An additional level of complexity emerges when resolvers violate the rules of the DNS protocol. A number of large ISPs have configured their DNS servers to violate rules (presumably to allow them to run on less-expensive hardware than a fully-compliant resolver), such as by disobeying TTLs, or by indicating that a domain name does not exist just because one of its name servers does not respond.

As a final level of complexity, some applications (such as web-browsers) also have their own DNS cache, in order to reduce the use of the DNS resolver library itself. This practice can add extra difficulty when debugging DNS issues, as it obscures the freshness of data, and/or what data comes from which cache. These caches typically use very short caching times — on the order of one minute. Internet Explorer offers a notable exception: recent versions cache DNS records for half an hour.

DNS primarily uses UDP on port 53 to serve requests. Almost all DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. TCP comes into play only when the response data size exceeds 512 bytes, or for such tasks as zone transfer. Some operating systems such as HP-UX are known to have resolver implementations that use TCP for all queries, even when UDP would suffice.

EDNS is an extension of the DNS protocol which allows the transport over UDP of DNS replies exceeding 512 bytes, and adds support for expanding the space of request and response codes. It is described in RFC 2671.

A Resource Record (RR) is the basic data element in the domain name system. Each record has a type (A, MX, etc.), a TTL, a class and some type-specific information. All resource records of the same type define a Resource Record Set (RR set). The order that resource records in a RR set are returned by the resolver to an application is undefined (the server typically uses round-robin DNS). DNSSEC, however, works on complete RR sets in a canonical order.

When sent over the Internet, all records use the common format specified in RFC 1035 shown below.

The NAME is the fully qualified domain name of the node in the tree. On the wire, the name may be shortened using label compression where ends of domain names mentioned earlier in the packet can be substituted for the end of the current domain name.

The TYPE of the record indicates what the format of the data is, and gives a hint of its intended use; for instance, the A record is used to translate from a domain name to an IPv4 address, the NS record lists which name servers can answer lookups on a DNS zone, and the MX record is used to translate from a name in the right-hand side of an e-mail address to the name of a machine able to handle mail for that address.

The RDATA is type-specific information, such as the actual IP address for A records, or the mail host for MX records. Well known record types may use label compression in the RDATA field, but "unknown" record types can not (see RFC 3597).

The CLASS of a record is almost always set to "IN" or "Internet". There are also the very rarely used "CH" (Chaos) and "HS" (Hesiod) classes. In theory, each class can be completely independent trees with different delegation DNS zones and different names, but in practice they all mirrored the Internet class.

In addition to resource records defined in a zone file, there are also some pseudo record types that are used only on the wire, such as to perform zone transfers (AXFR/IXFR) or for EDNS (OPT).

While domain names technically have no restrictions on the characters they use and can include non-ASCII characters, the same is not true for host names. Host names are the names most people see and use for things like e-mail and web browsing. Host names are restricted to a small subset of the ASCII character set known as LDH, the Letters A–Z in upper and lower case, Digits 0–9, Hyphen, and the dot to separate LDH-labels; see RFC 3696 section 2 for details. This prevented the representation of names and words of many languages natively. ICANN has approved the Punycode-based IDNA system, which maps Unicode strings into the valid DNS character set, as a workaround to this issue. Some registries have adopted IDNA.

DNS was not originally designed with security in mind, and thus has a number of security issues.

One class of vulnerabilities is DNS cache poisoning, which tricks a DNS server into believing it has received authentic information when, in reality, it has not.

DNS responses are traditionally not cryptographically signed, leading to many attack possibilities; The Domain Name System Security Extensions (DNSSEC) modifies DNS to add support for cryptographically signed responses. There are various extensions to support securing zone transfer information as well.

Even with encryption, a DNS server could become compromised by a virus (or for that matter a disgruntled employee) that would cause IP addresses of that server to be redirected to a malicious address with a long TTL. This could have far-reaching impact to potentially millions of Internet users if busy DNS servers cache the bad IP data. This would require manual purging of all affected DNS caches as required by the long TTL (up to 68 years).

Some domain names can spoof other, similar-looking domain names. For example, "paypal.com" and "paypa1.com" are different names, yet users may be unable to tell the difference when the user's typeface (font) does not clearly differentiate the letter l and the numeral 1. This problem is much more serious in systems that support internationalized domain names, since many characters that are different, from the point of view of ISO 10646, appear identical on typical computer screens. This vulnerability is often exploited in phishing.

Techniques such as Forward Confirmed reverse DNS can also be used to help validate DNS results.

The right to use a domain name is delegated by domain name registrars which are accredited by the Internet Corporation for Assigned Names and Numbers (ICANN), the organization charged with overseeing the name and number systems of the Internet. In addition to ICANN, each top-level domain (TLD) is maintained and serviced technically by a sponsoring organization, the TLD Registry. The registry is responsible for maintaining the database of names registered within the TLDs they administer. The registry receives registration information from each domain name registrar authorized to assign names in the corresponding TLD and publishes the information using a special service, the whois protocol.

Registrars usually charge an annual fee for the service of delegating a domain name to a user and providing a default set of name servers. Often this transaction is termed a sale or lease of the domain name, and the registrant is called an "owner", but no such legal relationship is actually associated with the transaction, only the exclusive right to use the domain name. More correctly authorized users are known as "registrants" or as "domain holders".

ICANN publishes a complete list of TLD registries and domain name registrars in the world. One can obtain information about the registrant of a domain name by looking in the WHOIS database held by many domain registries.

For most of the more than 240 country code top-level domains (ccTLDs), the domain registries hold the authoritative WHOIS (Registrant, name servers, expiration dates, etc.). For instance, DENIC, Germany NIC, holds the authoritative WHOIS to a .DE domain name. Since about 2001, most gTLD registries (.ORG, .BIZ, .INFO) have adopted this so-called "thick" registry approach, i.e. keeping the authoritative WHOIS in the central registries instead of the registrars.

For .COM and .NET domain names, a "thin" registry is used: the domain registry (e.g. VeriSign) holds a basic WHOIS (registrar and name servers, etc.). One can find the detailed WHOIS (registrant, name servers, expiry dates, etc.) at the registrars.

Some domain name registries, also called Network Information Centres (NIC), also function as registrars, and deal directly with end users. But most of the main ones, such as for .COM, .NET, .ORG, .INFO, etc., use a registry-registrar model. There are hundreds of Domain Name Registrars that actually perform the domain name registration with the end user (see lists at ICANN or VeriSign). By using this method of distribution, the registry only has to manage the relationship with the registrar, and the registrar maintains the relationship with the end users, or 'registrants' -- in some cases through additional layers of resellers.

Critics often claim abuse of administrative power over domain names. Particularly noteworthy was the VeriSign Site Finder system which redirected all unregistered .com and .net domains to a VeriSign webpage. For example, at a public meeting with VeriSign to air technical concerns about SiteFinder , numerous people, active in the IETF and other technical bodies, explained how they were surprised by VeriSign's changing the fundamental behavior of a major component of Internet infrastructure, not having obtained the customary consensus. SiteFinder, at first, assumed every Internet query was for a website, and it monetized queries for incorrect domain names, taking the user to VeriSign's search site. Unfortunately, other applications, such as many implementations of email, treat a lack of response to a domain name query as an indication that the domain does not exist, and that the message can be treated as undeliverable. The original VeriSign implementation broke this assumption for mail, because it would always resolve an erroneous domain name to that of SiteFinder. While VeriSign later changed SiteFinder's behaviour with regard to email, there was still widespread protest about VeriSign's action being more in its financial interest than in the interest of the Internet infrastructure component for which VeriSign was the steward.

Despite widespread criticism, VeriSign only reluctantly removed it after the Internet Corporation for Assigned Names and Numbers (ICANN) threatened to revoke its contract to administer the root name servers. ICANN published the extensive set of letters exchanged, committee reports, and ICANN decisions .

There is also significant disquiet regarding the United States' political influence over ICANN. This was a significant issue in the attempt to create a .xxx top-level domain and sparked greater interest in alternative DNS roots that would be beyond the control of any single country.

Additionally, there are numerous accusations of domain name "front running", whereby registrars, when given whois queries, automatically register the domain name for themselves. Recently, Network Solutions has been accused of this.

In the United States, the "Truth in Domain Names Act" (actually the "Anticybersquatting Consumer Protection Act"), in combination with the PROTECT Act, forbids the use of a misleading domain name with the intention of attracting people into viewing a visual depiction of sexually explicit conduct on the Internet.

The Domain name system is defined by Request for Comments published by the Internet Engineering Task Force (Internet standards). The following is a list of some of the RFCs that pertain to the core DNS protocol.

To the top

List of organizations with .INT domain names

These organizations are generally either international intergovernmental organizations established by treaty, or else internet infrastructure databases. Some however (such as the YMCA) do not meet the current requirements to have a .INT registration, but were grandfathered in.

To the top

Fictitious domain name

A fictitious domain name is a domain name used in a work of fiction or popular culture to refer to an Internet address that does not actually exist. This is similar in concept to 555 telephone numbers. RFC 2606 specifies particular reserved domains. Essentially, all versions of "example," among several others, are to be reserved, such as .example, example.com, example.org, example.edu, example.us, etc. for the purpose of providing a fictional domain name that is not actually used by anyone.

However, domain names that become popular in works of fiction have a tendency to become registered in real life (if possible). So it is difficult for any particular domain to be both popularly known and fictional. (Even example.com, mentioned above, is actually registered to the IANA, although not used for anything.) This phenomenon prompted NBC to purchase the domain name Hornymanatee.com after talk-show host Conan O'Brien spoke the name while ad-libbing on his show. O'Brien subsequently created a real website based around the concept and used it as a running gag on the show.

When IP addresses are called for in a script, some TV shows, like 24, use numbers that are over 255 (which are invalid addresses). The movie Swordfish uses an IP of 293.xx.xxx.xx in one scene, and the comic strip Narbonic referenced the fictitious IP 132.513.151.319. In Antitrust, several addresses in the 10.x.x.x range are shown; this is an RFC 1918 private network area. The CSI series uses addresses in the 5.xxx.xxx.xxx range, which, as of 2008, is currently unallocated by IANA, but is nonetheless used by the Hamachi VPN service. The IP address range 192.0.2.x is called "TEST-NET" and designated by RFC 3330 as being "for use in documentation and example code".

To the top

Cybersquatting

Cybersquatting (also known as domain squatting), according to the United States federal law known as the Anticybersquatting Consumer Protection Act, is registering, trafficking in, or using a domain name with bad faith intent to profit from the goodwill of a trademark belonging to someone else. The cybersquatter then offers to sell the domain to the person or company who owns a trademark contained within the name at an inflated price.

The term is derived from "squatting," which is the act of occupying an abandoned or unoccupied space or building that the squatter does not own, rent or otherwise have permission to use. Cybersquatting however, is a bit different in that the domain names that are being "squatted" are (sometimes but not always) being paid for through the registration process by the Cybersquatters. Cybersquatters usually ask for prices far greater than that at which they purchased it. Some cybersquatters put up derogatory remarks about the person or company the domain is meant to represent in an effort to encourage the subject to buy the domain from them. Others post paid links via Google, Yahoo, Ask.com and other paid advertising networks to the actual site that the user likely wanted, thus monetizing their squatting. As with many controversial issues, some argue that the dividing line of cybersquatting is difficult to draw, or that the practice is consistent with a capitalistic and free market ethos.

Cybersquatting is one of the most loosely used terms related to domain name intellectual property law and is often incorrectly used to refer to the sale or purchase of generic domain names such as example.com.

Cybersquatters sometimes register variants of popular trademarked names, a practice known as typosquatting.

Another strategy is as follows: Internet domain name registrations are for a fixed period of time. If the owner of a domain name doesn't re-register the name with an internet registrar prior to the domain's expiration date, then the domain name can be purchased by anybody else after it expires. At this point the registration is considered lapsed. A cybersquatter may use automated software tools to register the lapsed name the instant it is lapsed. This strategy is one of a family of identity theft schemes including renewal snatching, extension exaggeration and alert angling.

Yet another approach is "name jacking" (also "name-jacking" or "namejacking") which is accomplished by purchasing an individual's name as a second-level domain name. Setting up a website allows the purchaser to capitalize on any searches done for that name. For example, if John Jones has a thriving professional practice (perhaps he is a doctor, a lawyer, a financial professional, or real estate agent - or any other profession which interacts with the public on a regular basis), there is a high likelihood that potential clients will do some research on the internet before doing business with Mr. Jones. If Mr. Jones has been "name jacked ," then someone else owns johnjones.com and that website will appear at or near the top of any searches for the name "John Jones." These "name jacked" sites are typically set up to sell high-profit items like ebooks and/or various business opportunities and require few purchases to be profitable. As the name-jacked domains are set up using non-trademarked names and they have a purpose other than selling the domain name back to an individual, they circumvent the "Anti-cybersquatting Consumer Protection Act" (ACPA) laws U.S.C. § 1125 and U.S.C. § 1129. Since people frequently "google" to find out information, name jacking provides low-cost web traffic to the name-jacked website.

Domain name disputes involving alleged bad-faith registration are typically resolved using the Uniform Domain Name Resolution Policy (UDRP) process developed by the Internet Corporation for Assigned Names and Numbers (ICANN). Critics claim that the UDRP process favors large corporations and that their decisions often go beyond the rules and intent of the dispute resolution policy. A UDRP complaint may be initiated at UDRP proceeding with an approved dispute resolution service provider. A victim of cybersquatting may also file an InterNIC Registrar Problem Report regarding a cybersquatter posing as a registrar.

Court systems can also be used to sort out claims of cybersquatting, but jurisdiction is often a problem, as different courts have ruled that the proper location for a trial is that of the plaintiff, the defendant, or the location of the server through which the name is registered. Countries such as China and Russia do not view cybersquatting in the same way or degree that US law does. People often choose the UDRP (Uniform Dispute Resolution Process) created by ICANN because it is usually quicker and cheaper ($2,000 to $3,000 in costs and fees vs. $10,000 or more) than going to court, but courts can and often do overrule UDRP decisions. In Virtual Works, Inc. v. Volkswagen of America, Inc. (a dispute over the domain vw.net), the Fourth Circuit Court of Appeals created a common law requirement that the cybersquatter exhibit a bad faith intent in order to confer liability. This means that domain names bearing close resemblance to trademarked names are not per se impermissible. Rather, the domain name must have been registered with the bad faith intent to later sell it to the trademark holder. This "bad faith" concept is reiterated in 15 U.S.C. § 1125 and U.S.C. § 1129.

Some countries have specific laws against cybersquatting beyond the normal rules of trademark law. The United States, for example, has the U.S. Anticybersquatting Consumer Protection Act (ACPA) of 1999. While this expansion of the Lanham (Trademark) Act (15 U.S.C.) purports to provide protection against cybersquatting for individuals as well as owners of distinctive Trademarked names, the failure of notable personalities, including rock star Bruce Springsteen and actor Kevin Spacey, to obtain control of their names on the internet indicates the lack of protection afforded to the average businessman or individual.

Jurisdiction is an issue, as shown in the case involving actor Kevin Spacey, in which Judge Gary A. Feess, of the United States District Court of the Central District of California, ruled that Spacey would have to file a complaint in a Canadian court, where the current owner of kevinspacey.com resided. Spacey later won the domain through the National Arbitration Forum.

Under UDRP policy, successful complainants can have the names deleted or transferred to their ownership (which means paying regular renewal fees on all the names or risk their being registered by someone else). Under the ACPA (Anticybersquatting Consumer Protection Act) a cybersquatter can be held liable for actual damages or statutory damages in the amount of a maximum of $100,000 for each name found to be in violation, although application of this act in the form of actual fines assessed are few in number. In one of the first applications of the ACPA, the Plaintiff, Brian Salle, sought relief under 15 U.S.C. § 1125 and U.S.C. § 1129 from Defendant Garner W. Meadows. The court rejected Plaintiff's argument that "all personal names" are protected under the act and established that personal names must be "protected as a mark" for 15 U.S.C. § 1125(d) to apply. The court did award summary judgement under 15 U.S.C. § 1129(1)(A), with the award being the transfer of the domain briansalle.com to his control and judgment for attorney's fees against Garner W. Meadows of approximately $30,000.00. Monetary awards under the ACPA are infrequent at best, and the cost of filing a case is prohibitive for the average individual.

There have been several instances of companies, individuals or governments trying to take generic domain names away from their owners by making false claims of trademark violation. Sometimes they are successful. This practice is called "reverse domain hijacking". For example, little known Heathrow Land Development in Florida attempted to use their narrow one-class trademark and the UDRP process to acquire heathrow.com.

Australia is another example - auDA requires anyone registering a .com.au Second-level domain to have a valid entitlement for that domain - ie. a registered business name with an Australian Business Number (ABN) issued by the Australian Taxation Office. However, this has failed to protect Australia from such cybersquatting acts. Any Australian citizen over the age of 16 can obtain an ABN (which is free) and use it to register as few or as many domain names as they like.

Internationally, the United Nations copyright agency called WIPO (World Intellectual Property Organization) has, since 1999, provided an arbitration system wherein a trademark holder can attempt to claim a squatted site. In 2006, there were 1823 complaints filed with WIPO, which was a 25% increase over 2005's rate. On average, 84% of claims are decided in the complaining party's favor.

To the top