:: wikimiki.org ::

Canonical Name

Canonical name

A fully qualified domain name (or FQDN) is an unambiguous domain name that specifies the node's position in the DNS tree hierarchy absolutely. To distinguish an FQDN from a regular domain name, a trailing period is added. ex: somehost.example.com. An FQDN differs from a regular domain name by its absoluteness; a suffix will not be added. For example, given a device with a hostname of "myhost" and a domain name of "example.com", the fully qualified domain name is "myhost.example.com.". It therefore uniquely defines the device — whilst there might be many hosts in the world called "myhost", there can only be one "myhost.example.com.". Notice that there is a dot at the very end of the domain name, i.e. it ends ".com." and not ".com" — this indicates that the name is an FQDN. For example "myhost.bar.com" could be ambiguous, because it could be the prefix of a longer domain name such as "myhost.bar.com.gov", whereas "myhost.bar.com." is a fully qualified domain name. Technically, the dot comes before the empty label indicating the root of the Domain Name System hierarchy, and so an FQDN is sometimes called a rooted domain name. In practice, the dot is almost always left out in web pages and other documents making the domain name ambiguous, at least in theory. The maximum permitted length of an FQDN is 255 bytes, with an additional restriction to 63 bytes for each label within the domain name. The syntax of domain names is discussed in various RFCs — RFC 1035, RFC 1123 and RFC 2181. Labels in FQDNs are restricted to a limited character set, consisting of the ASCII letters A to Z, digits, and the "-" character, and are not case-sensitive. In 2004 umlauts (like ä, ö, ü, é, à, è, ...) were added as allowed characters for labels. Internationalized domain names expand the character repertoire of domain names to include non-ASCII characters, by encoding Unicode characters into byte strings within the normal FQDN character set. As a result, the character length limits of internationalized domain names are content-dependent. A FQDN is not the same as a Universal Resource Locator (URL) as it lacks the TCP/IP protocol name to be used in communication with the host. A URL always starts with "://", and so includes the communication protocol (like "http://", or "ftp://"), and can include a directory path, a filename and a TCP port number. Sometimes FQDNs are specified instead of the full URLs on websites etc., in which case the protocol is assumed to be HTTP on TCP port 80; and web browsers use this as the default if it is not otherwise specified.

External links

- RFC 1035: Domain names: implementation and specification
- RFC 1123: Requirements for Internet Hosts - application and support
- RFC 2181: Clarifications to the DNS specification Category:Domain Name System

Domain name

The term domain name has multiple meanings, all related to the Domain Name System (main article).
- a name that is entered into a computer (e.g. as part of a website or other URL, or an email address) and then looked up in the global [Domain Name System] which informs the computer of the IP address(es) with that name.
- the product that registrars provide to their customers.
- a name looked up in the DNS for other purposes. They are sometimes colloquially (and incorrectly) referred to by marketers as "web addresses". Domain names are Hostnames that provide rememberable names to stand in for numeric IP addresses. They allow for any service to move to a different location in the topology of the Internet (or another internet), which would then have a different IP address. Each string of letters, digits and hyphens between the dots is called a label in the parlance of the domain name system (DNS). Valid labels are subject to certain rules, which have relaxed over the course of time. Originally labels must start with a letter, and end with a letter or digit; any intervening characters may be letters, digits, or hyphens. Labels must be between 1 and 63 characters long (inclusive). Letters are ASCII A–Z and a–z; domain names are compared case-insensitively. Later it became permissible for labels to commence with a digit (but not for domain names to be entirely numeric), and for labels to contain internal underscores, but support for such domain names is uneven. These are the rules imposed by the way names are looked up ("resolved") by DNS. Some top level domains (see below) impose more rules, such as a longer minimum length, on some labels. Fully qualified names (FQDNs) are sometimes written with a final dot. Translating numeric addresses to alphabetical ones, domain names allow Internet users to localize and visit websites. Additionally since more than one IP address can be assigned to a domain name, and more than one domain name assigned to an IP address, one server can have multiple roles, and one role can be spread among multiple servers. One IP address can even be assigned to several servers, such as with anycast and hijacked IP space.

Examples

The following examples illustrates the difference between a URL (Uniform Resource Locator) and a domain name: : URL: http://www.example.com/ : Domain name: www.example.com 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 websites 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 is goes under the name virtual hosting and is commonly used by web hosts. For example, the server at 192.0.34.166 handles all of the following sites: : www.example.com : www.example.net : www.example.org

Top-level domains

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 characters territory code based on ISO-3166 (there are few exceptions and new codes are integrated case by case). Examples of (gTLD) extensions are:
- .com
- .net
- .org
- .biz
- .info
- .name
- .museum
- .travel
- .pro
- .aero
- .xxx (disapproved by ICANN) Examples of country code top-level domain (ccTLD) extensions are:
- .au
- .eu (not an ISO-3166 code, and not a country, but used anyway for the European Union. Scheduled to be launched December 7, 2005)
- .us
- .uk (not an ISO-3166 code, but used anyway)
- .br
- .fr
- .es
- .de
- .in
- .it
- .jp
- .ca
- .nz
- .su (not an existing country at the moment - Soviet Union, but used anyway)

Official assignment

ICANN (Internet Corporation for Assigned Names and Numbers) has overall responsibility for managing the DNS. It controls the root domain, delegating control over each top-level domain to a domain name registry. For ccTLDs, the domain registry is typically controlled by the government of that country. ICANN has a consultation role in these domain registries but is in no position to regulate the terms and conditions of how a domain name is allocated or who allocates it in each of these country level domain registries. On the other hand, generic top-level domains (gTLDs) are governed directly under ICANN which means all terms and conditions are defined by ICANN with the cooperation of the gTLD registries. Domain names which are theoretically leased can be considered in the same way as real estate, due to a significant impact on online brand building, advertising, search engine optimization, etc.

Uses and abuses

As domain names became attractive to marketers, rather than just the technical audience for which they were originally intended, they began to be used in manners that in many cases did not fit in their intended structure. As originally planned, the structure of domain names followed a strict hierarchy in which the top level domain 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 which were subdomains of the parent domain. Also, hostnames were intended to correspond to actual physical machines on the network, generally with only one name per machine. However, once the World Wide Web became popular, site operators frequently wished to have memorable addresses, regardless of whether they fit properly in the structure; thus, since the .com domain was the most popular and memorable, even noncommercial sites would often get addresses under it, and sites of all sorts wished to have second-level domain registrations even if they were parts of a larger entity where a logical subdomain would have made sense (e.g., abcnews.com instead of news.abc.com). A website found at http://www.example.org will often be advertised without the "http://", and in most cases can be reached by just typing "example.org" into a web browser. In the case of a .com, the website can sometimes be reached by just typing "example" (depending on browser versions and configuration settings, which vary in how they interpret incomplete addresses). With "virtual hosting", often many domain names would point to the same physical server. The popularity of domain names also led to uses which were regarded as abusive by established companies with trademark rights; this was known as cybersquatting, in which somebody took a name that resembled a trademark in order to profit from traffic to 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 as their being generic words as well as trademarks in a particular context, or their use in the context of fan or protest sites with free speech rights of their own.

Generic domain names — problems arising out of unregulated name selection

Within a particular top-level domain, parties are generally free to select an unallocated domain name as their own on a first come, first served basis. 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 this context, currently a generic domain name such as literary.org is available to the first literary festival organisation which is able to obtain registration, even if the festival in question is very young or obscure. Some critics would 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 non-commercial domain names.

Unconventional domain names

Due to the rarity of one-word dot-com domain names, many unconventional domain names, domain hacks, have been gaining popularity. They make use of the top-level domain as an integral part of the website's title. Two of the most visited domain hack websites are del.icio.us and blo.gs, which spell out 'delicious' and 'blogs', respectively. Some unconventional domain names are also used to create email hacks. 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.

Commercial resale of domain names

