A reverse lookup is a query of the DNS for domain names when the IP address is known. Multiple domain names may be associated with an IP address. The DNS stores IP addresses in the form of domain names as specially formatted names in pointer (PTR) records within the infrastructure top-level domain "arpa. For IPv4, the domain is in-addr.arpa. For IPv6, the reverse lookup domain is ip6.arpa. The IP address is represented as a name in reverse-ordered octet representation for IPv4, and reverse-ordered nibble representation for IPv6.
When performing a reverse lookup, the DNS client converts the address into these formats before querying the name for a PTR record following the delegation chain as for any DNS query. For example, assuming the IPv4 address 184.108.40.206 is assigned to Wikimedia, it is represented as a DNS name in reverse order: 220.127.116.11.in-addr.arpa. When the DNS resolver gets a pointer (PTR) request, it begins by querying the root servers, which point to the servers of "American Registry for Internet Numbers (ARIN) for the 208.in-addr.arpa zone. ARIN's servers delegate 152.80.208.in-addr.arpa to Wikimedia to which the resolver sends another query for 18.104.22.168.in-addr.arpa, which results in an authoritative response.
Users generally do not communicate directly with a DNS resolver. Instead DNS resolution takes place transparently in applications such as "web browsers, "e-mail clients, and other Internet applications. When an application makes a request that requires a domain name lookup, such programs send a resolution request to the "DNS resolver in the local operating system, which in turn handles the communications required.
The DNS resolver will almost invariably have a cache (see above) containing recent lookups. If the cache can provide the answer to the request, the resolver will return the value in the cache to the program that made the request. If the cache does not contain the answer, the resolver will send the request to one or more designated DNS servers. In the case of most home users, the Internet service provider to which the machine connects will usually supply this DNS server: such a user will either have configured that server's address manually or allowed "DHCP to set it; however, where systems administrators have configured systems to use their own DNS servers, their DNS resolvers point to separately maintained name servers of the organization. In any event, the name server thus queried will follow the process outlined above, until it either successfully finds a result or does not. It then returns its results to the DNS resolver; assuming it has found a result, the resolver duly caches that result for future use, and hands the result back to the software which initiated the request.
Some large ISPs have configured their DNS servers to violate rules, such as by disobeying TTLs, or by indicating that a domain name does not exist just because one of its name servers does not respond.
Some applications, such as web browsers, maintain an internal DNS cache to avoid repeated lookups via the network. This practice can add extra difficulty when debugging DNS issues, as it obscures the history of such data. These caches typically use very short caching times – in the order of one minute.
"Internet Explorer represents a notable exception: versions up to IE 3.x cache DNS records for 24 hours by default. Internet Explorer 4.x and later versions (up to IE 8) decrease the default time out value to half an hour, which may be changed by modifying default configuration.
"Google Chrome triggers a specific error message for DNS issues. When the DNS server is down or broken, Google Chrome returns an error message.
The Domain Name System includes several other functions and features.
Hostnames and IP addresses are not required to match in a one-to-one relationship. Multiple hostnames may correspond to a single IP address, which is useful in "virtual hosting, in which many web sites are served from a single host. Alternatively, a single hostname may resolve to many IP addresses to facilitate "fault tolerance and "load distribution to multiple server instances across an enterprise or the global Internet.
DNS serves other purposes in addition to translating names to IP addresses. For instance, "mail transfer agents use DNS to find the best mail server to deliver "e-mail. The domain to mail exchanger mapping provided by "MX records may present an additional layer of fault tolerance and load distribution.
The DNS is used for efficient storage and distribution of IP addresses of blacklisted email hosts. A common method is to place the IP address of the subject host into the sub-domain of a higher level domain name, and to resolve that name to a record that indicates a positive or a negative indication.
- The address 22.214.171.124 is blacklisted. It points to 126.96.36.199.blacklist.example, which resolves to 127.0.0.1.
- The address 188.8.131.52 is not blacklisted and points to 184.108.40.206.blacklist.example. This hostname is either not configured, or resolves to 127.0.0.2.
E-mail servers can query blacklist.example to find out if a specific host connecting to them is in the blacklist. Many of such blacklists, either subscription-based or free of cost, are available for use by email administrators and anti-spam software.
The "Sender Policy Framework and "DomainKeys were designed to take advantage of another DNS record type, the "TXT record, but have since been assigned specific record types.
To provide resilience in the event of computer or network failure, multiple DNS servers are usually provided for coverage of each domain. At the top level of global DNS, thirteen groups of root name servers exist, with additional "copies" of them distributed worldwide via "anycast addressing.
"Dynamic DNS (DDNS) updates a DNS server with a client IP address on-the-fly, for example, when moving between ISPs or mobile "hot spots, or when the IP address changes administratively.
DNS message format
The DNS protocol uses two types of DNS messages, queries and replies, and they both have the same format. Each message consists of a header and four sections: question, answer, authority, and an additional space. A header field (flags) controls the content of these four sections.
The header section contains the following fields: Identification, Flags, Number of questions, Number of answers, Number of authority resource records (RRs), and Number of additional RRs. The identification field can be used to match responses with queries. The flag field consists of several sub-fields. The first is a single bit which indicates if the message is a query (0) or a reply (1). The second sub-field consists of four bits; if the value is 1, the present packet is a reply; if it is 2, the present packet is a status; if the value is 0, the present packet is a request. A single-bit sub-field indicates if the DNS server is authoritative for the queried hostname. Another single-bit sub-field indicates if the client wants to send a recursive query ("RD"). The next single-bit sub-field indicates if the replying DNS server supports recursion ("RA"), since not all DNS servers are configured to do this task. Another sub-field indicates if the request was truncated for some reason ("TC"), and a four-bit sub-field indicates status. The question section contains the domain name and type of record (A, AAAA, MX, TXT, etc.) being resolved. The domain name is broken into discrete labels which are concatenated; each label is prefixed by the length of that label. The answer section has the resource records of the queried name. A domain name may occur in multiple records if it has multiple IP addresses associated.
DNS primarily uses the "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 resolver implementations use TCP for all queries.
DNS resource records
The Domain Name System specifies a set of various "types of resource records (RRs), which are the basic information elements of the domain name system. Each record has a type (name and number), an expiration time ("time to live), a class, and type-specific data. Resource records of the same type are described as a resource record set (RRset). The order of resource records in a set, which is returned by a resolver to an application, is undefined, but often servers implement "round-robin ordering to achieve "load balancing. The "Domain Name System Security Extensions (DNSSEC), however, work on the complete set of resource record in canonical order.
When sent over an "Internet Protocol network, all records use the common format specified in RFC 1035:
|NAME||Name of the node to which this record pertains||Variable|
|TYPE||Type of RR in numeric form (e.g., 15 for MX RRs)||2|
|"TTL||Count of seconds that the RR stays valid (The maximum is 231−1, which is about 68 years)||4|
|RDLENGTH||Length of RDATA field||2|
|RDATA||Additional RR-specific data||Variable, as per RDLENGTH|
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. A free standing @ is used to denote the current origin.
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.
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 "Chaos (CH) and "Hesiod (HS) exist. Each class is an independent name space 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 DNS records which specify 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 following configuration, the DNS zone x.example specifies that all subdomains, including subdomains of subdomains, of x.example use the mail exchanger (MX) a.x.example. The A record for a.x.example is needed to specify the mail exchanger IP address. As this has the result of excluding this domain name and its subdomains from the wildcard matches, an additional MX record for the subdomain a.x.example, as well as a wildcarded MX record for all of its subdomains, must also be defined in the DNS zone.
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.
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 database 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.
Originally, security concerns were not major design considerations for DNS software or any software for deployment on the early Internet, as the network was not open for participation by the general public. However, the expansion of the Internet into the commercial sector in the 1990s changed the requirements for security measures to protect data integrity and user authentication.
Several vulnerability issues were discovered and exploited by malicious users. One such issue is "DNS cache poisoning, in which data is distributed to caching resolvers under the pretense of being an authoritative origin server, thereby polluting the data store with potentially false information and long expiration times (time-to-live). Subsequently, legitimate application requests may be redirected to network hosts operated with malicious intent.
DNS responses are traditionally not cryptographically signed, leading to many attack possibilities; the "Domain Name System Security Extensions (DNSSEC) modify DNS to add support for cryptographically signed responses. "DNSCurve has been proposed as an alternative to DNSSEC. Other extensions, such as "TSIG, add support for cryptographic authentication between trusted peers and are commonly used to authorize zone transfer or dynamic update operations.
Some domain names may be used to achieve spoofing effects. For example, paypal.com and paypa1.com are different names, yet users may be unable to distinguish them in a graphical user interface depending on the user's chosen "typeface. In many fonts the letter l and the numeral 1 look very similar or even identical. This problem is acute in systems that support "internationalized domain names, since many character codes in "ISO 10646 may appear identical on typical computer screens. This vulnerability is occasionally 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) or other organizations such as "OpenNIC, that are 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 operating the database of names within its authoritative zone, although the term is most often used for TLDs. A registrant is a person or organization who asked for domain registration. The registry receives registration information from each domain name registrar, which is authorized (accredited) to assign names in the corresponding zone and publishes the information using the "WHOIS protocol. As of 2015, usage of "RDAP is being considered.
ICANN publishes the complete list of TLDs, TLD registries, and domain name registrars. Registrant information associated with domain names is maintained in an online database accessible with the WHOIS service. For most of the more than 290 "country code top-level domains (ccTLDs), the domain registries maintain the WHOIS (Registrant, name servers, expiration dates, etc.) information. For instance, "DENIC, Germany NIC, holds the DE domain data. Since about 2001, most "Generic top-level domain (gTLD) registries have adopted this so-called thick registry approach, i.e. keeping the WHOIS data in central registries instead of registrar databases.
For COM and NET domain names, a thin registry model is used. The domain registry (e.g., "VeriSign) holds basic WHOIS data (i.e., 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 domains COM, NET, ORG, INFO, use a registry-registrar model consisting of many domain name registrars. 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.
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 1034, Domain Names - Concepts and Facilities
- RFC 1035, Domain Names - Implementation and Specification
- RFC 1123, Requirements for Internet Hosts—Application and Support
- 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 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 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 5001, DNS Name Server Identifier (NSID) Option
- RFC 5452, Measures for Making DNS More Resilient against Forged Answers
- RFC 5890, Internationalized Domain Names for Applications (IDNA):Definitions and Document Framework
- RFC 5891, Internationalized Domain Names in Applications (IDNA): Protocol
- RFC 5892, The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
- RFC 5893, Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
- RFC 7766, DNS Transport over TCP - Implementation Requirements
- 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
- RFC 5910, Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)
- RFC 5933, Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
- RFC 7858, Specification for DNS over Transport Layer Security (TLS)
- RFC 1183, New DNS RR Definitions
Best Current Practices
- RFC 2182, Selection and Operation of Secondary DNS Servers (BCP 16)
- RFC 2317, Classless IN-ADDR.ARPA delegation (BCP 20)
- RFC 5625, DNS Proxy Implementation Guidelines (BCP 152)
- RFC 6895, Domain Name System (DNS) IANA Considerations (BCP 42)
- RFC 7720, DNS Root Name Service Protocol and Deployment Requirements (BCP 40)
These RFCs are advisory in nature, but may provide useful information despite defining neither a standard or BCP. (RFC 1796)
- RFC 1178, Choosing a Name for Your Computer (FYI 5)
- RFC 1591, Domain Name System Structure and Delegation
- RFC 1912, Common DNS Operational and Configuration Errors
- RFC 2100, The Naming of Hosts
- RFC 3696, Application Techniques for Checking and Transformation of Names
- RFC 4892, Requirements for a Mechanism Identifying a Name Server Instance
- RFC 5894, Internationalized Domain Names for Applications (IDNA):Background, Explanation, and Rationale
- RFC 5895, Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
- RFC 7626, DNS Privacy Considerations
- RFC 7706, Decreasing Access Time to Root Servers by Running One on Loopback
These RFCs have an official status of "Unknown, but due to their age are not clearly labeled as such.
- RFC 920, Domain Requirements – Specified original top-level domains
- RFC 1032, Domain Administrators Guide
- RFC 1033, Domain Administrators Operations Guide
- RFC 1101, DNS Encodings of Network Names and Other Types
- RFC 1034, Domain Names - Concepts and Facilities, P. Mockapetris, The Internet Society (November 1987)
- RFC 781, Internet Protocol - DARPA Internet Program Protocol Specification, Information Sciences Institute, J. Postel (Ed.), The Internet Society (September 1981)
- RFC 1035, Domain Names - Implementation and Specification, P. Mockapetris, The Internet Society (November 1987)
- J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman, and B. Weihl. "Globally Distributed Content Delivery, IEEE Internet Computing, September/October 2002, pp. 50-58" (PDF).
- Nygren., E.; Sitaraman R. K.; Sun, J. (2010). "The Akamai Network: A Platform for High-Performance Internet Applications" (PDF). ACM SIGOPS Operating Systems Review. 44 (3): 2–19. "doi:10.1145/1842733.1842736. Retrieved November 19, 2012.
- Paul Mockapetris (November 1987). "SOA RDATA format". Domain Names - Implementation and Specification. "IETF. sec. 3.3.13. RFC 1035. https://tools.ietf.org/html/rfc1035#section-3.3.13. Retrieved 18 December 2015.
- Champika Wijayatunga (February 2015). "DNS Abuse Handling" (PDF). "APNIC. Retrieved 18 December 2015.
- RFC 3467, "Role of the Domain Name System (DNS)", J.C. Klensin, J. Klensin (February 2003).
- Liu, Cricket; Albitz, Paul (2006). DNS and BIND (5th ed.). O'Reilly Media. p. 3. "ISBN "978-0-596-10057-5.
- IEEE Annals [3B2-9] man2011030074.3d 29/7/011 11:54 Page 74
- Andrei Robachevsky (26 November 2013). "Happy 30th Birthday, DNS!". "Internet Society. Retrieved 18 December 2015.
- Elizabeth Feinler, IEEE Annals, 3B2-9 man2011030074.3d 29/7/011 11:54 Page 74
- Terry, Douglas B.; et al. (June 12–15, 1984). "The Berkeley Internet Name Domain Server". Summer Conference, Salt Lake City 1984: Proceedings. USENIX Association Software Tools Users Group. pp. 23–31.
- Internet Systems Consortium. "The Most Widely Used Name Server Software: BIND". History of BIND. Retrieved 28 July 2013.
- Paul Hoffman; Andrew Sullivan; Kazunori Fujiwara (December 2015). DNS Terminology. "IETF. RFC 7719. https://tools.ietf.org/html/rfc7719. Retrieved 18 December 2015.
- Paul Mockapetris (November 1987). "Name space specifications and terminology". Domain Names - Domain Concepts and Facilities. "IETF. sec. 3.1. RFC 1034. https://tools.ietf.org/html/rfc1034#section-3.1. Retrieved 17 December 2015.
- Paul Mockapetris (November 1987). "How the database is divided into zones". Domain Names - Domain Concepts and Facilities. "IETF. sec. 4.2. RFC 1034. https://tools.ietf.org/html/rfc1034#section-4.2. Retrieved 17 December 2015.
- Network Working Group of the IETF, January 2006, RFC 4343: Domain Name System (DNS) Case Insensitivity Clarification
- RFC 3696, Application Techniques for Checking and Transformation of Names, J. Klensin
- "Providers ignoring DNS TTL?". "Slashdot. 2005. Retrieved 2012-04-07.
- Ben Anderson (7 September 2011). "Ben Anderson: Why Web Browser DNS Caching Can Be A Bad Thing". Retrieved 20 October 2014.
- "How Internet Explorer uses the cache for DNS host entries". "Microsoft Corporation. 2004. Retrieved 2010-07-25.
- "Google Chrome DNS Errors". Appuals. 2015. Retrieved 2016-08-28.
- James F. Kurose and Keith W. Ross, Computer Networking: A Top-Down Approach, 6th ed. Essex, England: Pearson Educ. Limited, 2012
- RFC 5395, Domain Name System (DNS) IANA Considerations, D. Eastlake 3rd (November 2008), Section 3
- RFC 5395, Domain Name System (DNS) IANA Considerations, D. Eastlake 3rd (November 2008), p. 11
- RFC 4592, The Role of Wildcards in the Domain Name System, E. Lewis (July 2006)
- APWG. "Global Phishing Survey: Domain Name Use and Trends in 1H2010." 10/15/2010 apwg.org
- "Registration Data Access Protocol (RDAP) Operational Profile for gTLD Registries and Registrars". "ICANN. 3 December 2015. Retrieved 18 December 2015.
- "Find a Registrar". VeriSign, Inc. Retrieved 18 December 2015.
|""||Wikiversity has learning resources about Domain Name System|
- Vixie, Paul (2007-04-01). "DNS Complexity". "ACM Queue.
- Zytrax.com, Open Source Guide – DNS for Rocket Scientists.
- Internet Governance and the Domain Name System: Issues for Congress "Congressional Research Service
- Ball, James (28 February 2014). "Meet the seven people who hold the keys to worldwide internet security". "The Guardian. Guardian News & Media Limited. Retrieved 28 February 2014.