Talk:CNAME record

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Low-importance).

Internet Low‑importance

	Internet portal This article is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet
Low	This article has been rated as Low-importance on the project's importance scale.

DNAME

The description of DNAME is unfortunately completely wrong.

DNAME only redirects subdomains.

Moreover the standard does not currently allow a CNAME and DNAME to be defined for the same node. —Preceding unsigned comment added by 92.238.99.235 (talk) 20:37, 10 June 2010 (UTC)[reply]

The DNAME example suggests the principle stated above, when it says that an A-lookup for foo fails. That contradicts the assertion in the main paragraph, which says that a "DNAME maps a domain and it's subdomains". Change that to simple "subdomains", and it's accurate. I am about to make that change, after seeing the confirmation above. (I am not adding the part about CNAME and DNAME not allowed for the same node, although possibly I should.) 75.41.52.94 (talk) 17:48, 5 November 2010 (UTC)[reply]

The best use of DNAME that never was:

ip6.int.   IN   DNAME   ip6.arpa.

- 71.106.211.51 (talk) 02:44, 16 November 2011 (UTC)[reply]

CNAME wording nit, details section

Suggest changing the wording: "CNAME must have no other resource records of other types" to something like "a node with a CNAME record must have no other resource records". Current wording makes it sound as if the CNAME record itself could have a record, or as if a node could have more than one CNAME record, neither of which is the case, AFAIK. Chconnor (talk) 02:27, 14 November 2010 (UTC)[reply]

I agree; the sentence in confusing. As someone trying to learn DNS better, this sentence makes me ask "What does 'have' mean? ...reference? ...be used in?". And my wording nit: if "other" is really needed twice, change one to "different".
Would it be correct to say "An alias defined by a CNAME record should not be used in resource records of other types (SOA, NS, MX, A, etc)."? Pbyhistorian (talk) 18:45, 23 October 2011 (UTC)[reply]

Wording issue...

Suggest changing...

The canonical name itself must be defined by a record other than a CNAME or DNAME record.

To...

The canonical name itself must be defined by another record.

—Preceding unsigned comment added by 174.114.248.239 (talk) 20:28, 11 March 2011 (UTC)[reply]

It's a while since I've looked at this, but my recollection is that the other record cannot be a CNAME or DNAME, so doesn't that need to be mentioned? I take the point that in a big-picture sense, the proposed wording is correct and simpler (which is good), but perhaps needs the qualification. Johnuniq (talk) 22:43, 11 March 2011 (UTC)[reply]

obligation contradiction

The expression "The canonical name itself must be defined by a record other than..." is likely understood as forbidding using a CNAME record with a canonical name. If the subsequent clarification "CNAME records that point to other CNAME records ... are not an error" is correct, I suggest altering the first statement from "must be" to "is usually". — Preceding unsigned comment added by 83.251.187.111 (talk) 16:26, 11 May 2012 (UTC)[reply]

Conflicting A and CNAME records — precedence?

Consider the following DNS setup:

www.example.com.      IN      A       192.0.43.10
  *.example.com.      IN      CNAME   www.google.com

The first line signifies that www.example.com shall point to IP address 192.0.43.10, the IP address of the IANA example HTTP server.
The second line signifies that any subdomain in example.com, including the www subdomain, shall point to www.google.com.

What is considered the default behavior now? Shall a client (e.g. a web browser) go to the IANA example HTTP server or the www.google.com HTTP server? --Abdull (talk) 00:26, 19 July 2012 (UTC)[reply]

This is a good question. I can't believe this Talk page has not been visited by an expert in five years! David Spector (talk) 13:20, 24 October 2017 (UTC)[reply]

From RFC 1912 [ https://tools.ietf.org/html/rfc1912 ]:

2.4 CNAME records

A CNAME record is not allowed to coexist with any other data. In other words, if suzy.podunk.xx is an alias for sue.podunk.xx, you can't also have an MX record for suzy.podunk.edu, or an A record, or even a TXT record.

-Guy Macon (talk) 03:04, 25 October 2017 (UTC)[reply]

CNAMEs using identifiers as alias URIs

In the authoritative DNS zones for my websites, my hosting company has frequently used identifiers as alias URIs.

Here are some examples:

springtimesoftware.com. A 64.131.68.211
www CNAME springtimesoftware.com.
ftp CNAME springtimesoftware.com.

In a browser, the URL springtimesoftware.com. is directly translated to IP address 64.131.68.211, but the first CNAME record makes this also true for URL www.springtimesoftware.com. Using FTP, a hostname ftp.springtimesoftware.com will also be translated to 64.131.68.211.

So the record "www CNAME springtimesoftware.com." appears to be treated exactly like "www.springtimesoftware.com. CNAME springtimesoftware.com.".

This article (and other articles on the Web) fail to describe this case of using an identifier (such as www or ftp) as the alias name in a CNAME record.

Can anyone explain this omission? Am I missing something obvious? Should the article be edited? David Spector (talk) 13:19, 24 October 2017 (UTC)[reply]

Wrong?

https://en.wikipedia.org/w/index.php?title=CNAME_record&diff=958680491&oldid=955870235 - not so? 50.201.195.170 (talk) 22:16, 8 June 2020 (UTC)[reply]

https://tools.ietf.org/id/draft-fujiwara-dnsop-additional-answers-00.html was an Internet-Draft that expired in 2018. You need a better source for WP. Vincent Lefèvre (talk) 22:33, 8 June 2020 (UTC)[reply]

Is there a good source for the claim, "a DNS client requires at least two queries"? I highly doubt it. I don't see that https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/ does so, besides, it has expired as well.--50.201.195.170 (talk) 07:43, 20 June 2020 (UTC)[reply]

Obviously two queries are needed. The first query asks for the IP of a host name, but the reply is that the given name is actually an alias, and the canonical name (CNAME) is something else. The second query is to find the IP of the something else. You are making the point that a polite DNS server will return the second reply in an additional record in the first reply. That is, the server (probably) anticipates that the second query will be needed and so provides the answer meaning that only physical query will be issued by the client. I doubt if a DNS server is compelled to provide such an additional record (is there an RfC saying it MUST?). Some better wording is needed but it's years since I contemplated these details. Johnuniq (talk) 09:41, 20 June 2020 (UTC)[reply]

Maybe the wording in the article ("a DNS client requires at least two queries") is a slight misinterpretation of the motivation for ANAME (bearing in mind that I have no knowledge of this other than a 30-second scan of the two references). With CNAME, two DNS queries are always required. In the case of the polite DNS server I mentioned above, the client makes one query which the server resolves to a CNAME, but then the server has to make an additional query to get the IP of the canonical name. It that is on another system, a significant overhead may be involved. That makes one client query plus one extra server query. Also, ANAME seems to be motivated by resolving a domain name like example.com (which in traditional DNS should not have an IP but which the web usually provides), as opposed to a host name like www.example.com. Johnuniq (talk) 23:41, 20 June 2020 (UTC)[reply]

Revdel?

The article revision history seems wrong. Am I imagining that https://en.wikipedia.org/w/index.php?title=CNAME_record&diff=958680491&oldid=955870235 was reverted? --50.201.195.170 (talk) 07:49, 20 June 2020 (UTC)[reply]

I don't understand the problem. {{fact}} was added and the current article still has that, and it is displaying ^{[citation needed]}. Johnuniq (talk) 09:32, 20 June 2020 (UTC)[reply]

Domains, CNAME and SMTP

The article say "Domains that are used in the SMTP MAIL and RCPT commands may not have a CNAME record". This is a bit ambiguous since domains can contain CNAME records without it affecting SMTP at all.

A better wording could be "Domains that are used in the SMTP MAIL and RCPT commands may not be a CNAME record". Here the word "have" have been changed to "be" to indicate that the very record itself cannot be a CNAME record. Hildingsson (talk) 08:29, 19 September 2023 (UTC)[reply]

It's a long time since I thought about this topic but my understanding is that the current wording is correct. If I email someone@example.com then the email server that I use (for example, my ISP's server) will find the MX record for the domain example.com and example.com may not have a CNAME record. See the example in MX record. Johnuniq (talk) 09:00, 19 September 2023 (UTC)[reply]