In Openshift you need to point (as it's recommended on Openshift) your domain to their CNAME records, like that:
mysite.com => cname: app-mynick.rhcloud.com
But according to DNS rules (as my domain registrator says) CNAME pointing applicable only for subdomains like this:
subdomain.mysite.com
So, how should I behave in this situation with my top level domain?
The problem is Openshift gives my app dynamic IP, so, somewhen it may be changed and my website wouldn't be accessible...
I have resolved the issue with CloudFlare CNAME Flattening.
Here is article - https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/ - that describes why you can't point root domain to CNAME record in your DNS, and how CNAME Flattening can solve my problem.
So now, I can "point top level (root) domain to Openshift app with CNAME".
Related
Hello I will get a access to a subdomain division.company.com and I will have to name where to point it in contract. I don't want request for contract update because where subdomain has point to every time I need to switch a server.
I am looking to have a top level DNS like control for a subdomain.
a) Do I use some kind of routing/proxy server?
b) Is there a way to have a dynamic DNS assignation (single time minimal configuration on the top level domain side)?
c) Is what I am looking for possible with DDNS providers like https://www.dynu.com/ ?
I tried using dynamic with a test domain but it did not seam to function properly.
On test domain I added CNAME DNS record b.a.com pointing to b.dynamicdns.com and then on dynamic DNS'es DNS records I pointed a CNAME record of www.b.dynamicdns.com to a website's server then on website server side I tried www.b.a.com but it did not seam to work.
Top level domains has to add NS (name server) records for the subdomain pointing to a DNS management provider
https://www.dynu.com/ has and add own domain where subdomain can be entered and configured but other providers should work too.
NS b.a.com NS1.provider.com
NS b.a.com NS2.provider.com
That will delegate subdomains DNS record management to it and will allow for full control of it. Including adding CNAME records pointing to any server.
I wish to setup Cloudflare so that both mydomain.com and www.mydomain.com will reach the same Elastic Beanstalk host.
I've created a CNAME for the "www" subdomain, it works great.
But how do I handle the mydomain.com DNS root entry? It's currently an A record, pointing to some IP, but in order to point to EB, I need to have a CNAME like "www", correct? If so, is it safe to somehow replace the A record with a CNAME despite the fact this is a root DNS entry rather than some subdomain..
thanks.
All you need to do is add a Page Rule
Match: mydomain.com/* and Redirect (301) to https://www.mydomain.com/$1
Or http if you’re not using SSL. The $1 means to copy the path from the original request.
Delete the A record from Cloudflare DNS Panel
Add a record with type CNAME and value as yourdomainname.com
This doesn't work on most DNS providers. However, Cloudflare has a feature called "CNAME flattening" that allows a CNAME Record to co-exist with other records at a domain's root. In practice, it doesn't act like a CNAME because when someone looks it up, Cloudflare resolves it internally, finds an A Record and returns the value. (This is how Alias A Records work on AWS Route 53, for example.)
I currently have a DNS setup where all content and applications are hosted on the same cloud server - example.com.
The presentation website is on example.com, www is forwarded to example.com with a CNAME and then various internal apps, eg app.example.com, are also forwarded with CNAME records to example.com. NGINX running on my server takes it from there, routing subdomains to the different apps.
I'd like to host the presentational website on an external service, and I'm confused about how to update my DNS config - specifically what to do with my A record.
I'm ok with creating a CNAME for www that will forward www.example.com to my external hosting service. But example.com is still pointing to my own server... and if I have understood correctly, if I forward example.com to www.example.com, then all my apps at eg app.example.com will break.
What are my options for handling this ?
My idea (from searching around) is that if I want example.com to point to an external service, then I should
1) create a new domain api-example.com whose A record points to a server where all my apps are hosted
2) make CNAME records for all my app subdomains on example.com which point to api-example.com
3) forward example.com to www.example.com, and forward www.example.com to the external service.
Will this configuration work ? Is there a simpler way to get the same result ?
Your plan is fine, except for maybe one thing: generally, you can't have a CNAME record for the root (apex) of your domain. This means that your external presentation website hosting will have to provide an IP address, and you will create an A record that will point example.com to that address. Then you can have a CNAME record simply aliasing www.example.com to example.com.
Also make sure that you leave enough time between the steps, to make sure that all DNS TTLs expired so you don't encounter DNS caching issues.
For explanation (and possible workarounds) for domain apex CNAMEing issue, look at https://stackoverflow.com/a/33027309/1145196
I have a meteor project deployed on Xervo here. I have a domain bought from GoDaddy, ustechland.com. I'm configuring custom domains in my project's administration panel on Xervo.
2
*.ustechland.com means all subdomains of this domain will point to this project. Now when I hit ustechland.com in the address bar, the URL changes to the project URL (https://utl-95476.app.xervo.io), which I don't want to happen.
I have configured CNAME records in my GoDaddy's domain DNS as specified by the Xervo Docs here.
Here is my list of CNAME DNS Records in GoDaddy:
4
Although, the Xervo custom domain docs specify to add two CNAME records, I'm able to add one CNAME record with www subdomain pointing to Joyent Servo in US-East. Another record with naked domain (#) must be added pointing to the same. But I'm not able to add this record as GoDaddy says the record already exists.
Now, is the URL changing because I'm not able to add the CNAME record required? Do try hitting ustechland.com or www.ustechland.com and see the URL change.
And at times, both these URL's take me to 'Future home of something quite cool' page.
I have found several sources that claim that godaddy does not support root cname flattening (which is what you want).
Check out these ideas for how to deal with this.
CNAME Flattening With GoDaddy.
Quora Answer
Good luck!
Probably simple question and I miss something trivial but...
Typical CDN incapsula setup is:
domain.com A record to incapsula IP
subdomain.domain.com CNAME record to incapsula.host
Why is A record used? Why don't use CNAME record for root domain also?
Because you cannot have a CNAME record for the root domain if you want to have other records under that same domain. This is not allowed by the DNS specification, specifically in RFC 1034 (http://www.faqs.org/rfcs/rfc1034.html)
If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different. This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.
If you had CNAME flattening then you "could" do it.
Whether CNAME record can be used for root domain is decided by the DNS service provider for that domain. It has nothing to do with the CDN provider for that domain.
CNAME to root domain is not standard DNS function, thus why many DNS service providers do not support it. That is also why root domain has to point to A record from CDN provider in some situation.
In other situation where DNS service provider does support CNAME to root domain, and you configure root domain to point to CNAME, you will still find a A record when dig it, this is called CNAME flattening.
Take my this site whatsmycdn.com for example, it is actually pointing to CDN CNAME, but you only see CDN virtual IP when digging it as a result of CNAME flattening:
dig whatsmycdn.com +short
110.232.178.193
Most DNS provider will not allow you to point root domain to other record then A record, the reason for that is that RFC rules prohibits that.
The best practice will be to point the root record as instructed by Incapsula and use their management console to point the root domain to the WWW one to avoid latency (The CNAME uses Geo-location).