CNAME
records were originally created to allow multiple names that provide the same resource to be aliased to a single "canonical name" for the resource. With the advent of name based virtual hosting, it has instead become commonplace to use them as a generic form of IP address aliasing. Unfortunately, most people who come from a web hosting background expect CNAME
records to indicate equivalence in the DNS, which has never been the intent. The apex contains record types which are clearly not used in the identification of a canonical host resource (NS
, SOA
), which cannot be aliased without breaking the standard at a fundamental level. (particularly in regards to zone cuts)
Unfortunately, the original DNS standard was written before the standards governing bodies realized that explicit verbiage was necessary to define consistent behavior (RFC 2119). It was necessary to create RFC 2181 to clarify several corner cases due to vague wording, and the updated verbiage makes it clearer that a CNAME
cannot be used to achieve apex aliasing without breaking the standard.
6.1. Zone authority
The authoritative servers for a zone are enumerated in the NS records
for the origin of the zone, which, along with a Start of Authority
(SOA) record are the mandatory records in every zone. Such a server
is authoritative for all resource records in a zone that are not in
another zone. The NS records that indicate a zone cut are the
property of the child zone created, as are any other records for the
origin of that child zone, or any sub-domains of it. A server for a
zone should not return authoritative answers for queries related to
names in another zone, which includes the NS, and perhaps A, records
at a zone cut, unless it also happens to be a server for the other
zone.
This establishes that SOA
and NS
records are mandatory, but it says nothing about A
or other types appearing here. It may seem superfluous that I quote this then, but it will become more relevant in a moment.
RFC 1034 was somewhat vague about the problems that can arise when a CNAME
exists alongside other record types. RFC 2181 removes the ambiguity and explicitly states the record types that are allowed to exist alongside them:
10.1. CNAME resource records
The DNS CNAME ("canonical name") record exists to provide the
canonical name associated with an alias name. There may be only one
such canonical name for any one alias. That name should generally be
a name that exists elsewhere in the DNS, though there are some rare
applications for aliases with the accompanying canonical name
undefined in the DNS. An alias name (label of a CNAME record) may,
if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
other data. That is, for any label in the DNS (any domain name)
exactly one of the following is true:
- one CNAME record exists, optionally accompanied by SIG, NXT, and
KEY RRs,
- one or more records exist, none being CNAME records,
- the name exists, but has no associated RRs of any type,
- the name does not exist at all.
"alias name" in this context is referring to the left hand side of the CNAME
record. The bulleted list makes it explicitly clear that a SOA
, NS
, and A
records cannot be seen at a node where a CNAME
also appears. When we combine this with section 6.1, it is impossible for a CNAME
to exist at the apex as it would have to live alongside mandatory SOA
and NS
records.
(This seems to do the job, but if someone has a shorter path to proof please give a crack at it.)
Update:
It seems that the more recent confusion is coming from Cloudflare's recent decision to allow an illegal CNAME record to be defined at the apex of domains, for which they will synthesize A records. "RFC compliant" as described by the linked article refers to the fact that the records synthesized by Cloudflare will play nicely with DNS. This does not change the fact that it is a completely custom behavior.
In my opinion this is a disservice to the larger DNS community: it is not in fact a CNAME record, and it misleads people into believing that other software is deficient for not allowing it. (as my question demonstrates)
CNAMES are not redirections, they are aliases. CNAME also includes all other resource records such as A,MX,TXT.
so if you query for an A record, the cname will send you to the A record of it's alias.
Many registrars include additional options such as redirect services, godaddy and Google for example.
also, be careful entering values for CNAMES, some systems assume terminating periods, others do not.
assuming domain example.com
test IN CNAME example.org
results in test resolves to the IP of host example.org.example.com which does not exist.
test IN CNAME example.org.
results in test resolves to the IP of host example.org which does exist.
CNAME values can only be HOSTS, not a URL.
dig A keep.richardyang.ca @8.8.8.8
keep.richardyang.ca. 299 IN CNAME https://keep.google.com/.
Change it to
keep.richardyang.ca. 299 IN CNAME keep.google.com.
Maybe check out https://stackoverflow.com/questions/10115799/set-up-dns-based-url-forwarding-in-amazon-route53
Example on how to use Synthetic records with Google.com Domains.
;; ANSWER SECTION:
keep.jacobdevans.com. 3600 IN CNAME ghs.googlehosted.com.
ghs.googlehosted.com. 163 IN A 173.194.207.121
This sends my request to google's servers, google then sends a 302 code to the new url, I've chosen 302, you would want 301 if you want SEO to know this is a permanent change, I may want to switch my destinations at a later time as I use this for my signature links to ensure my contact info stays current.
OR, since you already have a website, point the domain there and redirect the site.
Script:
<script type="text/javascript">
if (window.location.href== "http://keep.richardyang.ca") {
window.location.href = 'http://keep.google.com';
}
</script>
DNS:
keep.richardyang.ca. 299 IN CNAME richardyang.ca.
Best Answer
What is important to recognize here is that a
TXT
record can be multi-valued, with the record data containing one or more strings, each up to 255 characters long.Ie, one
TXT
record with multiple values and multipleTXT
records with one value each are not the same thing and should not be expected to be interpreted the same.What you showed initially is not actually a
TXT
record that has a single string with each value in " marks and separated by a space but rather aTXT
record which has three separate string values that do not contain any quotation marks or spaces.This understanding is particularly important as one of the things you tried to do in your attempts of solving the problem involved escaping these characters that are used for formatting purposes but are not actually part of the value.
For any software that understands and uses the DNS master file format (standard text representation of DNS records), what you included initially
... TXT "txtvers=1" "proto=https" "path=/acs/resources/configurations"
would be understood and interpreted as oneTXT
record with three separate string values (txtvers=1
,proto=https
,path=/acs/resources/configurations
).If your service provider has an interface that does not accept this form of input and they provide no other means of inputting multiple values (the answer you received from them suggests that may well be the case) there may be no way of entering the desired record into their system.
If that is indeed the case, you may have to look at hosting this record elsewhere (including options such as not moving your full zone but having the desired
TXT
record in a different zone hosted elsewhere and only adding aCNAME
pointing there, provided the software in question does not somehow disagree with this).That said, in specialized uses of
TXT
as part of other standards, it's more common (with widespread examples such as SPF and DKIM) to define the use of multiple string values in aTXT
record purely as a means of allowing long values and defining that all of the string values should simply be concatenated before further interpretation, instead using some internal delimiter (typically;
) for multi-value content inside that single, potentially long, string.It is very possible that your service provider has looked specifically at the very common "long value" scenario and supports that in one way or another (particularly likely because of DKIM).
Either way, if the design of the software that consumes these records is at all up to you, it may be a better idea to simply conform to the norm in this regard and use the same approach to storing multi-valued content as is used in these widespread
TXT
specializations instead. (However, such a change would obviously impact compatibility with existing records if this system is already in use).