Domain Name System part 2

Contents

* 4 Protocol details
* 5 DNS resource records
o 5.1 Wildcard DNS records
* 6 Protocol extensions
* 7 Dynamic zone updates
* 8 Internationalized domain names
* 9 Security issues
* 10 Domain name registration
* 11 Abuse and regulation
o 11.1 Truth in Domain Names Act
* 12 Internet standards
o 12.1 Security

Protocol details

DNS primarily uses User Datagram Protocol (UDP) on port number 53 to serve requests. DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. The Transmission Control Protocol (TCP) is used when the response data size exceeds 512 bytes, or for tasks such as zone transfers. Some operating systems, such as HP-UX, are known to have resolver implementations that use TCP for all queries, even when UDP would suffice.

DNS resource records

A Resource Record (RR) is the basic data element in the domain name system. Each record has a type (A, MX, etc.), an expiration time limit, a class, and some type-specific data. Resource records of the same type define a resource record set. The order of resource records in a set, returned by a resolver to an application, is undefined, but often servers implement round-robin ordering to achieve load balancing. DNSSEC, however, works on complete resource record sets in a canonical order.

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

TYPE is the record type. It indicates the format of the data and it gives a hint of its intended use. For example, the A record is used to translate from a domain name to an IPv4 address, the NS record lists which name servers can answer lookups on a DNS zone, and the MX record specifies the mail server used to handle mail for a domain specified in an e-mail address (see also List of DNS record types).

RDATA is data of type-specific relevance, such as the IP address for address records, or the priority and hostname for MX records. Well known record types may use label compression in the RDATA field, but "unknown" record types must not (RFC 3597).

The CLASS of a record is set to IN (for Internet) for common DNS records involving Internet hostnames, servers, or IP addresses. In addition, the classes CH (Chaos) and HS (Hesiod) exist. Each class is a completely independent tree with potentially different delegations of DNS zones.

In addition to resource records defined in a zone file, the domain name system also defines several request types that are used only in communication with other DNS nodes (on the wire), such as when performing zone transfers (AXFR/IXFR) or for EDNS (OPT).

Wildcard DNS records

The domain name system supports wildcard domain names which are names that start with the asterisk label, '*', e.g., *.example. DNS records belonging to wildcard domain names specify rules for generating resource records within a single DNS zone by substituting whole labels with matching components of the query name, including any specified descendants. For example, in the DNS zone x.example, the following configuration specifies that all subdomains (including subdomains of subdomains) of x.example use the mail exchanger a.x.example. The records for a.x.example are needed to specify the mail exchanger. As this has the result of excluding this domain name and its subdomains from the wildcard matches, all subdomains of a.x.example must be defined in a separate wildcard statement.

X.EXAMPLE. MX 10 A.X.EXAMPLE.
*.X.EXAMPLE. MX 10 A.X.EXAMPLE.
*.A.X.EXAMPLE. MX 10 A.X.EXAMPLE.
A.X.EXAMPLE. MX 10 A.X.EXAMPLE.
A.X.EXAMPLE. AAAA 2001:db8::1

The role of wildcard records was refined in RFC 4592, because the original definition in RFC 1034 was incomplete and resulted in misinterpretations by implementers.

Protocol extensions

The original DNS protocol had limited provisions for extension with new features. In 1999, Paul Vixie published in RFC 2671 an extension mechanism, called Extension mechanisms for DNS (EDNS) that introduced optional protocol elements without increasing overhead when not in use. This was accomplished through the OPT pseudo-resource record that only exists in wire transmissions of the protocol, but not in any zone files. Initial extensions were also suggested (EDNS0), such as increasing the DNS message size in UDP datagrams.

Dynamic zone updates

Dynamic DNS updates use the UPDATE DNS opcode to add or remove resource records dynamically from a zone data base maintained on an authoritative DNS server. The feature is described in RFC 2136. This facility is useful to register network clients into the DNS when they boot or become otherwise available on the network. Since a booting client may be assigned a different IP address each time from a DHCP server, it is not possible to provide static DNS assignments for such clients.


Internationalized domain names


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

Security issues

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

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

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

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

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

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

Domain name registration

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

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

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

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

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

