Short for canonical name, also referred to as a CNAME record, a record in a DNS database that indicates the true, or canonical, host name of a computer that its aliases are associated with. A computer hosting a Web sitemust have an IP address in order to be connected to the World Wide Web. The DNS resolves the computer??s domain name to its IP address, but sometimes more than one domain name resolves to the same IP address, and this is where the CNAME is useful. A machine can have an unlimited number of CNAME aliases, but a separate CNAME record must be in the database for each alias.
Usage Note: While CNAME is short for canonical name, use of the abbreviated term implies that one is referring to the canonical name record, not simply the canonical name.
CNAME |
----------------------------------------------------------------------------------------------------------
CNAME record
From Wikipedia, the free encyclopedia
A CNAME record or Canonical Name record is a type of resource record in the Domain Name System (DNS) that specifies that the domain name is an alias of another, canonical domain name. This helps when running multiple services (like an FTP server and a webserver; each running on different ports) from a single IP address. Each service can then have its own entry in DNS (like ftp.example.com. and www.example.com.).
Contents[hide] |
[edit]Details
CNAME records are specified in RFC 1034. CNAME records are handled specially in the domain name system, and have several restrictions on their use. When a DNS resolverencounters a CNAME record while looking for a regular resource record, it will restart the query using the canonical name instead of the original name. (If the resolver is specifically told to look for CNAME records, the CNAME alias 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, if there is a DNS zone as follows:
NAME TYPE VALUE -------------------------------------------------- foo.example.com. CNAME bar.example.com. bar.example.com. A 192.0.2.23
When an A record lookup for foo.example.com is done, the resolver will see a CNAME record and restart the checking at bar.example.com and will then return 192.0.2.23.
[edit]Which is the "CNAME"?
RFC 2181, "Clarifications to the DNS Specification", includes a warning on the use of the word "CNAME". "The CNAME" or "a CNAME" is often used to refer to the label, or left-hand part, of a CNAME record. However, as "CNAME" is an abbreviation of "canonical name", this usage is inaccurate; the label is an alias for the right-hand side (the RDATA portion), whichis (or should be) a canonical name.[1] In other words, a CNAME record like this:
foo.example.com. CNAME bar.example.com.
may be read as:
- foo.example.com is an alias for the canonical name (CNAME) bar.example.com.
The canonical name itself must be defined by a record other than a CNAME or DNAME record.
[edit]Restrictions
- An alias defined in a CNAME record must have no other resource records of other types (MX, A, etc.). (RFC 1034 section 3.6.2, RFC 1912 section 2.4) The exception is whenDNSSEC 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[2]. It is possible, then, to create unresolvable loops with CNAME records, as in:
foo.example.com. CNAME bar.example.com. bar.example.com. CNAME foo.example.com.
- Other DNS record types, such as NS, MX, PTR, SRV, etc. that point to other names should never point to a CNAME alias.[2][3] So, for example, a zone should not contain constructs such as:
example.com. MX 0 foo.example.com. foo.example.com. CNAME host.example.com. host.example.com. A 192.0.2.1
- Domains that are used for e-mail may not have a CNAME record[4]. In practice this may work, but can have different behavior with different mail servers, and can have undesired effects.[5]
[edit]DNAME record
A DNAME record or Delegation Name record is defined by RFC 2672. A DNAME record creates an alias for one or more subdomains of a domain. In contrast, the CNAME record creates an alias only of a single name (and not its subdomains). Like the CNAME record, the DNS lookup will continue by retrying the lookup with the new name. If a DNS resolver sends a query without EDNS, or with EDNS version 0, then a name server synthesizes a CNAME record to simulate the semantics of the DNAME record.
For example, if there is a DNS zone as follows:
foo.example.com. DNAME bar.example.com. bar.example.com. A 192.0.2.23 xyzzy.bar.example.com. A 192.0.2.24 *.bar.example.com A 192.0.2.25
An A record lookup for foo.example.com will fail because a DNAME is not a CNAME.
However, a look up 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 failed.
Lastly, a request for bar.foo.example.com would be DNAME mapped and return 192.0.2.25.
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
What is MX record? - A Word Definition From the Webopedia ...
tifies the mail server that is responsible for handling e-mails for thatdomain name.
When more than one MX record is entered for any single domain name that is using more than one mail server, the MX record can be prioritized with a preference number that indicates the order in which the mail servers should be used. This enables the use of primary and backup mail servers.
MX record |
A mail exchanger record (MX record) is a type of resource record in the Domain Name System that specifies a mail server responsible for accepting email messages on behalf of a recipient's domain, and a preference value used to prioritize mail delivery if multiple mail servers are available. The set of MX records of a domain name specifies how email should be routed with the Simple Mail Transfer Protocol.
Contents[hide] |
[edit]Overview
Resource records are the basic information elements of the Domain Name System (DNS). They are distinguished by a type identification (A, MX, NS, etc.) and a DNS class (Internet, CHAOS, etc.). The records have a validity period (time-to-live) assigned to them, indicating when the information they hold must be refreshed from an authoritative name server. Resource records are organized within the DNS based on their name field, which is a fully qualified domain name (FQDN) of a node in the DNS tree. In the case of an MX record, this specifies the domain name of a mail recipient's email address, i.e. the portion after the @ symbol that delimits the recipient's account name.
The characteristic payload information of an MX record is the fully qualified domain name of a mail host and a preference value. The host name must map directly to one or more address record (A, or AAAA) in the DNS, and must not point to any CNAME records.[1]
When an e-mail message is sent through the Internet, the sending mail transfer agent queries the Domain Name System for MX records of each recipient's domain name. This query returns a list of host names of mail exchange servers accepting incoming mail for that domain and their preferences. The sending agent then attempts to establish an SMTP connection to one of these servers, starting with the one with the smallest preference number, delivering the message to the first server with which a connection can be made. If no MX records were present, the server falls back to A, that is to say, it makes a request for the A record of the same domain.
The MX mechanism provides the ability to run multiple mail servers for a single domain, and allows administrators to specify an order in which they should be tried. This ability to run multiple mail servers proves very valuable for high-availability clusters of inexpensive mail gateways, which can then process hundreds of messages per second in aggregate to quarantine or remove spam and/or viruses.
The MX mechanism does not grant the ability to provide mail service on alternative port numbers, nor does it provide the ability to distribute mail delivery across a set of unequal-priority mail servers by assigning a weighting value to each one. MX can be used to distribute delivery across equal-priority mail servers.[2]
[edit]MX preference, distance, and priority
According to RFC 5321, the lowest-numbered records are the most preferred.[3] This phrasing can be confusing, and so the preference number is sometimes referred to as thedistance: smaller distances are more preferable. An older RFC, RFC 974, indicates that when the preference numbers are the same for two servers, they have the same priority, hence those two terms are used interchangeably.
[edit]The basics
The relative priority of an MX server is determined by the preference number present in the DNS MX record of the recipient's domain. When a remote client (typically another mail server) does an MX lookup for the domain name, it gets a list of servers and their preference numbers. The smallest preference number has the highest priority and any server with the smallest preference number must be tried first. To provide reliable mail transmission, the SMTP client must be able to try (and retry) each of the relevant addresses in this list in order, until a delivery attempt succeeds.[3] If there is more than one MX record with the same preference number, all of those must be tried before moving on to lower-priority entries.
[edit]Load distribution among an array of mail servers
One technique used to distribute the load of incoming mail over an array of servers is to return the same preference number for each server in the set. When determining which server of equal preference to send mail to, "the sender-SMTP MUST randomize them to spread the load across multiple mail exchangers for a specific organization", unless there is a clear reason to favor one.[3] Note that multihomed servers are treated differently, since in this case any randomization is assumed to have been applied already by the name server. This technique mainly addresses routing problems; other types of server load can be addressed by using an SMTP proxy.
The other alternative mentioned in the RFC is to use what appears to be a multihomed A record for a mail server. It may in fact be an array of mail servers that share the same host name. This method places the burden on the DNS system rather than the SMTP-sender to perform the load balancing, which in this case will present a list of IP addresses in a specific order to the clients querying the A record of the mail exchanger. Since the RFC requires that the SMTP-sender use the order given in the A record query, the DNS server is free to carefully manipulate its balancing based on any method, including round robin DNS, mail server load, or some undisclosed priority scheme.
[edit]The backup MX
A target server, i.e. one that knows how to deliver to the relevant user's e-mail mailbox is typically one which is the most preferred. Lower priority servers, a.k.a. backup MX or secondary MX, usually keep the messages in a queue waiting for the primary server to become available. If both servers are online or in some way connected to one another, the backup MX will typically queue a message briefly and immediately forward it to the primary MX. The backup MX acts as a store-and-forward mail server.
[edit]Why have priority?
A common misconception about the MX preference ordering is that it is intended to increase the likelihood that mail may be delivered; however, merely having multiple MX records with the same preference provides this benefit (see below). Because the MX preference ordering specifies that some servers should be tried first, it is, if anything, a means of establishing load imbalance. Another common misinterpretation of MX preference ordering is that it is intended to provide a means of "failover" in the case of server overload. While it can be used that way, it is a poor resource management technique because it intentionally creates overload and does not fully utilize the available hardware. Assigning the same preference value to all of the available servers provides the same benefit and may even help avoid overload situations and thereby increase system throughput by decreasing latency.
The SMTP protocol establishes a store-and-forward network, and if a domain's mail servers are all offline, sending servers are required to queue messages destined for that domain to retry later. However, these sending servers have no way of being notified that a previously offline domain's servers are now available. The sending servers will only discover that the domain is available whenever delivery of the delayed messages is next attempted. The delay between when a domain's servers come online and when delayed messages are finally delivered can be anywhere from minutes to days, depending on the retry schedule of the sending servers. This is the problem that backup MX records are uniquely qualified to solve. The idea is that the servers listed as secondary MX servers have some out-of-band way of knowing when the primary servers are back online. Thus, they are a more useful place to queue messages when the primary servers are offline than the original sender's queue.
The question then becomes: if the secondary servers are still online, why not give them the same priority as the rest of the domain's MX records? Secondary servers are ones that, for whatever reason, cannot or should not be used normally, but that can be used if the primary servers are offline. Reasons for them to not be used normally can vary widely, but here are some examples:
- the backup server is owned by a different company or organization
- the backup server does not have direct access to the primary mail storage
- the backup server cannot determine valid recipient addresses
- the backup server's Internet bandwidth costs more
- the backup server has significantly less Internet bandwidth
- the backup server has a high-latency Internet connection
[edit]Spammers
A favorite technique of spammers is to connect to the backup (high distance) MX servers for a domain first in order to avoid any anti-spam filters that may be running on the primary (lowest distance/highest preference) MX. Backup MX servers often have different anti-spam techniques, and using them can hide the spammer's IP address from the primary MX servers. This can be foiled by using bogus high-distance MX servers.
Alternatively, sometimes spammers only target the lowest-distance MX records for domains, and do not fall back to higher-distance MX records when the lowest-distance MX records are unreachable. A technique called nolisting will defeat this behavior.
[edit]The preference debate
The SMTP RFC[3] is ambiguous about exactly what kinds of delivery failure must result in re-attempting delivery via more distant MX records (those with higher preference values).
For example, sometimes servers indicate temporary failures, either by explicitly sending a 4xx error or by ending the connection unexpectedly (which must be treated as a 451 error, according to Section 3.8 of the RFC). If there is a temporary failure, should a more distant MX record be attempted, or should the server wait and retry later? According to Section 4.5.4.1:
No comments:
Post a Comment