An economic effect of the widespread usage of domain names has been the resale market for generic domain names that has sprung up in the last decade. Certain domains, especially those related to business, gambling, pornography, and other commercially lucrative fields have become very much in demand to corporations and entrepreneurs due to their intrinsic value in attracting clients. In fact, the most expensive internet domain name to date, according to Guinness World Records, is business.com which was resold in 1999 for $7.5 million. Another high value 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. Two long-running US lawsuits resulted, one against the thief and one against the domain registrar VeriSign[http://www.wired.com/news/business/0,1367,63142,00.html]. In one of the cases, the judge found in favor of the plaintiff, leading to an unprecendented ruling that classified domain names as property, granting them the same legal protections. In 1999, Microsoft traded the valuable name Bob.com for the name Windows2000.com which was the name of their new operating system.[http://www.theregister.com/1999/11/11/windows2000_com_owner_sells_domain/] 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. Furthermore, generic domain names such as Rent.com or Books.com are extremely easy for potential customers to remember, increasing the probability that they become repeat customers or regular clients. 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 due to the resale of domains. Large numbers of registered domain names lapse and are deleted each year. On average 25,000 domain names drop (are deleted) every day.

Caveat Emptor

Care should always be exercised when registering a domain name: DNS is case-insensitive and the modern trend of words run together with intercapping can be misinterpreted when converted to lowercase. Who Represents, a database of artists and agents, chose http://www.whorepresents.com; Experts Exchange, the programmers' site, famously had http://www.expertsexchange.com; Pen Island unwisely chose http://www.penisland.net; a therapists' network thought http://www.therapistfinder.com looked good and of course the Italian power company PowerGen Italia became http://www.powergenitalia.com. Fortunately the dash is allowable in DNS, a fact possibly unknown to those organisations listed above. DNS is case-insensitive, so CAMFT's website can be advertised as http://www.TherapistFinder.com (instead of http://www.therapistfinder.com).

External links

- [http://www.dnjournal.com/ Domain Name Journal] - Covering the Domain Name Industry with Profiles and News.
- [http://www.domainnamewire.com/ Domain Name Wire] - Latest news about Domain Name Industry, domain sales, and legal issues.
- [http://www.gobin.info/domainname/ Domain Name Universe] - List of all existing Domain Name Registries, global Domain Name Search, Latest news.
- [http://www.faqs.org/rfcs/std/std13.html STD 13/RFC 1034], Domain Names—Concepts and Facilities, an Internet Protocol Standard.
- [http://www.icann.org/ ICANN] - Internet Corporation for Assigned Names and Numbers.
- [http://www.icann.org/udrp/udrp.htm UDRP], Uniform Domain-Name Dispute-Resolution Policy.
- [http://www.internic.net/ Internic.net], public information regarding Internet domain name registration services.
- [http://lifeofawebsite.com/begin/country-specific-domains.php List of Country Specific Domains]
- [http://www.circleid.com/ CircleID], Community discussions on TLDs and Internet infrastructure.
- [http://xona.com/domainhacks/ Domain Hacks] - unconventional domain name search utility
- The authoritative definition is that given in
- RFC 1032 - Domain administrators guide
- RFC 1033 - Domain administrators operations guide
- RFC 1034 - Domain names - concepts and facilities
- RFC 1035 - Domain names - implementation and specification Category:Domain Name System Category:Internet Category:Information technology Category:Identifiers als:Domäne (Internet) ja:ドメイン名

Full stop

A full stop or period, also called a full point, is the punctuation mark commonly placed at the end of several different types of sentences in English and several other languages. A period consists of a small dot placed at the end of a line of text, thus: "." (sans quotes). The term full stop is less common in the United States and Canada, but is generally differentiated from period in contexts where both might be used: a full stop is specifically a delimiting piece of punctuation that represents the end a sentence. When a distinction is made, a period is then any appropriately sized and placed dot in English language text, including use in abbreviations (such as U.K.) and at the ends of sentences, but excluding certain special uses of dots at the bottom of a line of text, such as ellipses. The term full stop is also used, vernacularly, to terminate a phrase or thought with finality and emphasis, as in "I told him I was leaving him, full stop." The term period is used in the same sense in North America but also to some extent in the UK, having fallen less completely out of use in this context than as a general reference to the punctuation mark.

Abbreviations

The period is also used after abbreviations, such as Mrs. & Ms. If the abbreviation is ending a declaratory sentence a second period is not needed (e.g. My name is Phil Simpson Jr.), but in the case of an interogative or exclamatory sentence a question or exclamation mark is needed. In British English, "Dr" and "Mr" do not need a period, as they include both the first and last letter of the abbreviation; but in American English, these are written "Dr." and "Mr." In this use, the period is also occasionally known as the suspension mark.

Decimal point

The same glyph is very often used, rather than a mid-line point, as a decimal point (or dot) in English-speaking countries. For example: :3.14159 For more on this use see Decimal separator.

Spacing after full stop

In typewritten texts and other documents printed in uniform-width fonts, there is a convention among lay writers that two spaces are placed after the full stop (along with the other sentence enders: question mark and exclamation mark), as opposed to the single space used after other punctuation symbols. In modern American English typographical usage, debate has arisen around the proper number of trailing spaces after a full stop to separate sentences within a paragraph. Whereas two spaces are still regarded by many outside the publishing industry to be the better usage for monospace typefaces, the awkwardness that most keyboards and word-processing software have in representing correctly the 1.5 spaces that had previously become standard for typographically proportional (non-monospace) fonts has led to some confusion about how to render the space between sentences using only word-processing tools. Many descriptivists support the notion that a single space after a full stop should be considered standard because it has been the norm in mainstream publishing for many decades. Many prescriptivists, meanwhile, adhere to the earlier use of two spaces on typewriters to make the separation of sentences more salient than separation of elements within sentences. Some, however, accept that in modern word-processing the single space is better because two spaces may stretch inordinately when full justification is applied. Additionally, many computer typefaces are designed proportionately to alleviate the need for the double space. Most modern typesetters, designers, and desktop publishers use only one space after a period as do all mainstream publishers of books and journals. With the advent of standardized HTML for rendering webpages, the broader distinction between full stop spacing and internal spacing in a sentence has become largely moot on the World Wide Web. Standardized HTML treats additional whitespace after the first space as immaterial, and ignores it when rendering the page. A common workaround for this is the use of   to represent extra spaces, and is done automatically by some WYSIWYG editors.

Asian full stop

In some Asian languages, notably Chinese and Japanese, a small circle is used instead of a solid dot: "。". Unlike the Western full stop, this is often used to separate consecutive sentences, rather than to finish every sentence; it is frequently left out where a sentence stands alone, or where text is terminated by a quotation mark instead. In these languages, the partition sign "·" (間隔號 jiāngéhào) is often used to separate the given name and the family name in other languages: for example, William Shakespeare is represented in Chinese as 威廉‧莎士比亞 (Weilian·Shashibiya), and in Japanese as ウィリアム・シェイクスピア (Uiriamu·Sheikusupia), with a partition sign inserted between the characters of "William" and those of "Shakespeare". The Chinese partition sign is also used to separate book title and chapter title when they are mentioned consecutively (with book title first, then chapter).

Computing use

In computing, the period is often used as a delimiter, also called "dot", for example in DNS lookups and file names. For example: :www.example.com In computer programming, the full stop corresponds to Unicode and ASCII character 46, or 0x2E. See dot for other dots or periods

External links

- [http://www.press.uchicago.edu/Misc/Chicago/cmosfaq/cmosfaq.OneSpaceorTwo.html Chicago Manual of Style] on one space versus two after sentences
- [http://www.fontsite.com/Pages/RulesOfType/ROT0997.html FontSite] typographic design center on one space versus two after sentences Category:Typography Category:Punctuation ja:。

Root directory

In computer file systems, the root directory is the first or top-most directory in a hierarchy. It can be likened to the root of a tree—the starting point where all branches originate. To use the example of a physical file cabinet, if the separate drawers in the file cabinet are represented as the highest level of sub-directories in the file system, then the room the file cabinet is in may be representated as the root directory. That is, the other directories may be inside it, but the root directory cannot go in any other directories, at least in that file system. In many operating systems, including Microsoft Windows and Unix, you may place files inside the root directory; not only in directories. One may envision this as placing paper files in the room but not in a drawer of a file cabinet. Unix abstracts the nature of this tree hierarchy entirely, and in Unix the root directory is denoted /. All filesystem entries, including mounted partitions are "leaves" of this root. However under DOS and Windows, this behavior is different: Each partition has a separate root directory (labeled C:\ for a particular partition C) and there is no common root directory above that. Specific to Unix and similar operating systems, each process has its own idea of what the root directory is. For most processes this is the same as the system's actual root directory, but it can be changed by calling the chroot system call. This is typically done for security purposes to restrict which files a process may access to just a subset of a filesystem. On many Unices, there is also a directory which is named /root. Confusingly, it is not a root directory in the sense of this article, but rather the home directory of the Superuser (root user).

Domain Name System

The Domain Name System (DNS) is a system that stores information associated with domain names in a distributed database on networks, such as the Internet. The domain name system associates many types of information with domain names, but most importantly, it provides the IP address associated with the domain name. It also lists mail exchange servers accepting e-mail for each domain. This means that DNS is involved with each page visit on the internet and with each email message sent. DNS is useful for several reasons. Most well known, the DNS makes it possible to attach hard-to-remember IP addresses (such as 207.142.131.206) to easy-to-remember domain names (such as "wikipedia.org") Humans take advantage of this when they recite URLs and e-mail addresses. Less recognized, the domain name system makes it possible for people to assign authoritative names, without needing to communicate with a central registrar each time.

A brief history of the DNS

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, all the way back to the ARPAnet era. Originally, each computer on the network retrieved a file called HOSTS.TXT from SRI (now SRI International) which mapped an address (eg. 192.0.2.135) to a name (eg. www.example.com.) The Hosts file still exists on most modern operating systems either by default or through configuration and allows users to specify an IP Address to use for a hostname without checking the DNS. This file is now used primarily for troubleshooting DNS errors or mapping local addresses to more organic names. Such a system had inherent limitations, because of the obvious requirement that every time a given computer's address changed, every computer that wanted to communicate with it would need an update to its Hosts file. The growth of networking called for a more scalable system: one which 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. Enter the DNS. Paul Mockapetris invented the DNS in 1983; the original specifications appear in RFC 882 and 883. In 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.

How the DNS works in theory

Actors

1987 The domain name space is a gigantic tree of domain names. Each node or leaf in the tree is associated with resource records, which hold the information associated with the domain name. The tree is divided into zones. A zone is a collection of connected nodes that are authoritatively served by an authoritative DNS nameserver. (Note that a single nameserver can host several zones.) When a system administrator wants to let another administrator control a part of the domain name space within his or her zone of authority, he or she can delegate control to the other administrator. This splits a part of the old zone off into a new zone, which is served by the second administrator's nameservers. The old zone is no longer authoritative for what is under the authority of the new zone. The information associated with nodes is looked up by a resolver. A resolver knows how to communicate with name servers by sending DNS requests, and heeding DNS responses. Resolving usually entails recursing through several name servers to find the needed information. Some resolvers are simple, and can only communicate with a single name server. These simple resolvers rely on a recursing name server to perform the work of finding information for it.

Understanding the parts of a domain name

A domain name usually consists of two or more parts (technically labels), separated by dots. For example wikipedia.org.
- The rightmost label conveys the top-level domain (for example, the address en.wikipedia.org has the top-level domain org).
- Each label to the left specifies a subdivision or subdomain of the domain above it. Note that "subdomain" expresses relative dependence, not absolute dependence: for example, wikipedia.org comprises a subdomain of the org domain, and en.wikipedia.org could form a subdomain of the domain wikipedia.org (in practice, however, en.wikipedia.org actually represents a hostname). In theory, this subdivision can go down to 127 levels deep, and each label can contain up to 63 characters, as long as the whole domain name does not exceed a total length of 255 characters. But in practice some domain registries have shorter limits than that.
- Finally, the leftmost part of the domain name (usually) expresses the hostname. The rest of the domain name simply specifies a way of building a logical path to the information required; the hostname is the actual target system name for which an IP address is desired. For example, the domain name en.wikipedia.org has the hostname "en". The DNS consists of a hierarchical set of DNS 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 "beneath" it. The hierarchy of authoritative DNS servers matches the hierarchy of domains. At the top of the hierarchy stand the root servers: the servers to query when looking up (resolving) a top-level domain name.

An example of theoretical DNS recursion

root servers An example may clarify this process. Suppose an application needs to find the IP address of www.wikipedia.org. It puts this question to a local DNS recursor.
- Before starting, the recursor has to know where to find the root servers; administrators of recursive DNS servers manually specify (and periodically update) a file called the root hints which specify recently known IP addresses of these servers, from which the DNS server can obtain a current complete list.
- The process starts by the recursor asking one of these root servers - for example, the server with the IP address "198.41.0.4" - the question "what is the IP address for www.wikipedia.org?"
- The root server replies with a delegation, meaning roughly: "I don't know the IP address of www.wikipedia.org, but I do know that the DNS server at 204.74.112.1 has information on the org domain."
- The local DNS recursor then asks that DNS server (i.e. 204.74.112.1) the same question it had previously put to the root servers, i.e. "what is the IP address for www.wikipedia.org?". It gets a similar reply - essentially, "I don't know the address of www.wikipedia.org, but I do know that the DNS server at 207.142.131.234 has information on the wikipedia.org domain."
- Finally the request goes to this third DNS server (207.142.131.234), which replies with the required IP address. This process utilises recursive searching.

Understanding domain registration and glue records

Reading the example above, you might reasonably wonder: "how does the DNS server 204.74.112.1 know what IP address to give out for the wikipedia.org domain?" In the first step of the process, we noted that a DNS recursor has the IP addresses of the root servers more-or-less hard coded. Equally, the name servers that are authoritative for the Top-Level Domains change very infrequently. However, the name servers that provide authoritative answers for common domain names may change relatively often. As part of the process of registering a domain name (and at any time thereafter), a registrant provides the registry with the name servers that will be authoritative for that domain name; therefore, when registering wikipedia.org, that domain is associated with the name servers gunther.bomis.com and zwinger.wikipedia.org at the .org registry. Consequently, in the example above, when the server identified by 204.74.112.1 receives a request, the DNS server scans its list of domains, locates wikipedia.org, and returns the name servers associated with that domain. Name servers in delegations are 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 bootstrapping problem when the name of the nameserver is in the domain about which nothing is yet known, 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.

DNS in practice

When an application (such as a web browser) tries to find the IP address of a domain name, it doesn't necessarily follow all of the steps outlined in the Theory section above. We will first look at the concept of caching, then outline the operation of DNS in "the real world".

Caching and time to live

Because of the huge volume of requests generated by a system like the DNS, the designers wished to provide a mechanism to reduce the load on individual DNS servers. The mechanism devised provided that when a DNS resolver (i.e. client) received a DNS response, it would cache that response for a given period of time. A value (set by the administrator of the DNS server handing out the response) called the time to live, or TTL defines that period of time. Once a response goes into cache, the resolver will consult its cached (stored) answer; only when the TTL expires (or until an administrator manually flushes the response from the resolver's memory) will the resolver contact the DNS server for the same information. Generally, the time to live is specified in the Start of Authority (SOA) record. SOA parameters are:
- Serial — the zone serial number, incremented when the zone file is modified, so the slave and secondary name servers know when the zone has been changed and should be reloaded.
- Refresh — This is the number of seconds between update requests from secondary and slave name servers.
- Retry — This is the number of seconds the secondary or slave will wait before retrying when the last attempt has failed.
- Expire — This is the number of seconds before a master or slave will wait before considering the data stale if it cannot reach the primary name server.
- Minimum — Previously used to determine the minimum TTL, this is used for negative caching. (Newer versions of named will accept 'M','H','D' & 'W' suffixes indicating that the time interval is respectively in Minutes, Hours, Days and Weeks).

Caching time

An important consequence of this distributed and caching architecture is that changes to the DNS are not always immediately effective 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:00pm 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 the DNS: not everyone is necessarily seeing the same thing you're seeing. [http://www.ietf.org/rfc/rfc1537.txt RFC1537] helps to convey basic rules for how to set the TTL. Note that the term "propagation", although very widely used, is a poor term to describe the effects of caching. Specifically, it implies that [1] 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 [2] that you do not have control over the amount of time the record is cached (you have complete control for all DNS records on 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 you change the NS records for your domain or the IP addresses for hostnames of authoritative DNS servers using your 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).

DNS in the real world

TTL Users generally do not communicate directly with a DNS resolver. Instead DNS resolution is handled transparently via client applications such as web browsers (Mozilla Firefox, Safari, Opera, Internet Explorer, etc), mail clients (Outlook Express, Mozilla Thunderbird, etc), and other internet applications. When a request is made which necessitates a DNS lookup, such programs send a resolution request to the local DNS resolver in the 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 a designated DNS server or 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 configure that server's address manually or allow DHCP to set it; however, where systems administrators have configured systems to use their own DNS servers, their DNS resolvers will generally point to their own nameservers. This name server will then follow the process outlined above in DNS in theory, 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. As a final level of complexity, some applications such as Web browsers also have their own DNS cache, in order to reduce use of the DNS resolver library itself, which can add extra difficulty to DNS debugging, as it obscures which data is fresh, or lies in which cache. These caches typically have very short caching times of the order of 1 minute. A notable exception is Internet Explorer. Recent versions cache DNS records for 30 minutes[http://support.microsoft.com/default.aspx?scid=KB;en-us;263558].

Other DNS applications

The system outlined above provides a somewhat simplified scenario. The DNS includes several other functions:
- Hostnames and IP addresses do not necessarily match on a one-to-one basis. Many hostnames may correspond to a single IP address: combined with virtual hosting, this allows a single machine to serve many web sites. Alternatively a single hostname may correspond to many IP addresses: this can facilitate fault tolerance and load distribution, and also allows a site to move physical location seamlessly.
- There are many uses of DNS besides translating names to IP addresses. For instance, Mail transfer agents use DNS to find out where to deliver e-mail for a particular address. The domain to mail exchanger mapping provided by MX records accommodates another layer of fault tolerance and load distribution on top of the name to IP address mapping.
- Sender Policy Framework controversially takes advantage of a DNS record type, the TXT record.
- To provide resilience in the event of computer failure, multiple DNS servers provide coverage of each domain. In particular, thirteen root servers exist worldwide. DNS programs or operating systems have the IP addresses of these servers built in. The USA hosts, at least nominally, all but three of the root servers. However, because many root servers actually implement anycast, where many different computers can share the same IP address to deliver a single service over a large geographic region, most of the physical (rather than nominal) root servers now operate outside the USA. The DNS uses TCP and 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 typically comes into play only when the response data size exceeds 512 bytes, or for such tasks as zone transfer.

Standards

- RFC 1034 Domain Names - Concepts and Facilities.
- RFC 1035 Domain Names - Implementation and Specification.
- RFC 1183 New DNS RR Definitions
- RFC 1706 DNS NSAP Resource Records
- RFC 1876 Location Information in the DNS (LOC)
- RFC 1886 DNS Extensions to support IP version 6
- RFC 1912 Common DNS Operational and Configuration Errors
- RFC 1995 Incremental Zone Transfer in DNS
- RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
- RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
- RFC 2181 Clarifications to the DNS Specification
- RFC 2308 Negative Caching of DNS Queries (DNS NCACHE)
- RFC 2317 Classless IN-ADDR.ARPA delegation
- RFC 2672 Non-Terminal DNS Name Redirection
- RFC 2782 A DNS RR for specifying the location of services (DNS SRV)
- RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
- RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering
- RFC 3403 Dynamic Delegation Discovery System (DDDS) (NAPTR records)

Types of DNS records

Important categories of data stored in the DNS include the following:
- An A record or address record maps a hostname to a 32-bit IPv4 address.
- An AAAA record or IPv6 address record maps a hostname to a 128-bit IPv6 address.
- A CNAME record or canonical name record makes one domain name an alias of another. The aliased domain gets all the subdomains and DNS records of the original.
- An MX record or mail exchange record maps a domain name to a list of mail exchange servers for that domain.
- A PTR record or pointer record maps an IPv4 address to the canonical name for that host. Setting up a PTR record for a hostname in the in-addr.arpa domain that corresponds to an IP address implements reverse DNS lookup for that address. For example (at the time of writing), www.icann.net has the IP address 192.0.34.164, but a PTR record maps 164.34.0.192.in-addr.arpa to its canonical name, referrals.icann.org.
- An NS record or name server record maps a domain name to a list of DNS servers authoritative for that domain. Delegations depend on NS records.
- An SOA record or start of authority record specifies the DNS server providing authoritative information about an Internet domain, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.
- An SRV record is a generalized service location record.
- A TXT record allows an administrator to insert arbitrary text into a DNS record. For example, this record is used to implement the Sender Policy Framework specification. Other types of records simply provide information (for example, a LOC record gives the physical location of a host), or experimental data (for example, a WKS record gives a list of servers offering some well-known service such as HTTP or POP3 for a domain).

Internationalised domain names

Domain names must use only a subset of ASCII characters—the Roman alphabet in upper and lower case, the digits 0 through 9, and the hyphen. 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 software

Various flavors of DNS software implement the DNS, including:
- BIND (Berkeley Internet Name Daemon) – full featured, most popular, de facto Internet standard
- djbdns (Daniel J. Bernstein's DNS) – composed of several small-footprint components
- MaraDNS – UDP only
- VitalQIP (Lucent Technologies)
- Adonis DNS Management Appliance (BlueCat Networks Inc)
- NSD (Name Server Daemon) – small footprint, UDP only, authoritative only
- PowerDNS
- Microsoft DNS (in the server editions of Windows 2000 and Windows 2003)
- Simple DNS Plus (JH Software) - shareware, runs on Windows DNS-oriented utilities include:
- dig (the "domain information groper")
- mysqlBind - BIND 8/9 DNS server administration system for one or hundreds of DNS servers. GPL licensed.

Legal users of domains

Registrant

No one in the world really "owns" a domain name except the Network Information Centre (NIC), or domain name registry. Most of the NICs in the world receive an annual fee from a legal user in order for the legal user to utilise the domain name (i.e. a sort of a leasing agreement exists, subject to the registry's terms and conditions). Depending on the various naming convention of the registries, legal users become commonly known as "registrants" or as "domain holders". ICANN holds a complete list of domain registries in the world. One can find the legal user of a domain name by looking in the WHOIS database held by most 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, expiry dates etc). For instance, DENIC, Germany NIC holds the authoritative WHOIS to a .DE domain name. However, some domain registries, such as VeriSign, use a registry-registrar model. There are hundreds of Domain Name Registrars that actually perform the domain name registration with the end-user, such as eNom. 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'. For .COM, .NET domain names, the domain registries, 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. Since about 2001, most gTLD registries (.ORG, .BIZ, .INFO) have adopted a so-called "thick" registry approach, i.e. keeping the authoritative WHOIS with the various registries instead of the registrars.

Administrative contact

A registrant usually designates an administrative contact to manage the domain name. In practice, the administrative contact usually has the most immediate power over a domain. Management functions delegated to the administrative contacts may include (for example):
- the obligation to conform to the requirements of the domain registry in order to retain the right to use a domain name
- authorisation to update the physical address, e-mail address and telephone number etc in WHOIS

Technical contact

A technical contact manages the name servers of a domain name. The many functions of a technical contact include:
- making sure the configurations of the domain name conforms to the requirements of the domain registry
- updating the domain zone
- providing the 24x7 functionality of the name servers (that leads to the accessibility of the domain name)

Billing contact

Self-explanatory, the party whom a NIC invoices.

Name servers

Namely the authoritative name servers that host the domain name zone of a domain name.

Politics

Many investigators have voiced criticism of the methods used currently to control ownership of domains. Most commonly, critics claim abuse by monopolies or near-monopolies, such as VeriSign, Inc., and problems with assignment of top-level domains. The international body ICANN (the Internet Corporation for Assigned Names and Numbers) oversees the domain name industry.

Truth in Domain Names Act

In the United States, the "Truth in Domain Names 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

External links and documentation

- [http://www.linux.ie/articles/dns.php All About DNS]
- [http://www.linux.ie/articles/tutorials/dns-tsig.php Securing DNS with Transaction Signatures]
- [http://www.nap.edu/execsumm_pdf/11258.pdf Signposts in Cyberspace: The Domain Name System and Internet Navigation (PDF format)]
- [http://cr.yp.to/djbdns/forgery.html DNS Forgery]
- [http://ketil.froyn.name/poison.html DNS Poisoning, a practical example]
- [http://www.windowsnetworking.com/articles_tutorials/Quickly-Test-DNS-Resolution.html How to 'Quickly' Test DNS Resolution]
- [http://www.ckdhr.com/dns-loc/sites.html Sites supporting DNS LOC]
- [http://www.bind9.net/dns-links Domain Name System Links, Whitepapers, and Research]
- [http://www.dnswatch.info DNS lookups] shows recursive search process during dns lookup
- [http://www.adminschoice.com/docs/domain_name_service.htm Setting up DNS server in unix]
- [http://www.DNSstuff.com Online DNS tools]
- [http://support.microsoft.com/default.aspx?scid=KB;en-us;263558 Microsoft KB Article on IE Cache Times]
- [http://pdos.csail.mit.edu/chord/papers/ddns.pdf Serving DNS using a Peer-to-Peer Lookup Service]
- [http://distributeddns.sourceforge.net/ Distributed DNS] Category:Internet standards Category:Internet protocols ko:DNS ms:Sistem Nama Domain ja:Domain Name System

Document

For the R.E.M. album, see: Document (album) A document is a writing that contains information. Traditionally, the medium of a document was paper and the information was applied to it as ink either by hand (to make a hand-written document) or by a mechanical process (such as a printing press or a laser printer). Through time, documents have also been written with ink on papyrus (starting in ancient Egypt) or parchment, scratched as runes on stone using a sharp apparatus, stamped or cut into clay and baked to make clay tablets (i.e. in Sumerian and Mesopotamian civilisations). Paper, papyrus or parchment might be rolled up as scrolls or cut into sheets and bound into books. Stacks of clay tablets might also be thought of as books. Small documents might also be stapled. Today, electronic means for storing and displaying documents are also popular; a variety of computers and displays can be used, for example:
- a desktop computer with a monitor
- a laptop
- a Personal Digital Assistant
- refreshable electronic paper Documents in all forms are frequently found to be material evidence in criminal and civil proceedings. The forensic analysis of such a document falls under the scope of questioned document examination. Author Michael Buckland has discussed the document in terms of Librarianship in depth, here [http://www.sims.berkeley.edu/~buckland/whatdoc.html]. ---- For an in-depth, recent and multiapproach study, see the collective text Document: Form, Sign and Medium, As Reformulated for Electronic Documents, written under pseudo Roger T. Pédauque ([http://archivesic.ccsd.cnrs.fr/sic_00000511.html French version] or [http://archivesic.ccsd.cnrs.fr/documents/archives0/00/00/05/94/sic_00000594_02/sic_00000594.html English version]). ----

Request for comment

In internetworking and computer network engineering, Request for Comments (RFC) documents are a series of memoranda encompassing new research, innovations, and methodologies applicable to Internet technologies. Through the Internet Society, engineers and computer scientists may publish discourse in the form of an RFC memorandum, either for peer review or simply to convey new concepts, information, or (occasionally) engineering humor. The Internet Engineering Task Force (IETF) adopts some of the applied information theory published in RFCs as Internet standards. The IETF issues each RFC document a unique serial number. Once issued a numerical identifier and published, an RFC is never rescinded; if the document requires amendments, the authors publish a revised document via the IETF; therefore, some RFCs obsolete others. Together, the serialized RFCs compose a continuous historical record of the evolution of Internet standards.

RFC production and evolution

The RFC production process differs from the standardization process of formal standards organizations such as ANSI. Internet technology experts may submit an Internet Draft without support from an external institution. Practically speaking, standards-track RFCs are usually produced by experts participating in working groups which first publish an Internet Draft. This approach facilitates initial rounds of peer review before documents mature into RFCs. The RFC tradition of pragmatic, experience-driven, after-the-fact standards-authorship accomplished by individuals or small working groups has important advantages over the more formal, committee-driven process typical of ANSI or ISO. Emblematic of some of these advantages is the existence of a flourishing tradition of joke RFCs. Usually at least one a year is published, usually on April Fool's Day. The RFCs are most remarkable for how well they work - they manage to have neither the ambiguities that are usually rife in informal specifications, nor the committee-perpetrated misfeatures that often haunt formal standards, and they define a network that has grown to truly worldwide proportions. For more details about RFCs and the RFC process, see RFC 2026, "The Internet Standards Process, Revision 3".

History

The inception of the RFC format occurred in 1969 as part of the seminal ARPANET project. Today, it is the official publication channel for the IETF, the Internet Architecture Board (IAB), and —to some extent—the global community of computer network researchers in general. The authors of the first RFCs typewrote their work and circulated hard copies among the ARPA researchers. In December of 1969, researchers began distributing new RFCs via the now-operational ARPANET. RFC 1, entitled "Host Software", was written by Steve Crocker of the University of California, Los Angeles (UCLA), and published on April 7, 1969. Crocker first drafted the document in his bathroom to avoid waking his roommate. Many of the subsequent RFCs of the 1970s also came from UCLA, not only because of the quality of the scholarship, but also because UCLA was one of the first Interface Message Processors (IMPs) on ARPANET. Douglas Engelbart's Augmentation Research Center (ARC) at Stanford Research Institute was another of the four first ARPANET nodes, as well as the first Network Information Centre, and (as noted by the sociologist Thierry Bardini) the source of a large number of early RFCs. From 1969 until 1998, Jon Postel served as the sole RFC editor. Following his death, the Internet Society (acting on behalf of the IETF) contracted the Networking Division of the USC Information Sciences Institute to assume the editorship and publishing responsibilities (under the direction of the IAB).

Obtaining RFCs

Official sources for RFCs on the World Wide Web are the [http://www.rfc-editor.org/rfc.html RFC Editor] and the [http://www.ietf.org/rfc.html IETF repository]. Unofficially, they are obtainable from a multitude of mirrors accessible via the HyperText Transfer Protocol, anonymous FTP, the gopher protocol, and other prominent application layer protocols. One may retrieve any individual, published RFC via the following Uniform Resource Locator by replacing the # with the document's RFC serial number: http://www.ietf.org/rfc/rfc#.txt Every RFC is available as ASCII text, but may also be available in other file formats; however, the definitive version of any standards-track specification is always the ASCII version.

Sources

- [http://www.rfc-editor.org/rfcfaq.html RFC Frequently Asked Questions]

:This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.

Category:FOLDOC sourced articles

External links

- [http://www.rfc-editor.org/rfc.html RFC Database]
- [http://www.ietf.org/iesg/1rfc_index.txt RFC Index] (plaintext)
- [http://www.rfc-editor.org/rfcxx00.html Official RFC standardization status]
- [http://www.ietf.org/rfc.html RFCs from the IETF]
- [http://www.elook.org/computing/request-for-comments.htm eLook.org Computing Reference - Request for Comments]

RFC document mirrors

- [http://tangentsoft.net/rfcs/ Important RFCs]
- [http://www.faqs.org/rfcs/np.html RFC by Category] at [http://www.faqs.org/ faqs.org]
- [http://www.rfc-archive.org/ RFC-Archive.org]
- [http://rfclibrary.hosting.com/ RFC Index]
- [http://www.elook.org/computing/rfc/ eLook Computing Reference - RFC Database]
- [http://rfc.8x.ca/ RFC Library - Searchable RFC database]
- [http://zvon.org/tmRFC/RFC_share/Output/index.html ZVON RFC Repository] Category:Internet standards ja:Request for Comments

Internationalized domain names

An internationalized domain name (IDN) is an Internet domain name that (potentially) contains non-ASCII characters. Such domain names could contain letters with diacritics, as required by many European languages, or characters from non-Latin scripts such as Arabic or Chinese. However, the standard for domain names does not allow such characters, and much work has gone into finding a way around this, either by changing the standard, or by agreeing on a way to convert internationalized domain names into standard ASCII domain names while preserving the stability of the domain name system. IDN has, by the standards of the Internet, a long history; it was originally proposed prior to (by M. Duerst) and implemented in 1998 (by T.W.Tan et al). After much debate and many competing proposals, a system called Internationalizing Domain Names in Applications (IDNA) was adopted as the chosen standard, and is currently, as of 2005, in the process of being rolled out. In IDNA, the term internationalized domain name means specifically any domain name consisting only of labels to which the IDNA ToASCII algorithm can be successfully applied. ToASCII is based on the Punycode ASCII encoding of normalized (Nameprep) Unicode strings.

Internationalizing Domain Names in Applications

Internationalizing Domain Names in Applications (IDNA) is a mechanism defined in 2003 for handling internationalized domain names containing non-ASCII characters. Such domain names could not be handled by the existing DNS and name resolver infrastructure. Rather than redesigning the existing DNS infrastructure, it was decided that non-ASCII domain names should be converted to a suitable ASCII-based form by web browsers and other user applications; IDNA specifies how this conversion is to be done. IDNA was designed for maximum backward compatibility with the existing DNS system, which was designed for use with names using only a subset of the ASCII character set. An IDNA-enabled application is able to convert between the restricted-ASCII and non-ASCII representations of a domain, using the ASCII form in cases where it is needed (such as for DNS lookup), but being able to present the more readable non-ASCII form to users. Applications that do not support IDNA will not be able to handle domain names with non-ASCII characters, but will still be able to access such domains if given the (usually rather cryptic) ASCII equivalent. ICANN issued guidelines for the use of IDNA in June 2003, and it was already possible to register .jp domains using this system in July 2003. Several other top-level domain registries started accepting registrations in March 2004. Mozilla 1.4, Netscape 7.1 and Opera 7.11 are among the first applications to support IDNA. Microsoft has announced that Internet Explorer 7.0 will provide native support for IDN; previously, a browser plugin was required.

ToASCII and ToUnicode

The conversions between ASCII and non-ASCII forms of a domain name are accomplished by algorithms called ToASCII and ToUnicode. These algorithms are not applied to the domain name as a whole, but rather to individual labels. For example, if the domain name is www.example.com, then the labels are www, example and com, and ToASCII or ToUnicode would be applied to each of these three separately. The details of these two algorithms are complex, and are specified in the RFCs linked at the end of this article. The following gives an overview of their behaviour. ToASCII leaves unchanged any ASCII label, but will fail if the label is unsuitable for DNS. If given a label containing at least one non-ASCII character, ToASCII will apply the Nameprep algorithm (which converts the label to lowercase and performs other normalization) and will then translate the result to ASCII using Punycode before prepending the 4-character string "xn--". This 4-character string is called the ACE prefix, where ACE means ASCII Compatible Encoding, and is used to distinguish Punycode-encoded labels from ordinary ASCII labels. Note that the ToASCII algorithm can fail in a number of ways; for example, the final string could exceed the 63-character limit for the DNS. A label on which ToASCII fails cannot be used in an internationalized domain name. ToUnicode reverses the action of ToASCII, stripping off the ACE prefix and applying the Punycode decode algorithm. It does not reverse the Nameprep processing, since that is merely a normalization and is by nature irreversible. Unlike ToASCII, ToUnicode always succeeds, because it simply returns the original string if decoding would fail. In particular, this means that ToUnicode has no effect on a string that does not begin with the ACE prefix.

Example of IDNA encoding

As an example of how IDNA works, suppose the domain to be encoded is Bücher.ch. This has two labels, Bücher and ch. The second label is pure ASCII, and so is left unchanged. The first label is processed by Nameprep to give bücher, and then by Punycode to give bcher-kva, and then has xn-- prepended to give xn--bcher-kva. The final domain suitable for use with the DNS is therefore xn--bcher-kva.ch.

Spoofing concerns

Because IDN allows websites to use full Unicode names, it also makes it much easier to create a spoofed web site that looks exactly like another, including domain name and security certificate, but in fact is controlled by someone attempting to steal private information. These spoofing attacks potentially open users up to phishing attacks. These attacks are not due to technical deficiencies in either the Unicode or IDNA specifications, but due to the fact that different characters in different languages can look the same, depending on the font used. For example, Unicode character U+0430, Cyrillic small letter a ("а"), can look identical to Unicode character U+0061, Latin small letter a, ("a") which is the lowercase "a" used in English. Technically, characters that look alike in this way are known as a homonym in orthographic form called homographs. Although a computer may display visually identical or very similar glyphs for two different characters, these differences are still significant (to the computer, but not the user) when locating the web sites or validating certificates. Thus, the user's assumption of a one-to-one correspondence between the visual appearance of a name, and the named entity, breaks down. For example, someone could register a domain name that appears identical to an existing domain but goes somewhere else. For example, the spoofed domain "pаypal.com" contains a Cyrillic a, not a Latin a. In many ways, this is not a new thing. Even staying within the old character set of A-Z, 0-9 and hyphen, G00GLE.COM is easily confused with GOOGLE.COM, for example. What was new was that the expansion of the character repertoire from a few dozen characters in a single alphabet to many thousands of characters in many scripts greatly increased the scope for homograph attacks. In general, this kind of attack is known as a homograph spoofing attack. This problem was anticipated before IDN was introduced and guidelines for registries were made to try and avoid or reduce the problem for example recommending that registries only accepting the latin alphabet and that of their own country not all of unicode. Sadly some major registries ignored them. On February 7 2005, Slashdot reported that this exploit was disclosed at the hacker conference Schmoocon with an example available at http://www.shmoo.com/idn/. On browsers supporting IDNA, the URL "http://www.pаypal.com/" (where the first a is replaced by a Cyrillic а) appears to lead to paypal.com but instead leads to a spoofed PayPal web site that says "Meeow." It is possible to work around this problem in Gecko-based browsers (such as Mozilla Firefox and Mozilla Navigator) by turning off IDN support entirely. To do this, type "about:config" into the address bar, bringing up the list of browser settings. Then find the "network.enableIDN" setting, and change the value to "false". The browser will then report IDN URLs as nonexistent. Note that on some versions (particularly, Firefox 1.0), this work-around only works for the first session only. Closing the browser and restarting leaves the user vulnerable again (though the option remains disabled). This can be corrected by clearing the browser's cache. On February 17, 2005, Mozilla developers announced that they would ship their next versions of their software with IDN support still enabled, but showing the punycode URLs instead, thus thwarting any attacks while still allowing people to access websites on an IDN domain. This is a change from the earlier plans to disable IDN entirely for the time being. [https://bugzilla.mozilla.org/show_bug.cgi?id=279099#c135] Since then, both Mozilla and Opera have now announced that they will be using per-domain whitelists to selectively switch on IDN display for domain run by registries which are taking appropriate anti-spoofing precautions. (See the article on homograph spoofing attacks for more details). As of September 9, 2005, the most recent version of Mozilla Firefox displays the spoofed Paypal URL as "http://www.xn--pypal-4ve.com/", unsightly but clearly different from the actual [https://www.paypal.com paypal.com].

History of IDN

- 1996-97: Martin Duerst's original Internet Draft proposing UTF5 (the first incarnation of what is known today as ACE)- UTF-5 was first defined by Martin Duerst at the University of Zurich in draft-duerst-dns-i18n-00.txt. See early history of IDN http://www.minc.org/about/history/earlyhistory.shtml; http://www.connect-world.com/Articles/Dr-TanTinWee.htm.
- 03/98: Early Research on IDN at National University of Singapore, Center for Internet Research (formerly Internet Research and Development Unit - IRDU) led by Tan Tin Wee (IDN Project team - Lim Juay Kwang and Leong Kok Yong)
- July 98: Geneva INET'98 conference with a BoF discussion on iDNS and APNG General Meeting and Working Group meeting.
- 07/98: Asia Pacific Networking Group (now still in existence [http://www.apng.org] and distinct from a gathering known as APSTAR [http://www.apstar.org]) iDNS Working Group formed - chaired not by James Seng who only joined the initiative after 1998 upon his return from studies in Australia. (See APNG Chairman's Commission on Internationalization of DNS http://www.apng.org/old/commission/idns/)
- 12/98: Pioneering effort to start precursor of iDNS.net International Inc, founded by S. Subbiah and T.W. Tan as a university start-up company to drive the mass popularisation and commercialisation of IDN. James Seng was recruited and subsequently appointed as CTO of iDNS.net.
- 02/99: iDNS Testbed launched with participation from CNNIC, JPNIC, KRNIC, TWNIC, THNIC, HKNIC and SGNIC. See early history of IDN http://www.minc.org/about/history/idns/idomain/
- 02/99: Presentation of Report on IDN at Joint APNG-APTLD meeting, at APRICOT'99
- 03/99: Endorsement of the IDN Report at APNG General Meeting 1 March 1999.
- 06/99: Grant application by APNG jointly with the Centre for Internet Research (CIR), National University of Singapore, to the International Development Research Center (IDRC), a Canadian Governement funded international organisation to work on IDN for IPv6. This APNG Project was funded under the Pan Asia R&D Grant administered on behalf of IDRC by the Canadian Committee on Occupational Health and Safety (CCOHS). Principal Investigator: Tan Tin Wee of National University of Singapore. See Pan Asia R&D Grant Number: 982.3.3 http://www.apng.org/old/commission/idns/ipv6/.
- 07/99: [http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-jseng-utf5-00.txt]; Renewed 2000 [http://www.nic.ad.jp/ja/idn/mdnkit/download/documents/mdnkit-2.4-doc/reference/draft/draft-jseng-utf5-01.txt] Internet Draft on UTF5 by James Seng (BIX Pte Ltd), Martin Duerst (W3C) and Tan Tin Wee (NUS).
- 08/99: APTLD and APNG forms a working group to look into IDN issues chaired by Kilnam Chon http://www.minc.org/about/history/idns/iname/
- 11/99: IETF IDN Birds-of-Feather in Washington
- Late 1999: Kilnam Chon initiates Task Force on IDNS which led to formation of MINC, the Multilingual Internet Names Consortium. See http://www.minc.org/oldminc/old/meetings/.
- 01/00: IETF IDN Working Group formed chaired by James Seng and Marc Blanchet
- 02/2000: Multilingual Internet Names Consortium(MINC) Proposal BoF at IETF Adelaide. See http://www.minc.org/oldminc/old//meetings/minc_20000327.html
- 03/2000: APRICOT 2000 Multilingual DNS session http://www.apricot.net/apricot2000/index2.html
- 05/2000: Interoperability Testing WG, MINC meeting. San Francisco, chaired by Bill Manning and Y.Yoneya 12 May 2000. See http://www.minc.org/oldminc/old/meetings/sanfrancisco_20000512/testing_SFO.htm
- 06/2000: Inaugural Launch of the Multilingual Internet Names Consortium (MINC) in Seoul http://www.minc.org to drive the collaborative roll-out of IDN starting from the Asia Pacific. See History of MINC http://www.minc.org/about/history/.
- 07/2000: Joint Engineering TaskForce (JET) initiated in Yokohama to study technical issues led by JPNIC (K.Konishi)
- 07/2000: Official Formation of CDNC Chinese Domain Name Consortium to resolve issues related to and to deploy Han Character domain names, founded by CNNIC, TWNIC, HKNIC and MONIC in May 2000 http://www.cdnc.org/english/introduction/index.html. See http://www.cdnc.org/english/news/index.html.
- 03/01: ICANN Board IDN Working Group formed
- 07/01: Japanese Domain Name Association : JDNA Lauch Ceremony (July 13, 2001) in Tokyo, Japan.
- 07/01: Urdu Internet Names System (July 28, 2001) in Islamabad, Pakistan, Organised Jointly by SDNP and MINC http://urduworkshop.sdnpk.org
- 07/01: Presentation on IDN to the Committee Meeting of the Computer Science and Telecommunications Board, National Academies USA (JULY 11-13, 2001)at University of California School of Information Management and Systems, Berkeley, CA. See CSTB publicationhttp://www.nap.edu/books/0309096405/html/390.html.
- 08/01: MINC presentation and outreach at the Asia Pacific Advanced Network annual conference, Penang, Malaysia 20th August 2001
- 10/01: Joint MINC-CDNC Meeting in Beijing 18-20 October 2001
- 11/01: ICANN IDN Committee formed
- 12/01: Joint ITU-WIPO Symposium on Multilingual Domain Names organised in association with MINC, 6-7 Dec 2001, International Conference Center, Geneva.
- 03/03: Publication of RFC 3454, RFC 3490, RFC 3491 and RFC 3492
- 06/03: Publication of [http://www.icann.org/general/idn-guidelines-20jun03.htm ICANN IDN Guidelines for registries]
- 05/04: Publication of RFC 3743, Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean

DNS registries known to have adopted IDNA

- .ac: see [http://www.nic.ac/AC-IDN-Policy.pdf details]
- .at: (March 1 2004), see [http://www.nic.at/en/service/idn/iz_zeichentabelle.asp details]
- .br: (May 9 2005) for Portuguese names, see [http://registro.br/anuncios/20050504.html details]
- .com: see [http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/index.html details]
- .ch: (March 1 2004)
- .cl: (September 21 2005), see [http://www.nic.cl/CL-IDN-policy.html details]
- .cn
- .de: (March 1 2004), see [http://www.denic.de/en/domains/idns/liste.html details]
- .dk: (January 2 2004), (æ, ø, å, ö, ä, ü, & é)
- .fi: (September 1 2005), see [http://www.ficora.fi/englanti/internet/IDN.htm details]
- .gr: (July 4 2005) for Greek names, see [https://grweb.ics.forth.gr/english/gr_char_en.html details]
- .hu
- .info: (March 19 2004) see [http://www.afilias.info/register/idn/ details]
- .io: see [http://www.nic.io/IO-IDN-Policy.pdf details]
- .li: (March 1 2004)
- .lv: (2004), see [http://www.nic.lv/DNS/lvdomain.php details]
- .jp: (July 2003), for Japanese characters (Kanji, hiragana & katakana)
- .kr: (August 2003), for Korean characters
- .museum: (January 20 2004), see [http://about.museum/idn/ details]
- .net: see [http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/index.html details]
- .no: (February 9 2004), see [http://www.norid.no/domeneregistrering/idn/idn_nyetegn.en.html details]
- .nu: see [http://www.nunames.nu/Local-Language.cfm details]
- .org: (January 18 2005), see [http://www.pir.org/GetAOrg/FAQ-IDN.aspx details]
- .pl: (September 11 2003)
- .se: (October 2003), for Swedish characters (ä, ö & å)
- .tw: for Chinese characters
- .sh: see [http://www.nic.sh/SH-IDN-Policy.pdf details] Alternatively, a Singaporian company called [http://www.i-dns.net/ I-DNS] also proposes via an own registrar network generic domain name registrations in various languages, but the country codes at the end of the domain names are also transcripted into the same characters as the domain names. However, this company is not affiliated with ICANN.

External links

- RFC 3454 (Stringprep)
- RFC 3490 (IDNA)
- RFC 3491 (Nameprep)
- RFC 3492 (Punycode)
- [http://www.icann.org/general/idn-guidelines-20jun03.htm ICANN Guidelines for the Implementation of Internationalized Domain Names]
- [http://www.imc.org/idna/ Internet Mail Consortium IDNA test tool] (includes Perl source code)
- [http://www.atm.tut.fi/list-archive/ietf-announce/msg13572.html IANA e-mails explaining the final choice of ACE prefix]
- [http://www.gnu.org/software/libidn/ GNU Libidn] is an implementation of IDNA
- [http://www.verisign.com/products-services/naming-and-directory-services/naming-services/internationalized-domain-names/page_002201.html List of all applications which have implemented IDNA along with a list of open source SDKs]
- [http://www.unicode.org/reports/tr36/ Unicode Technical Report #36 - Security Considerations for the Implementation of Unicode and Related Technology]
- [http://www.motobit.com/util/punycode-decoder-encoder.asp Online Punycode/IDN Decoder/Encoder]
- [http://www.icann.org/topics/idn.html ICANN Internationalized Domain Names]
- [http://idn.isc.org/ ISC IDN-OSS project]
- [http://www.iana.org/assignments/idn/ IDN Language Table Registry]
- [http://www.shmoo.com/idn/ The Shmoo Group: IDN]
- [http://www.microsoft.com/downloads/details.aspx?FamilyId=E289BB2C-D111-4331-8FB2-CC6C5A026C93&displaylang=en Microsoft Internationalized Domain Names (IDN) Mitigation APIs 1.0]
- [http://www.idnforums.com IDN Forums] - [http://www.idnforums.com/converter/ IDN Conversion Tool]
- [http://www.cs.technion.ac.il/~gabr/papers/homograph_full.pdf The Homograph Attack], Evgeniy Gabrilovich and Alex Gontmakher, Communications of the ACM, 45(2):128, February 2002 Category:Domain Name System ko:자국어 도메인 ja:国際化ドメイン名

Uniform Resource Locator

A Uniform Resource Locator, URL (properly pronounced as a spelled-out initialism, not syllabized as 'earl'), or Web address, is a standardized address name layout for resources (such as documents or images) on the Internet (or elsewhere). First created by Tim Berners-Lee for use on the World Wide Web, the currently used forms are detailed by Internet standard RFC 1738. It is also known as Universal Resource Locator [http://www.orafaq.com/glossary/faqglosu.htm],[http://www.patrickgavin.com/SEO-Glossary.htm],[http://www.wda.org/Public/help/glossary.htm]. The URL was a fundamental innovation in the history of the Internet. The syntax is designed to be generic, extensible, and able to express addresses in any character set using a limited subset of ASCII characters (for instance, whitespace is never used in a URL). URLs are classified by the "scheme" which typically identifies the network protocol used to retrieve the resource over a computer network.

Definition

URIs and URLs

Every URL is a type of Uniform Resource Identifier (URI), or more precisely the set of URLs is a proper subset of the set of URIs. A URI identifies a particular resource while a URL both identifies a resource and indicates how to locate it. To illustrate the distinction consider the URI urn:ietf:rfc:1738 which identifies IETF RFC 1738 without indicating where to find the text of this RFC. Now consider three URLs for three separate documents containing the text of this RFC:
- http://www.ietf.org/rfc/rfc1738.txt
- http://www.w3.org/Addressing/rfc1738.txt
- http://rfc.sunsite.dk/rfc/rfc1738.html Each URL uniquely identifies each document and thus is a URI itself, but URL syntax is such that the identity allows one to also locate each of these documents. Thus, a URL functions as the document's address. Historically, the terms have been almost synonymous as almost all URIs have also been URLs. For this reason, many definitions in this article mention URIs instead of URLs; the discussion applies to both URIs and URLs.

URL scheme

A URL begins with the name of its scheme, followed by a colon, followed by a scheme-specific part. Some examples of URL schemes:
- http - HTTP resources
- https - HTTP over SSL
- ftp - File Transfer Protocol
- mailto - E-mail address
- ldap - Lightweight Directory Access Protocol lookups
- file - resources available on the local computer or over a local file sharing network
- news - Usenet newsgroups
- gopher - the Gopher protocol
- telnet - the telnet protocol
- data - the Data: URL scheme for inserting small pieces of content in place See also http://www.iana.org/assignments/uri-schemes

Generic URI syntax

The syntax of the scheme-specific part depends on the requirements of the scheme. Schemes using typical connection-based protocols use a common "generic URI" syntax, defined below: scheme://authority/path?query The authority typically consists of a hostname or IP address of a server, optionally followed by a colon and a port number. It may in fact also contain information on username and password for authenticating to the server. The path is a specification of a location in some hierarchical structure, using a slash ("/") as delimiter between components. The query part is typically intended to express parameters of a dynamic query to some database residing on the server.

Example: HTTP URLs

The URLs employed by HTTP, the protocol used to transmit web pages, are the most popular kind of URI and can be used as an example to demonstrate the concept of the URI. The HTTP URL syntax is: scheme://host:port/path?parameter=value#anchor
- scheme, in the case of HTTP, is most of the time http, but https can also be used for signifying HTTP over a TLS connection (to make the connection more secure).
- Many web browsers allow use of scheme://username:password@host:port/... for HTTP authentication. This format has been used as an exploit to make it difficult to correctly identify the server involved. Consequently, support for this format has been dropped from some browsers. According to section 3.3 of RFC 1738, "No user name or password is allowed" in HTTP URLs.
- host, which is probably the most prominent part of a URL, is in almost all cases the domain name of a server, e.g. www.wikipedia.org, google.com, www.imv.au.dk, etc.
- The :port portion specifies an IP port number. It is usually omitted (defaults to 80 in that case) and in the entire URL probably has the least relevance for the user.
- The path portion is used by the server (specified by host) in whatever way the server's software is set up, but in many cases it specifies a filename, possibly prepended with directory names. For example, in the path /wiki/Cow, wiki would be a (pseudo-)directory and Cow would be a (pseudo-)filename.
- The part given above as ?parameter=value is referred to as query portion (sometimes search portion). It can either be omitted, have one parameter-value pair as in the example, or have many of them, which is expressed as ?para=value&anotherpara=value&.... The parameter-value pairs are only relevant if the file specified by the path is not a simple, static webpage, but some sort of automatically generated page. The generator software uses the parameter-value pairs in any way it is set up; mostly they carry information specific to one user and one moment in the use of the site, like concrete search terms, usernames, etc. (Watch, for example, how the URL in your browser's address bar behaves during a [http://google.com/ Google] search: your search term is passed to some sophisticated program on google.com as a parameter, and Google's program returns a page with the search results to you.)
- The #anchor part, lastly, is called fragment identifier and refers to certain significant places inside a page; for example, this Wikipedia page has anchors at each section heading which can be referred to via the fragment ID. They are relevant if a URL should be given which, when loaded in a browser, directly jumps to a certain point in a long page. An example would be this link, which leads to this page and to the beginning of this section. (Watch how the URL in your browser's address bar changes when clicking the link.) For another example of a HTTP URL, see below.

URI references

The term URI reference means a particular instance of a URI, or portion thereof, as used in, for instance, an HTML document, in order to refer to a particular resource. A URI reference often looks just like a URL or the tail end of a URL. URI references introduce two new concepts: the distinction between absolute and relative references, and the concept of a fragment identifier. An absolute URL is a URI reference that is just like a URL defined above; it starts with a scheme followed by a colon and then a scheme-specific part. A relative URL is a URI reference that comprises just the scheme-specific part of a URL, or some trailing component thereof. The scheme and leading components are inferred from the context in which the URL reference appears: the base URI (or base URL) of the document containing the reference. A URI reference can also be followed by a hash sign ("#") and a pointer to within the resource referenced by the URI as a whole. This is not a part of the URI as such, but is intended for the "user agent" (browser) to interpret after a representation of the resource has been retrieved. Therefore, it is not supposed to be sent to the server in HTTP requests. Examples of absolute URLs:
- http://en.wikipedia.org/w/wiki.phtml?title=Train&action=history
- http://en.wikipedia.org/wiki/Train#Freight_trains Examples of relative URLs:
- //nl.wikipedia.org/wiki/Train
- /wiki/Train
- Train#Passenger_trains

Case-sensitivity

URLs in general are case-sensitive; however it is up to the server administrator to decide to respect case when responding to requests. For convenience some webservers send the same page for URLs differing only in case.

URLs in everyday use

A HTTP URL combines into one simple address the four basic items of information necessary to retrieve a resource from anywhere on the Internet:
- the protocol to use to communicate,
- the host (server) to communicate with,
- the network port on the server to connect to,
- the path to the resource on the server (for example, its file name). A typical URL can look like: http://en.wikipedia.org:80/wiki/Special:Search?search=train&go=Go where
- http is the protocol,
- en.wikipedia.org is the host,
- 80 is the network port number on the server (as 80 is the default value for the HTTP protocol, this portion could have been omitted entirely),
- /wiki/Special:Search is the resource path,
- ?search=train&go=Go is the query string; this part is optional. Most web browsers do not require the user to enter "http://" to address a webpage, as HTTP is by far the most common protocol used in web browsers. Likewise, since 80 is the default port for http it is not usually specified. One usually just enters a partial URL such as www.wikipedia.org/wiki/Train. To go to a homepage one usually just enters the host name, such as www.wikipedia.org. Since the HTTP protocol allows a server to respond to a request by redirecting the web browser to a different URL, many servers additionally allow users to omit certain parts of the URL, such as the "www." part, or the trailing slash if the resource in question is a directory. However, these omissions technically make it a different URL, so the web browser cannot make these adjustments, and has to rely on the server to respond with a redirect. It is possible, but due to tradition rare, for a web server to serve two different pages for URLs that differ only in a trailing slash. Note that in en.wikipedia.org/wiki/Train, the hierarchical order of the five elements is org (generic top-level domain) - wikipedia (second-level domain) - en (subdomain) - wiki - Train; i.e. before the first slash from right to left, then the rest from left to right. For a more extensive discussion of HTTP URLs and their use, see above.

The big picture

The term URL is also used outside the context of the World Wide Web. Database servers specify URLs as a parameter to make connections to it. Similarly any Client-Server application following a particular protocol may specify a URL format as part of its communication process. Example of a database URL : jdbc:datadirect:oracle://myserver:1521;sid=testdb If a webpage is uniquely and more or less permanently defined by a URL it can be linked to (see also permalink, deep linking). This is not always the case, e.g. a menu option may change the contents of a frame within the page, without this new combination having its own URL. A webpage may also depend on temporarily stored information. If the webpage or frame has its own URL, this is not always obvious for someone who wants to link to it: the URL of a frame is not shown in the address bar of the browser, and a page without address bar may have been produced. The URL may be derivable from the source code and/or "properties" of various components of the page. See also Webpage#URL. Apart from the purpose of linking to a page or page component, one may want to know the URL to show the component alone, and/or to lift restrictions such as a browser window without toolbars, and/or of a small non-adjustable size. Web servers also have the ability to redirect URLs if the destination has changed, allowing sites to change their structure without affecting existing links. This process is known as URL redirection.

External links

- RFC 1738 – Uniform Resource Locators (URL).
- RFC 3986 – Uniform Resource Identifier (URI): Generic Syntax.
- [http://www.blooberry.com/indexdot/html/topics/urlencoding.htm URL Encoding (or: 'What are those "%20" codes in URLs?') by Brian Wilson] - some URL encoding charts and converter.
- [http://i-technica.com/whitestuff/urlencodechart.html URLEncode Code Chart (from i-Technica)] - URL encoding chart. Category:URI scheme Category:Internet standards Category:Identifiers als:URL ko:URL ja:Uniform Resource Locator

Protocol (computing)

In computing, a protocol is a convention or standard that controls or enables the connection, communication, and data transfer between two computing endpoints. In its simplest form, a protocol can be defined as the rules governing the syntax, semantics, and synchronization of communication. Protocols may be implemented by hardware, software, or a combination of the two. At the lowest level, a protocol defines the behavior of a hardware connection. Protocols should be distinguished from technical standards, which variously specify how to build a computer or related hardware device, or how the contents of a file are structured, or describe the static structure of a network interface. Protocols are generally used to define real-time communications behavior, while standards are used to govern the structure of information committed to long-term storage. It is difficult to generalize about protocols because they vary so greatly in purpose and sophistication. Most protocols specify one or more of the following behaviors:
- Detection of the underlying physical connection (wired or wireless), or the existence of the other endpoint or node
- Handshaking
- Negotiation of various connection characteristics
- How to start and end a message
- How to format a message
- What to do with corrupted or improperly formatted messages (error correction)
- How to detect unexpected loss of the connection, and what to do next
- Termination of the session or connection The widespread use and expansion of communications protocols is both a prerequisite to the Internet, and a major contributor to its power and success. The pair of Internet Protocol (or IP) and Transmission Control Protocol (or TCP) are the most important of these, and the term TCP/IP refers to a collection (or protocol suite) of its most used protocols. Most of the Internet's communication protocols are described in the RFC documents of the Internet Engineering Task Force (or IETF). Object-oriented programming has extended the use of the term to include the programming protocols available for connections and communication between objects. Generally, only the simplest protocols are used alone. Most protocols, especially in the context of communications or networking, are layered together into protocol stacks where the various tasks listed above are divided among different protocols in the stack. Whereas the protocol stack denotes a specific combination of protocols that work together, the reference model is a software architecture that lists each layer and the services each should offer. The classic seven-layer reference model is the OSI model, which is used for conceptualizing protocol stacks and peer entities. This reference model also provides an opportunity to teach more general software engineering concepts like hiding, modularity, and delegation of tasks. This model has endured in spite of