Some domain name registries, often called network information centers (NIC), also function as registrars to end-users. The major generic top-level domain registries, such as for the COM, NET, ORG, INFO domains and others, use a registry-registrar model consisting of hundreds of domain name registrars (see lists at ICANN or VeriSign). In this method of management, the registry only manages the domain name database and the relationship with the registrars. The registrants (users of a domain name) are customers of the registrar, in some cases through additional layers of resellers.

In the process of registering a domain name and maintaining authority over the new name space created, registrars use several key pieces of information connected with a domain:

* Administrative contact. A registrant usually designates an administrative contact to manage the domain name. The administrative contact usually has the highest level of control over a domain. Management functions delegated to the administrative contacts may include management of all business information, such as name of record, postal address, and contact information of the official registrant of the domain and the obligation to conform to the requirements of the domain registry in order to retain the right to use a domain name. Furthermore the administrative contact installs additional contact information for technical and billing functions.
* Technical contact. The technical contact manages the name servers of a domain name. The functions of a technical contact include assuring conformance of the configurations of the domain name with the requirements of the domain registry, maintaining the domain zone records, and providing continuous functionality of the name servers (that leads to the accessibility of the domain name).
* Billing contact. The party responsible for receiving billing invoices from the domain name registrar and paying applicable fees.
* Name servers. Most registrars provide two or more name servers as part of the registration service. However, a registrant may specify its own authoritative name servers to host a domain's resource records. The registrar's policies govern the number of servers and the type of server information required. Some providers require a hostname and the corresponding IP address or just the hostname, which must be resolvable either in the new domain, or exist elsewhere. Based on traditional requirements (RFC 1034), typically a minimum of two servers is required.

Abuse and regulation

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

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

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

Additionally, there are numerous accusations of domain name "front running", whereby registrars, when given whois queries, automatically register the domain name for themselves. Recently, Network Solutions has been accused of this.[17]
[edit] Truth in Domain Names Act
Main article: Truth in Domain Names Act

In the United States, the Truth in Domain Names Act of 2003, in combination with the PROTECT Act of 2003, forbids the use of a misleading domain name with the intention of attracting people into visiting Internet pornography sites.

Internet standards

The Domain Name System is defined by Request for Comments (RFC) documents published by the Internet Engineering Task Force (Internet standards). The following is a list of RFCs that define the DNS protocol.

* RFC 920, Domain Requirements - Specified original top-level domains
* 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
* RFC 1101, DNS Encodings of Network Names and Other Types
* RFC 1123, Requirements for Internet Hosts—Application and Support
* RFC 1178, Choosing a Name for Your Computer (FYI 5)
* RFC 1183, New DNS RR Definitions
* RFC 1591, Domain Name System Structure and Delegation (Informational)
* 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 2100, The Naming of Hosts (Informational)
* RFC 2136, Dynamic Updates in the domain name system (DNS UPDATE)
* RFC 2181, Clarifications to the DNS Specification
* RFC 2182, Selection and Operation of Secondary DNS Servers
* RFC 2308, Negative Caching of DNS Queries (DNS NCACHE)
* RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
* RFC 2671, Extension Mechanisms for DNS (EDNS0)
* RFC 2672, Non-Terminal DNS Name Redirection
* RFC 2845, Secret Key Transaction Authentication for DNS (TSIG)
* RFC 3225, Indicating Resolver Support of DNSSEC
* RFC 3226, DNSSEC and IPv6 A6 aware server/resolver message size requirements
* RFC 3597, Handling of Unknown DNS Resource Record (RR) Types
* RFC 3696, Application Techniques for Checking and Transformation of Names (Informational)
* RFC 4343, Domain Name System (DNS) Case Insensitivity Clarification
* RFC 4592, The Role of Wildcards in the Domain Name System
* RFC 4635, HMAC SHA TSIG Algorithm Identifiers
* RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance (Informational)
* RFC 5001, DNS Name Server Identifier (NSID) Option
* RFC 5395, Domain Name System (DNS) IANA Considerations (BCP 42)
* RFC 5452, Measures for Making DNS More Resilient against Forged Answers'
* RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)


Security

* RFC 4033, DNS Security Introduction and Requirements
* RFC 4034, Resource Records for the DNS Security Extensions
* RFC 4035, Protocol Modifications for the DNS Security Extensions
* RFC 4509, Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records
* RFC 4470, Minimally Covering NSEC Records and DNSSEC On-line Signing
* RFC 5011, Automated Updates of DNS Security (DNSSEC) Trust Anchors
* RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
* RFC 5702, Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC