CNAME record

Last updated

A Canonical Name (CNAME) record is a type of resource record in the Domain Name System (DNS) that maps one domain name (an alias) to another (the canonical name). [1]

Contents

This can prove convenient when running multiple services (like an FTP server and a web server, each running on different ports) from a single IP address. One can, for example, use CNAME records to point ftp.example.com and www.example.com to the DNS entry for example.com, which in turn has an A record which points to the IP address. Then, if the IP address ever changes, one only has to record the change in one place within the network: in the DNS A record for example.com.

CNAME records must always point to another domain name, never directly to an IP address.

Details

DNS CNAME records are specified in RFC   1034 and clarified in Section 10 of RFC   2181.

CNAME records are handled specially in the domain name system and have several restrictions on their use. When a DNS resolver encounters a CNAME record while looking for a regular resource record, it will restart the query using the canonical name instead of the original name. However, if the resolver is specifically told to look for CNAME records, the canonical name (right-hand side) is returned, rather than restarting the query. The canonical name that a CNAME record points to can be anywhere in the DNS, whether local or on a remote server in a different DNS zone.

For example, consider a DNS zone as follows:

NAMETYPEVALUE--------------------------------------------------bar.example.com.CNAMEfoo.example.com.foo.example.com.A192.0.2.23

When an A record lookup for bar.example.com is carried out, the resolver will see a CNAME record and restart the lookup for foo.example.com and will then return 192.0.2.23.

Possible confusion

With a CNAME record, one can point a name such as "bar.example.com" to "foo.example.com". Because of this, during casual discussion, the "bar.example.com." (left-hand) side of a DNS entry can be incorrectly identified as "the CNAME" or "a CNAME". However, this is inaccurate. The canonical (true) name of "bar.example.com" is "foo.example.com". Because CNAME stands for Canonical Name, the right-hand side is the actual "CNAME"; on the same side as the address "A".

This confusion is specifically mentioned in RFC 2181, "Clarifications to the DNS Specification". The left-hand label is an alias for the right-hand side (the RDATA portion), which is (or should be) a canonical name. [2] In other words, consider the following CNAME record:

bar.example.com.CNAMEfoo.example.com.

This may be read as saying that "bar.example.com" is an alias for the canonical name (CNAME) "foo.example.com". A client will request "bar.example.com" and the answer will be "foo.example.com".

Restrictions

  • CNAME records must always be pointed to another domain name, never to an IP address.
  • If a CNAME record is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. (RFC 1034 section 3.6.2, RFC 1912 section 2.4) The exception is when DNSSEC is being used, in which case there can be DNSSEC related records such as RRSIG, NSEC, etc. (RFC 2181 section 10.1)
  • CNAME records that point to other CNAME records should be avoided due to their lack of efficiency, but are not an error. [3] It is possible, then, to create unresolvable loops with CNAME records, as in: 
    foo.example.com.CNAMEbar.example.com.bar.example.com.CNAMEfoo.example.com.
  • A CNAME record cannot be present at the zone apex. RFC 1034 section 4.2.1 [4] demands a SOA record at the zone apex and RFC 1034 section 3.6.2 [5] demands that are no other records be present if a CNAME record is present. Therefore a CNAME record cannot appear at the zone apex.
  • CNAME records that are served by DNAME records may cause recursive loops in older resolvers.[ clarification needed ]
  • MX and NS records must never point to a CNAME alias (RFC 2181 section 10.3). So, for example, a zone must not contain constructs such as: 
    example.com.MX0foo.example.com.foo.example.com.CNAMEhost.example.com.host.example.com.A192.0.2.1
  • Domains that are used in the SMTP MAIL and RCPT commands may not have a CNAME record. [6] In practice this may work, but can have different behavior with different mail servers, and can have undesired effects. [7]

DNAME record

A DNAME record or Delegation Name record is defined by RFC   6672 (original RFC 2672 is now obsolete). The DNAME record provides redirection (alias) for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. In contrast, the CNAME record creates an alias for a single name and not its subdomains. Like the CNAME record, the DNS lookup will continue by retrying the lookup with the new name. The name server synthesizes a CNAME record to actually apply the DNAME record to the requested name—CNAMEs for every node on a subtree have the same effect as a DNAME for the entire subtree.

For example, if there is a DNS zone as follows:

foo.example.com.DNAMEbar.example.com.bar.example.com.A192.0.2.23xyzzy.bar.example.com.A192.0.2.24*.bar.example.com.A192.0.2.25

An A record lookup for foo.example.com will return no data because a DNAME is not a CNAME and there is no A record directly at foo.

However, a lookup for xyzzy.foo.example.com will be DNAME mapped and return the A record for xyzzy.bar.example.com, which is 192.0.2.24; if the DNAME record had been a CNAME record, this request would have returned name not found.

Lastly, a request for foobar.foo.example.com would be DNAME mapped and return 192.0.2.25.

ANAME record

Several managed DNS platforms implement a non-standard ALIAS [8] or ANAME [9] record type. These pseudo records are managed by DNS administrators like CNAME records, but are published and resolved by (some) DNS clients like A records. ANAME records are typically configured to point to another domain, but when queried by a client, answer with an IP address. While ANAME record types were submitted for standardization, [10] there are other non-conforming implementations, so they can do whatever the owner of the DNS platform chooses, including existing at the apex of a zone and existing for domains that receive mail.

The main advantage of ANAME records over CNAME records is that they can be used on a zone apex, while a standards-following resolver will not treat domain names with CNAME records as a zone apex. [11] Also, while a DNS client requires at least two queries to resolve a CNAME to an A record to an IP address, an ANAME will shift the second and subsequent query to the server. If the DNS server can resolve the A record and cache the requested IP address more efficiently and with less latency than its DNS clients can, then the DNS client can resolve the query faster.

The ANAME record type was submitted as a draft standard to IETF. However, the latest draft document expired in January 2020 [10] and has been superseded by a series of proposals, the most recent of which is the one for the SVCB and HTTPS record types. [12]

See also

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed name service that provides a naming system for computers, services, and other resources on the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

A name server is a computer application that implements a network service for providing responses to queries against a directory service. It translates an often humanly meaningful, text-based identifier to a system-internal, often numeric identification or addressing component. This service is performed by the server in response to a service protocol request.

<span class="mw-page-title-main">Domain name</span> Identification string in the Internet

In the Internet, a domain name is a string that identifies a realm of administrative autonomy, authority or control. Domain names are often used to identify services provided through the Internet, such as websites, email services and more. Domain names are used in various networking contexts and for application-specific naming and addressing purposes. In general, a domain name identifies a network domain or an Internet Protocol (IP) resource, such as a personal computer used to access the Internet, or a server computer.

A mail exchanger record specifies the mail server responsible for accepting email messages on behalf of a domain name. It is a resource record in the Domain Name System (DNS). It is possible to configure several MX records, typically pointing to an array of mail servers for load balancing and redundancy.

<span class="mw-page-title-main">Root name server</span> Name server for the DNS root zone

A root name server is a name server for the root zone of the Domain Name System (DNS) of the Internet. It directly answers requests for records in the root zone and answers other requests by returning a list of the authoritative name servers for the appropriate top-level domain (TLD). The root name servers are a critical part of the Internet infrastructure because they are the first step in resolving human-readable host names into IP addresses that are used in communication between Internet hosts.

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

The Domain Name System Security Extensions (DNSSEC) is a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

A Service record is a specification of data in the Domain Name System defining the location, i.e., the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33. Some Internet protocols such as the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) often require SRV support by network elements.

In computer networking, a hostname is a label that is assigned to a device connected to a computer network and that is used to identify the device in various forms of electronic communication, such as the World Wide Web. Hostnames may be simple names consisting of a single word or phrase, or they may be structured. Each hostname usually has at least one numeric network address associated with it for routing packets for performance and other reasons.

In the Domain Name System (DNS) hierarchy, a subdomain is a domain that is a part of another (main) domain. For example, if a domain offered an online store as part of their website example.com, it might use the subdomain shop.example.com.

In computer networks, a reverse DNS lookup or reverse DNS resolution (rDNS) is the querying technique of the Domain Name System (DNS) to determine the domain name associated with an IP address – the reverse of the usual "forward" DNS lookup of an IP address from a domain name. The process of reverse resolving of an IP address uses PTR records. rDNS involves searching domain name registry and registrar tables. The reverse DNS database of the Internet is rooted in the .arpa top-level domain.

<span class="mw-page-title-main">DNS zone</span> Administrable unit of the Domain Name System

