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 ...
Multiple CNAME records for the same fully-qualified domain name is a violation of the specs for DNS. Some versions of BIND would allow you to do this (some only if you specified the multiple-cnames yes option) and would round-robin load-balance between then but it's not technically legal.
There are not supposed to be resource records (RRs) with the same ...
The certificate name must match what the user entered in the browser, not the 'final' DNS record. If the user enters docs.tenantcompany.com then your SSL certificate has to cover that.
If docs.tenantcompany.com is a CNAME to foo.example.com, the certificate does not need to cover foo.example.com, just docs.tenantcompany.com.
You can't. As RFC1034 says in s3.6.2,
If a CNAME RR is present at a node, no other data should be
If you want a TXT record for (say) www.example.com, you can't have a CNAME for www.example.com, and will have to find another way to achieve what you want. This may mean monitoring example.herokuapp.com yourself, and when the IP address changes, ...
Jason's answer is correct. But just to clarify terms a bit here, "DNS redirect" is a bit of a misnomer. DNS has CNAME records (a.k.a. aliases) which is a name pointing to another name. But it's not a redirect. The translation from name to name to IP all happens in the background and your browser only cares about the initial name.
The only thing that does ...
In the past S3 supported FQDN bucket names - i.e. exactly what you needed. Where FQDN = Fully Qualified Domain Name, i.e. full host name like static.mypage.com. The problem is that this only works with HTTP and not with HTTPS because there is no way to make S3 use a SSL certificate with your bucket name / host name (static.mypage.com).
You can still do it if ...
It would definitely create a problem if you were to point your MX records at CNAME records since it is against the standards. The clearest explanation is provided by RFC2181 §10.3:
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
I think you're confusing terms a little bit. A CNAME is not a redirect per se. It's just a record type in DNS, also known as a DNS alias. The DNS protocol is ultimately about mapping names to IP addresses. The most common record type is a "A" record which is a one-way mapping of Name to IP. The CNAME record instead is a one way mapping of Name1 to Name2.
Is this kind of multi level CNAME a bad design in general ?
CNAME to CNAME chains are not forbidden but as you already experience it is not a very robust solution.
Each additional CNAME increases the recursion depth for the resolver, and that depth is not always unlimited. Also you run the risk of creating loops, or triggering the loop detection ...
You cannot. A CNAME makes one record another name for another. If a record could have CNAMES for two names, it wouldn't be another name for either of them, but a name for something entirely new, making a CNAME entry inappropriate.
There's likely a good way to solve your outer problem though. For example, you can have multiple A records.
If I'm not mistaken, the problem is that your registrar has published DS records for your domain - that is, DNSSEC signing keys:
[me@risby player]$ dig ds ultreyatours.com
;; ANSWER SECTION:
ultreyatours.com. 85920 IN DS 49864 8 1 0152C1213569799FAFA42C7699A20132A293F908
ultreyatours.com. 85920 IN DS 20536 8 1 ...
Using Google's public DNS servers, the expiration of the A record causes a query of the CNAME record as well, even if the CNAME has a longer TTL.
We painfully experienced that because the DNS provider charged us for DNS queries. The CNAME hosted by the DNS provider had a TTL of several days. The TTL of the A record was hosted on Windows Azure with a TTL of ...
The Wikipedia article you are quoting reports what the relevant RFC 2782 for SRV records states:
The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181).
What you are seeing is a clear violation of the rules; however, it might work (and ...
HBrujin is correct, but in truth recursion depth is a lot worse than anything dig +trace is going to show you. Recursion depth is something that often gets sneered at and over-trivialized, but those people forget that you aren't just resolving ~5 CNAME records. This is because resolving the target of a CNAME record creates a need to look up every nameserver ...
As mentioned in the comments, you will need to use A records instead of CNAME records. CNAME records will not be able to point at an IP Address.
The key to making each of the sites to work is to specify ServerName correctly for each virtual server in your Apache config.
Barring unusual behavior from a web-browser or poorly coded application, there's nothing special about the www domain. I would suggest looking for a new DNS provider if they're willing to change DNS records without your approval or your knowledge.
There is a trick you can use here. That said, Wesley is a smart dude and you should listen to him. I don't get paid to say that but I'm hoping to change that one day.
Assuming that you're trying to change a record called www in a zone called example.com....
Create a temporary wildcard A record (*) in the zone. Commit the change. Test it, make sure the ...
Use A record to point to the sub domains
myurl.com. A 300 220.127.116.11
api.myurl.com. A 300 18.104.22.168
app.myurl.com. A 300 22.214.171.124
preview.myurl.com. A 300 126.96.36.199
www.myurl.com. CNAME 300 myurl.com.
CAA records are supposed to follow CNAMEs, so you need a CAA record for the target of the CNAME record instead.
CAA validation follows CNAMEs, like all other DNS requests. If www.community.example.com is a CNAME to web1.example.net, the CA will first request CAA records for www.community.example.com, then seeing ...
As others have stated, it's not possible to perform HTTP redirection with DNS alone. DNS and HTTP work together to redirect a user from one web page to another.
You can use DNS by itself to make domain A show the same content as domain B, but the web browser will show domain A in the URL. You need to be very careful with this as it's quite bad from an SEO ...
You cannot have a CNAME for the domain.
CNAMEs can only exist as single records and not combined with any other resource records. Since a domain always has a SOA and NS record, you cannot use a CNAME for the domain. This is specified in RFC 1034, section 3.6.2.
The reason that email specifically breaks is found in RFC 5321, section 5.1:
That domain ...
I wanted to understand if I my tenant company has a wildcard SSL certificate, will it work with this setup or a new SSL certificate has to be purchased for docs.tenantcompany.com?
Short answer: No. If your tenant company has a wildcard in the name *.tenantcompany.com, that is sufficient to install on your server to cover accesses via that name. Whether you ...
The standards discourage such a solution.
It probably works with most DNS software, but your clients might encounter some which is not willing to follow multiple CNAMEs in succession. In that case, those clients using such a DNS resolver will likely not be able to access your service using those domain names.
Domain names in RRs which point ...
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 ...
If you have the domain company.com (for example) and you want the certificate's Common Name to "just work", then consider using a wildcard-based Common Name like this: *.company.com
Then the SSL certificate should work for https://company.com and https://www.company.com and whatever subdomains you choose to use.
Note: I have used this only in self-signed ...
You can't use a CNAME record at the zone apex. This is because a CNAME record defines one name to be an alias of another regardless the requested record type.
This, in turn, also means that a CNAME record cannot coexist with other records as that would be a conflict/inconsistency.
The zone apex always has at least SOA and NS records, which means there can ...
You can add the following to your configuration file in dnsmasq:
as specified in the man page:
Return a CNAME record which indicates that <cname> is really <target>. There are significant ...
Your first record ("blank"/apex/root) can, but probably shouldn't, be a cname; see
How to overcome root domain CNAME restrictions? on Stack Overflow:
This is often attempted by inexperienced administrators as an obvious way to allow your domain name to also be a host. However, DNS servers like BIND will see the CNAME and refuse to add any other resources ...
You misunderstand the nature of RFCs. Anyone is perfectly free to violate them, but unpredictable behaviour may result. You are seeing a perfect example of that: when you ask for NS records for the domain from a .com server, you get one answer (a pair of records), but when you do it through normal recursion, you get a different result (SERVFAIL).