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 ...
From RFC 1034 - Domain names - concepts and facilities:
Of course, by the robustness principle, domain software should not fail
when presented with CNAME chains or loops; CNAME chains should be followed
and CNAME loops signalled as an error.
So yes, it is allowed and properly written software will handle it just OK. CNAME chains aren't however considered ...
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.
So you are not looking at redirection as such (as that happens at the app level, i.e. on Apache/Nginx/wherever) but rather on the DNS resolution. The host on which DomainA is hosted will or should never be hit, based on your description as you want the DNS requests to be resolved to the IPs of DomainB. Unless I'm missing something in your request?
As Shane ...
No you don't because DNS records don't propagate. What you do need to allow for is for any cached records to expire, based on the TTL of the record in question.
If this is a new record, no caching can have occurred so the new record should be available and should resolve immediately.
Additionally, the root servers (first level; .) don't host DNS zones or ...
Sure, it is possible.
It is generally discouraged though, for the obvious reason that it uses more DNS resources.
foo IN CNAME someserver.somehost.com.
bar IN CNAME foo
Querying 'bar' would result in CNAME foo being queried, then someserver.somehost.com. being queried, resulting in one extra query.
For every element in the ...
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 ...
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
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, ...
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 ...
Route 53 DNS record changes propagate in less than a minute, but TTL times will impact on how quickly DNS resolvers check back for updated records.
Q. How quickly will changes I make to my DNS settings on Amazon Route 53 propagate globally?
Amazon Route 53 is designed to propagate updates you make to your DNS records to its world-wide network of ...
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 ...
You use the name the service is accessed as. So if your portal clients visit https://portal.dlinkddns.com, use portal.dlinkddns.com. And if they visit https://portal.company.com, use portal.company.com.
If your clients will access both, get a certificate with one of the names as DN and the other as subjectAltName, so it can be used for both.
If I'm reading ...
host, dig, and nslookup all share most of the same functionality. In the case you are asking about (asking a particular DNS question to a particular nameserver), dig and host (and indeed nslookup) behave exactly the same.
For DNS troubleshooting, dig is preferred because its output format is more "raw": in its output it directly shows the contents of all 4 ...
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.
From RFC 2821 "Simple Mail Transfer Protocol", section 5 "Address Resolution and Mail Handling":
The lookup first attempts to locate an MX record associated with the
name. If a CNAME record is found instead, the resulting name is
processed as if it were the initial name.
In general, this is how CNAMEs work. They are often mis-used, mis-understood, ...
The wildcard (the *) must be the leftmost part of the domain. So you can't do stage.*.example.com.
If you need to do wildcard DNS for this, I suggest using *.stage.example.com. This may require some minor changes to your deployment processes, but should not be significant.
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.
Well it's not that the root of a domain can't be a CNAME - It's that a CNAME cannot coexist with other record types for the same domain.
Simply put, it would make no sense for a domain with a CNAME to have any other record type, because the CNAME would ensure that they would never be seen or read.
Let's say we did try to give example.net both a CNAME (...
The more specific DNS record overrides the wildcard. So your CNAME should override your wildcard A. What this might be is that you still have the domain name cached to the a record. Use the dig command:
dig @yourdnsserver mydomain.freshdesk.com
Normally it should return the CNAME.
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.
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 126.96.36.199
api.myurl.com. A 300 188.8.131.52
app.myurl.com. A 300 184.108.40.206
preview.myurl.com. A 300 220.127.116.11
www.myurl.com. CNAME 300 myurl.com.
This is generally a good idea, as you point out you only have to change the IP in one place now.
The client would look-up test1, get pointed to default, then get the IP. It would then connect to Apache and tell Apache that it wants the test1 site (it does not tell the server how it found the server, just what the original request is).
OK, this was asked some time ago, and there is already an accepted answer...
CNAME'ing your root is generally a bad idea,
You must not use a CNAME for your root example.com domain.
users complain the website is down [..] because they are typing example.com instead of www.example.com
There is a simple solution:
Point example.com at the IP address (A ...
CNAME'ing your root is generally a bad idea, as all of the other records on the root (SOA, NS, MX) tend to be pretty important.
Your provider should really be allowing you to point to an address instead of a name. I appreciate what they're trying to do, giving themselves more flexibility to mess with that DNS entry as needed, but in this case it's ...
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 ...