A DNS zone is a specific portion of the DNS namespace in the Domain Name System (DNS), which a specific organization or administrator manages. A DNS zone is an administrative space allowing more granular control of the DNS components, such as authoritative nameserver. The DNS is broken up into different zones, distinctly managed areas in the DNS namespace. DNS zones are not necessarily physically separated from one another; however, a DNS zone can contain multiple subdomains, and multiple zones can exist on the same server.

Multicast DNS (mDNS) is a computer networking protocol that resolves hostnames to IP addresses within small networks that do not include a local name server. It is a zero-configuration service, using essentially the same programming interfaces, packet formats and operating semantics as unicast Domain Name System (DNS). It was designed to work as either a stand-alone protocol or compatible with standard DNS servers. It uses IP multicast User Datagram Protocol (UDP) packets and is implemented by the Apple Bonjour and open-source Avahi software packages, included in most Linux distributions. Although the Windows 10 implementation was limited to discovering networked printers, subsequent releases resolved hostnames as well. mDNS can work in conjunction with DNS Service Discovery (DNS-SD), a companion zero-configuration networking technique specified separately in RFC 6763.

A Domain Name System (DNS) zone file is a text file that describes a DNS zone. A DNS zone is a subset, often a single domain, of the hierarchical domain name structure of the DNS. The zone file contains mappings between domain names and IP addresses and other resources, organized in the form of text representations of resource records (RR). A zone file may be either a DNS master file, authoritatively describing a zone, or it may be used to list the contents of a DNS cache.

This article presents a comparison of the features, platform support, and packaging of many independent implementations of Domain Name System (DNS) name server software.

DNS hijacking, DNS poisoning, or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries. This can be achieved by malware that overrides a computer's TCP/IP configuration to point at a rogue DNS server under the control of an attacker, or through modifying the behaviour of a trusted DNS server so that it does not comply with internet standards.

Blackhole DNS servers are Domain Name System (DNS) servers that return a "nonexistent address" answer to reverse DNS lookups for addresses reserved for private use.

Amazon Route 53 is a Domain Name System (DNS) service by Amazon Web Services (AWS) since 2010. The name is a possible reference to U.S. Routes, and "53" is a reference to the TCP/UDP port 53, where DNS server requests are addressed. Route 53 allows users to reach AWS services and non-AWS infrastructure and to monitor the health of their application and its endpoints. Route 53's servers are distributed throughout the world. Amazon Route 53 supports full, end-to-end DNS resolution over IPv6. Recursive DNS resolvers on IPv6 networks can use either IPv4 or IPv6 transport to send DNS queries to Amazon Route 53.

A start of authority record is a type of resource record in the Domain Name System (DNS) containing administrative information about the zone, especially regarding zone transfers. The SOA record format is specified in RFC 1035.

References

  1. ↑ Mockapetris, P. (November 1987). "RFC 1035 - Domain names - implementation and specification". Internet Engineering Task Force. Retrieved 16 March 2019.
  2. ↑ "RFC 2181: Clarifications to the DNS Specification". IETF. July 1997. Retrieved 2011-03-09.
  3. ↑ Mockapetris, P. (November 1987). "RFC 1034 - Domain names - concepts and facilities". Internet Engineering Task Force. Retrieved 15 July 2019.
  4. ↑ Mockapetris, P. (November 1987). "RFC 1034 section 4.2.1" . Retrieved 15 July 2019.
  5. ↑ Mockapetris, P. (November 1987). "RFC 1034 section 3.6.2" . Retrieved 15 July 2019.
  6. ↑ Braden, R. (October 1989). "RFC1123 - MAIL - SMTP & RFC-822" . Retrieved 23 July 2020.
  7. ↑ Bernstein, D. J. "CNAME records in mail" . Retrieved 3 June 2011.
  8. ↑ "ALIAS Records" . Retrieved 2019-07-26.
  9. ↑ "ANAME Records" . Retrieved 2022-09-24.
  10. 1 2 "Address-specific DNS aliases (ANAME)". 2019-07-08. Retrieved 2019-07-26.
  11. ↑ Goldlust, Suzanne; Almond, Cathy. "CNAME at the apex of a zone". ISC's Open Source Knowledgebase. Internet Systems Consortium. Retrieved 8 April 2023.
  12. ↑ Schwartz, B.; Bishop, M.; Nygren, E. (2023-03-11). "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)" . Retrieved 2023-04-08.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.