Home About us Products Services Contact us Bookmark
:: wikimiki.org ::
Domain Name

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).

See also


- Uniform Resource Locator
- webpage
- website
- World Wide Web
- cname
- domain hack
- Free domain names

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:InternetCategory:Information technology Category:Identifiers als:Domäne (Internet) ja:ドメイン名

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

See also


- cybersquatting
- domain hack
- dynamic DNS
- DNS cache poisoning
- DNSSEC
- ICANN
- Root nameserver

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

Website

Website.]] A website, web site or WWW site (often shortened to just site) is a collection of web pages, typically common to a particular domain name or sub-domain on the World Wide Web on the Internet. A web page is an HTML/XHTML document accessible generally via HTTP. All publicly accessible websites in existence comprise the World Wide Web. The pages of a website will be accessed from a common root URL called the homepage, and usually reside on the same physical server. The URLs of the pages organise them into a hierarchy, although the hyperlinks between them control how the reader perceives the overall structure and how the traffic flows between the different parts of the sites. Some websites require a subscription to access some or all of their content. Examples of subscription sites include many Internet pornography sites, parts of many news sites, gaming sites, message boards, Web-based e-mail services and sites providing real-time stock market data.

Overview

A website will may be the work of an individual, a business or other organization and is typically dedicated to some particular topic or purpose. Any website can contain a hyperlink to any other website, so the distinction between individual sites, as perceived by the user, may sometimes be blurred. Websites are written in, or dynamically converted to, HTML (Hyper Text Markup Language) and are accessed using a software program called a web browser, also known as a HTTP client. Web pages can be viewed or otherwise accessed from a range of computer based and Internet enabled devices of various sizes, examples of which include desktop computers, laptop computers, PDAs and cell phones. A website is hosted on a computer system known as a web server, also called an HTTP Server, and these terms can also refer to the software that runs on these system and that retrieves and delivers the web pages in response to requests from the web site users. Apache is the most commonly used web server software (according to Netcraft statistics) and Microsoft's Internet Information Server (IIS) is also commonly used. A static website, is one that has content that is not expected to change frequently and is manually maintained by some person or persons using some type of editor software. There are two broad categories of editor software used for this purpose which are
- Text editors such as Notepad, where the HTML is manipulated directly within the editor program
- WYSIWYG editors such as Microsoft FrontPage and Macromedia Dreamweaver, where the site is edited using a GUI interface and the underlying HTML is generated automatically by the editor software. A dynamic website is one that may have frequently changing information. When the web server receives a request for a given page, the page is automatically generated by the software in direct response to the page request; thus opening up many possibilities including for example: a site can display the current state of a dialogue between users, monitor a changing situation, or provide information in some way personalised to the requirements of the individual user. There are a large range of software systems, such as Active Server Pages (ASP), Java Server Pages (JSP) and the PHP programming language that are available to generate dynamic web systems and dynamic sites also often include content that is retrieved from one or more databases or by using XML-based technologies such as RSS. Static content may also be dynamically generated periodically or if certain conditions for regeneration occur (cached) to avoid the performance loss of initiating the dynamic engine on a per-user or per-connection basis. Plugins are available for browsers, which use them to show active content, such as Flash, Shockwave or applets written in Java. Dynamic HTML also provides for user interactivity and realtime element updating within Web pages (i.e., pages don't have to be loaded or reloaded to effect any changes), mainly using the DOM and JavaScript, support for which is built-in to most modern browsers.

Types of websites

There are many varieties of websites, each specialising in a particular type of content or use, and they may be arbitrarily classified in any number of ways. A few such classifications might include:
- Archive site: used to preserve valuable electronic content threatened with extinction. Two examples are: Internet Archive which since 1996 preserves billions of old (and new) Web pages, and Google Groups which in early 2005 was archiving over 845,000,000 messages posted to Usenet news/discussion groups.
- Blog (or weblog) site: site used to log online readings or to post online diaries; may include discussion forums.
- Business site: used for promoting a business or service.
- Commerce site or eCommerce site: for purchasing goods, such as Amazon.com.
- Community site: a site where persons with similar interests communicate with each other, usually by chat or message boards.
- Database site: a site whose main use is the search and display of a specific database's content such as the Internet Movie Database or the Political graveyard.
- Development site: a site whose purpose is to provide information and resources related to software development, Web design and the like.
- Directory site: a site that contains varied contents which are divided into categories and subcategories, such as Yahoo! directory, Google directory and Open Directory Project.
- Download site: strictly used for downloading electronic content, such as software, game demos or computer wallpaper.
- Game site: a site that is itself a game or "playground" where many people come to play, such as MSN Games, Pogo.com and the MMORPGs Planetarion and Kings of Chaos.
- Information site: contains content that is intended merely to inform visitors, but not necessarily for commercial purposes; such as: RateMyProfessors.com, Free Internet Lexicon and Encyclopedia.
- News site: similar to an information site, but dedicated to dispensing news and commentary.
- Pornography site: a site that shows pornographic images and videos.
- Search engine site: a site that provides general information and is intended as a gateway or lookup for other sites. A pure example is Google, and the most widely known extended type is Yahoo!.
- Shock site: includes images or other material that is intended to be offensive to most viewers.
- Vanity site (or "personal site"): run by an individual or a small group (such as a family) that contains information or any content that the individual wishes to include.
- Web portal site: a website that provides a starting point, a gateway, or portal, to other resources on the Internet or an intranet.
- Wiki site: a site which users collaboratively edit (such as Wikipedia). Some sites may be included in one or more of these categories. For example, a business website may promote the business's products, but may also host informative documents, such as white papers. There are also numerous sub-categories to the ones listed above. For example, a porn site is a specific type of eCommerce site or business site (that is, it is trying to sell memberships for access to its site). A fan site may be a vanity site on which the administrator is paying homage to a celebrity. Many business Websites have the appearance of brochures—that is, an advertisement that can be strolled around. Some websites act as vehicles for users to communicate with other people via webchat. Websites are constrained by architectural limits (e.g. the computing power dedicated to the Website). Very large websites, such as Yahoo!, Microsoft, Google and most other very large sites employ several servers and load balancing equipment, such as Cisco Content Services Switches

Mousetrapping

Mousetrapping is a technique employed by some "aggressive" commercial websites, especially ones that are pornographic in nature, which prevents the user from leaving the site, depending on Web browser settings. Typically, this form of trapping is employed by the use of Javascript code (or Dynamic HTML) that detects a user's attempt to either close the browser window or leave the Website to view another site. These attempts may easily fail if the user disabled javascript on their Web browser; however, disabling Javascript may also impact how well certain pages on the current site or other Websites load. Tools such as pop-up blockers can help in preventing this annoyance but by no means will solve the problem entirely. [http://www.webopedia.com/TERM/M/mousetrapping.html]

Prizes

The Webby Awards are a set of awards presented to the world's "best" Websites.

Spelling

As noted above, there are several different spellings for this term. Although "website" is commonly used (particularly by some newspapers and other media), Reuters, Microsoft, academia, and dictionaries such as Oxford, prefer to use the two-word, capitalised spelling "Web site". An alternate version of the two-word spelling is not capitalised. As with many newly created terms, it may take some time before a common spelling is finalised. (This controversy also applies to derivative terms such as "Web master"/"webmaster".) The Associated Press Stylebook, a guide to newspaper style, suggests "Web site" and "Web page". "WWW site" is rarely used.

See also


- Webmaster
- Cyberspace
- Web application
- Web content management
- Web service
- Web template
- World Wide Web Consortium (Web standards)
- Microsoft FrontPage
- Macromedia Dreamweaver
- Web hosting

External links


- [http://www.w3.org/ World Wide Web Consortium]
- [http://www.isoc.org/ The Internet Society (ISOC)]
- [http://www.icann.org/ Internet Corporation For Assigned Names and Numbers]
- [http://www.useit.com Useit.com Internet Usability]
- [http://www.cgisecurity.com/questions/securewebsite.shtml How do I secure my website?] CGISecurity.com - Website Security Portal
- ko:웹사이트 ja:ウェブサイト simple:Website

Electronic mail

Electronic mail, abbreviated e-mail or email, is a method of composing, sending, and receiving messages over electronic communication systems. The term e-mail applies both to the Internet e-mail system based on the Simple Mail Transfer Protocol (SMTP) and to workgroup collaboration systems allowing users within one company or organization to send messages to each other. Often workgroup collaboration systems natively use non-standard protocols but have some form of gateway to allow them to send and receive internet e-mail. Some organizations may use the internet protocols for internal e-mail service.

Origins of e-mail

Despite common belief, e-mail actually predates the Internet; in fact, existing e-mail systems were a crucial tool in creating the Internet. E-mail started in 1965 as a way for multiple users of a time-sharing mainframe computer to communicate. Although the exact history is murky, among the first systems to have such a facility were SDC's Q32 and MIT's CTSS. E-mail was quickly extended to become network e-mail, allowing users to pass messages between different computers. The early history of network e-mail is also murky; the AUTODIN system may have been the first allowing electronic text messages to be transferred between users on different computers in 1966, but it is possible the SAGE system had something similar some time before. The ARPANET computer network made a large contribution to the evolution of e-mail. There is one report [http://www.multicians.org/thvv/mail-history.html] which indicates experimental inter-system e-mail transfers on it shortly after its creation, in 1969. Ray Tomlinson initiated the use of the @ sign to separate the names of the user and their machine in 1971 [http://openmap.bbn.com/~tomlinso/ray/firstemailframe.html]. The common report that he "invented" e-mail is an exaggeration, although his early e-mail programs SNDMSG and READMAIL were very important. The first message sent by Ray Tomlinson is not preserved; it was "a message announcing the availability of network email"[http://openmap.bbn.com/~tomlinso/ray/firstemailframe.html]. The ARPANET significantly increased the popularity of e-mail, and it became the killer app of the ARPANET.

Growing popularity

As the utility and advantages of e-mail on the ARPANET became more widely known, the popularity of e-mail increased, leading to demand from people who were not allowed access to the ARPANET. A number of protocols were developed to deliver e-mail among groups of time-sharing computers over alternative transmission systems, such as UUCP and IBM's VNET e-mail system. Since not all computers or networks were directly inter-networked, e-mail addresses had to include the "route" of the message, that is, a path between the computer of the sender and the computer of the receivers. E-mail could be passed this way between a number of networks, including the ARPANET, BITNET and NSFNET, as well as to hosts connected directly to other sites via UUCP. The route was specified using so-call "bang path" addresses, specifying hops to get from some assumed-reachable location to the addressee, so called because each hop is signified by a "bang sign" (the exclamation mark, !). Thus, for example, the path ...!bigsite!foovax!barbox!me directs people to route their mail to machine bigsite (presumably a well-known location accessible to everybody) and from there through the machine foovax to the account of user me on barbox. Before auto-routing mailers became commonplace, people often published compound bang addresses using the convention (see glob) to give paths from several big machines, in the hopes that one's correspondent might be able to get mail to one of them reliably (example: ...!!rice!beta!gamma!me). Bang paths of 8 to 10 hops were not uncommon in 1981. Late-night dial-up UUCP links would cause week-long transmission times. Bang paths were often selected by both transmission time and reliability, as messages would often get lost. E-mail became an increasingly important feature of work group collaboration products developed by vendors such as Wang, Lotus, IBM, and Microsoft. These systems often provided enhanced e-mail features (such as file attachments, Rich Text Format, and delivery confirmation), but only when sending e-mail to other users of the same system. These systems communicated with other, non-like, systems via specialized e-mail gateways which translated one vendor's (usually proprietary) e-mail format into a form understandable by another vendor. The CCITT developed the X.400 standard in the 1980's to allow different e-mail systems to interoperate. Roughly at the same time, the IETF developed a much simpler protocol called the Simple Mail Transfer Protocol (SMTP) which has become the de facto standard for e-mail transfer on the Internet. With the advent of widespread use of home personal computers connected to the Internet, interoperability via SMTP-based Internet e-mail has become a critical feature for all e-mail systems. In 1969 US Air Force users were sending text messages by keypunching cards with long text messages using one card for each 80 character line and transmitting them as card decks from one computer to another. By 1979, US Air Force users were logging onto central computers and leaving messages for government contractors and other US Air Force users to read in special file areas where their replies were often received back within hours. By the end of 1983 US Air Force users were using user names like alclark@vax1.mil to send emails between a nationwide linkup of VAX computers. By 1984 these same users were using personal computers for same. In 1982 the White House adopted a prototype email system from IBM called the Professional Office System, or PROFs for the National Security Council (NSC) staff. By April 1985, the system was fully operational within the NSC with home terminals for principals on the staff. And by November of 1986 the rest of the White House came online, first with the PROFs system, and later (by the end of the 1980s) through a variety of systems including VAX A-1 ("All in One"), and ccmail.

Modern Internet e-mail

How Internet e-mail works

ccmail The diagram above shows a stereotypical sequence of events that takes place when Alice sends an e-mail to Bob. # Alice composes a message using her mail user agent (MUA). She types in, or selects from an address book, the e-mail address of her correspondent. She hits the "send" button. Her MUA formats the message in Internet e-mail format and uses the Simple Mail Transfer Protocol (SMTP) to send the message to the local mail transfer agent (MTA), in this case smtp.a.org, run by Alice's Internet Service Provider (ISP). # The MTA looks at the destination address provided in the SMTP protocol (not from the message headers), in this case bob@b.org. A modern Internet e-mail address is a string of the form localpart@domain.example. The part before the @ sign is the local part of the address, often the username of the recipient, and the part after the @ sign is a domain name. The MTA looks up this domain name in the Domain Name System to find the mail exchange servers accepting messages for that domain. # The DNS server for the b.org domain, ns.b.org, responds with an MX record listing the mail exchange servers for that domain, in this case mx.b.org, a server run by Bob's ISP. # smtp.a.org sends the message to mx.b.org using SMTP, which delivers it to the mailbox of the user bob. # Bob presses the "get mail" button in his MUA, which picks up the message using the Post Office Protocol (POP3). This sequence of events applies to the majority of e-mail users. However, there are many alternative possibilities and complications to the e-mail system:
- Alice or Bob may use a client connected to a corporate e-mail system, such as IBM's Lotus Notes or Microsoft's Exchange. These systems often have their own internal e-mail format and their clients typically communicate with the e-mail server using a vendor-specific, proprietary, protocol. The server sends or receives e-mail via the Internet through the product's Internet mail gateway which also does any necessary reformatting. If Alice and Bob work for the same company, the entire transaction may happen completely within a single corporate e-mail system.
- Alice may not have a MUA on her computer but instead may connect to a webmail service.
- Alice's computer may run its own MTA, so avoiding the transfer at step 1.
- Bob may pick up his e-mail in many ways, for example using the Internet Message Access Protocol, by logging into mx.b.org and reading it directly, or by using a webmail service.
- Domains usually have several mail exchange servers so that they can continue to accept mail when the main mail exchange server is not available. It used to be the case that many MTAs would accept messages for any recipient on the Internet and do their best to deliver them. Such MTAs are called open mail relays. This was important in the early days of the Internet when network connections were unreliable. If an MTA couldn't reach the destination, it could at least deliver it to a relay that was closer to the destination. The relay would have a better chance of delivering the message at a later time. However, this mechanism proved to be exploitable by people sending unsolicited bulk e-mail and as a consequence very few modern MTAs are open mail relays, and many MTAs will not accept messages from open mail relays because such messages are very likely to be spam. Note that the people, email addresses and domain names in this explanation are fictional: see Alice and Bob.

Internet e-mail format

The format of Internet e-mail messages is defined in RFC 2822 and a series of RFCs, RFC 2045 through RFC 2049, collectively called Multipurpose Internet Mail Extensions (MIME). Although as of July 13, 2005 (see [http://www.ietf.org/iesg/1rfc_index.txt]) RFC 2822 is technically a proposed IETF standard and the MIME RFCs are draft IETF standards, these documents are the de facto standards for the format of Internet e-mail. Prior to the introduction of RFC 2822 in 2001 the format described by RFC 822 was the de facto standard for Internet e-mail for nearly two decades; it is still the official IETF standard. The IETF reserved the numbers 2821 and 2822 for the updated versions of RFC 821 (SMTP) and RFC 822, honoring the extreme importance of these two RFCs. RFC 822 was published in 1982 and based on the earlier RFC 733. Internet e-mail messages consist of two major sections:
- Headers - Message summary, sender, receiver, and other information about the e-mail
- Body - The message itself, sometimes containing a signature block at the end The header section is separated from the body by a blank line.

Internet e-mail headers

Each header has a name and a value. RFC 2822 specifies the precise syntax. Informally, the header name starts in the first character of a line, followed by a ":", followed by the value which is continued on non-null subsequent lines that have a space or tab as their first character. Header names and values are restricted to 7-bit ASCII characters. Non-ASCII values may be represented using MIME encoded words. Messages usually have at least four headers: # From: The e-mail address, and optionally name, of the sender of the message # To: The e-mail addresses, and optionally names, of the receiver of the message # Subject: A brief summary of the contents of the message # Date: The local time and date when the message was originally sent Note however that the "To" header in the message is not necessarily related to the addresses to which the e-mail is delivered. The actual delivery list is supplied in the SMTP protocol, not extracted from the header content. The "To" header is similar to the greeting at the top of a conventional letter which is delivered according to the address on the outer envelope. Also note that the "From" header does not have to be the real sender of the e-mail. It is very easy to fake the "From" line and let an e-mail seem to be from any mail address. It is possible to digitally sign an e-mail, which is much harder to fake. Some Internet service providers do not relay e-mails claiming to come from a domain not hosted by them, but very few (if any) check to make sure that the person or even e-mail account named in the "From" header is the one associated with the connection. Other common headers include: # Cc: Carbon copy (because typewriters use carbon paper to make copies of letters) # Received: Tracking information generated by mail servers that have previously handled a message # Content-Type: Information about how the message has to be displayed, usually a MIME type Many e-mail clients present "Bcc" (Blind carbon copy, recipients not visible in the "To" header) as a header. Since all the headers are visible to all recipients, "Bcc" isn't actually a header. Addresses added as "Bcc" are only added to the SMTP delivery list.

E-mail content encoding

Email was only designed for 7-bit ASCII. While a lot of email software was in fact 8 bit clean this couldn't be relied upon on open interchange. The MIME standard introduced charset specifiers and two content transfer encodings to encode 8 bit data for transmission: quoted printable for mostly 7 bit content with a few characters outside that range and base64 for arbitary binary data. The 8BITMIME extension was introduced to allow transmission of mail without the need for these encodings but many mail transport agents still don't support it fully, possibly due to the complication of having to do content transformations when forwarding to a mailserver that doesn't support it.

Saved Message Extension

Different applications save email files with different file extensions.
- .eml This is used by Outlook Express, and is the default email extension for Mozilla Thunderbird.
- .emlx Used by Apple Mail

Messages and mailboxes

Messages are exchanged between hosts using the Simple Mail Transfer Protocol with software like Sendmail. Users download their messages from servers usually with either the POP or IMAP protocols, yet in a large corporate environment users are likely to use some proprietary protocol such as Lotus Notes or Microsoft Exchange Server's. Mails can be stored either on the client or on the server side. Standard formats for mailboxes include Maildir and mbox. Several prominent e-mail clients use their own, proprietary format, and require conversion software to transfer e-mail between them. When a message cannot be delivered, the recipient MTA must send a bounce message back to the sender, indicating the problem.

Spamming and e-mail worms

The usefulness of e-mail is being threatened by three phenomena, spamming, phishing and e-mail worms. Spamming is unsolicited commercial e-mail. Because of the very low cost of sending e-mail, spammers can send hundreds of millions of e-mail messages each day over an inexpensive Internet connection. Hundreds of active spammers sending this volume of mail results in information overload for many computer users who receive tens or even hundreds of junk e-mails each day. E-mail worms use e-mail as a way of replicating themselves into vulnerable computers. Although the first e-mail worm affected early UNIX computers, this problem is today almost entirely confined to the Microsoft Windows operating system. The combination of spam and worm programs results in users receiving a constant drizzle of junk e-mail, which reduces the usefulness of e-mail as a practical tool. A number of technology-based initiatives mitigate the impact of spam. In the United States, U.S. Congress has also passed a law, the Can Spam Act of 2003, attempting to regulate such e-mail.

Privacy problems regarding e-mail

E-mail privacy, without some security precautions, can be compromised because
- e-mail messages are generally not encrypted;
- e-mail messages have to go through intermediate computers before reaching their destination, meaning it is relatively easy for others to intercept and read messages;
- many Internet Service Providers (ISP) store copies of your email messages on their mail servers before they are delivered. The backups of these can remain up to several months on their server, even if you delete them in your mailbox. There are cryptography applications that can serve as a remedy to the above, such as Virtual Private Networks, message encryption using PGP or the GNU Privacy Guard, encrypted communications with the e-mail servers using Transport Layer Security and Secure Sockets Layer, and/or encrypted authentication schemes such as Simple Authentication and Security Layer.

See also


- E-mail art
- E-mail social issues:
  - Netiquette
  - Information overload
  - Internet humor
  - Internet slang
  - Spam
  - stopping e-mail abuse
  - Computer virus.
- Clients and servers:
  - E-mail client
  - mail transfer agent
  - webmail / HTMLmail
  - branded e-mail
  - Unicode and Email
- Mailing list:
  - Electronic mailing list
  - mailing list archive
- E-mail address
- E-cards
- Internet mail standards
- Free e-mail services/webmail:
  - Hotmail
  - Yahoo! Mail
  - Gmail
  - Temporary hosting
- Uniform Resource Identifier
- Alternative protocols and projects
  - Trust-forum
  - Internet Mail 2000

Further reading


- Katie Hafner, Matthew Lyon, Where Wizards Stay Up Late: The Origins of the Internet (Simon and Schuster, 1996) also covers the early history of e-mail
- Abdullah, M. H. (1998). "Electronic discourse: Evolving conventions in online academic environments". Bloomington, IN: ERIC Clearinghouse on Reading, English, and Communication. [ED 422 593]
- Abras, C. (2002) The principle of relevance and metamessages in online discourse: Electronic exchanges in a graduate course. Language, "Literacy and Culture Review" 1(2), 39-53.
- Biesenbach-Lucas, S. & Wiesenforth, D. (2001). E-mail and word processing in the ESL classroom: How the medium affects the message. "Language Learning and Technology", 5 (1), 135-165. [EJ 621 506]
- Danet, B. (2001). Cyberplay: Communicating online. Oxford: Berg Publishing.

References

External links


- SourceForge's database of [http://sourceforge.net/softwaremap/trove_list.php?form_cat=28 free email software]
- [http://openmap.bbn.com/%7Etomlinso/ray/firstemailframe.html The First Network Email]
- A. Padlipsky, [http://www.lafn.org/~ba213/allnight.html And They Argued All Night...] is an alternative personal recollection of the origins of network e-mail
- [http://www.sciencedirect.com/science/article/B6VB4-4F0GR6R-1/2/6e8130c8b281029598bc40fe5934fdaf Email training significantly reduces email defects] from International Journal of Information Management
- [http://www.guardian.co.uk/uk_news/story/0,3604,1465950,00.html Guardian.co.uk] - 'Emails "pose threat to IQ"', Martin Wainwright, The Guardian (April 22, 2005)
- [http://www.multicians.org/thvv/mail-history.html The History of Electronic Mail] is a personal memoir by the implementer of one of the first e-mail systems
- [http://www.windowsecurity.com/articles/Encrypting-Your-E-mail.html Is it Time to Start Encrypting Your E-mail?] - Discusses the pros and cons of E-mail encryption
- [http://www.cyberbullying.us Cyberbullying News, Research, and Resources] Category:Digital Revolution Category:Internet terminology ko:전자 우편 ja:電子メール simple:Email th:อีเมล

Hostname

A hostname (occasionally also, a sitename) is the unique name by which a network attached device ( which could consist of a computer, file server, network storage device, fax machine, copier, cable modem, etc. ) is known on a network. The hostname is used to identify a particular host in various forms of electronic communication such as E-mail or Usenet. Hostnames are used by various naming systems: NIS, DNS, SMB, etc. Host names are typically used in an administrative capacity and may appear in computer browser lists, active directory lists, IP Address to hostname resolutions, email headers etc. They are human readable nick-names which ultimately correlate to unique network hardware MAC addresses. In some cases the host name may contain embedded domain names and/or locations, non-dotted IP addresses, etc. Special characters other than the underscore, dash and period are not allowed in the hostname designation although cohesion may cause them to appear. On a simple local area network, a hostname is usually a single word: for instance, an organization's CVS server might be named "cvs" or "server-1". On the Internet, a hostname is a domain name assigned to the host. This is usually a combination of the host's local name with its parent domain's name. For example, "en.wikipedia.org" consists of a host label ("en") and the domain name label "wikipedia.org". This kind of hostname (also known as an FQDN) is translated into an Internet address via the local hosts file, or the Domain Name System (DNS) resolver. It is possible for a single host to have several hostnames; but generally the OS of the host prefers to have one hostname that the host uses for itself. It is often possible to guess a hostname for a particular institution. This is useful if you want to know if they operate network services like anonymous FTP, World-Wide Web or finger. First try the institution's name or obvious abbreviations thereof, with the appropriate domain appended, e.g. "mit.edu". If this fails, prepend "ftp." or "www." as appropriate, e.g. "www.data-io.com". You can use the ping command as a quick way to test whether a hostname is valid. The folklore interest of hostnames stems from the creativity and humour they often display. Interpreting a sitename is not unlike interpreting a vanity licence plate; one has to mentally unpack it, allowing for mono-case and length restrictions and the lack of whitespace. Hacker tradition deprecates dull, institutional-sounding names in favour of punchy, humorous, and clever coinages (except that it is considered appropriate for the official public gateway machine of an organisation to bear the organisation's name or acronym). Mythological references, cartoon characters, animal names, and allusions to SF or fantasy literature are probably the most popular sources for sitenames (in roughly descending order). The obligatory comment is Harris' Lament: "All the good ones are taken!"

See also


- URL

External links


- [http://www.articlesandtools.com/host.php IP Address to/from Hostname] Convert between an IP address and a Hostname. ja:ホスト名 Category:Computer networks Category:Domain Name System

DNS

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