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).
Related
Let's say my domain is xyz.com
If
- I had an A record pointing to an IP address, say 193.10.23.1
- then I had a CNAME www points to blah.cloudfront.net
But of course blah.cloudfront.net is not pointing to 193.10.23.1, will dns look up return the A record or the CNAME record? Is there an order of precedence or whether CNAMES overrides the A record?
Thanks
DNS standards does not allow having both CNAME and A record:
https://www.rfc-editor.org/rfc/rfc1034#section-3.6.2
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.
DNS provider will usually will usually prevent you from adding conflicting records:
Cloudflare:
AWS Route53:
I own a domain "x.wiki" which is managed via domains.google
I have a website, which is split up into multiple endpoints using azure cdn.
sub1-x.azureedge.net - Subdomain 1 (intended site route with all content)
sub2-x.azureedge.net - Subdomain 2 (subdomain with limited
content)
sub3-x.azureedge.net - Subdomain 3 (subdomain with limited
content)
I want to serve these as follows.
www.x.wiki -> sub1-x.azureedge.net
x.wiki -> sub1-x.azureedge.net
sub2.x.wiki -> sub2-x.azureedge.net
sub3.x.wiki -> sub3-x.azureedge.net
currently it only works with www. / sub2. / sub3.
x.wiki doesnt resolve
Does anyone know how I can get this working correctly?
My understanding is that due to limitations with CNAME i cannot do this easily, however azureCDN to my knowledge does not give me an IP for use with custom domains.
Here is my DNS configuration.
You also use alias records to point your DNS zone apex x.wiki to Azure CDN endpoints. If your domain DNS provider does not support alias record for root domain, you could optionally to host your domain in Azure DNS.
In the Azure DNS zone, you could create an alias record like this,
Then, you will see one A record and one CNAME for your CDN endpoint.
After the records are verified, you could add the hostname x.wiki in the custom domain of your CDN endpoint.
Alternatively, you could try the workaround in this blog.
Set up a CNAME “cdnverify.” to
“cdnverify..azureedge.net”. Once all is verified and set up
(including SSL provisioning if desired), delete the CNAME and use
ANAME for the root record.
The answer to this is to redirect root to WWW from my DNS provider.
The cdnverify cname is not necessary.
https://www.tachyonstemplates.com/2018/google-domains-forward-root/
May re-open this if i still cant get adsense to resolve the root (because it is a redirect)
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!
most domain providers don’t allow setting a CNAME record for a main domain. It’s usually only possible to set CNAME records for subdomains.
So now I’m wondering if it would be possible to set an A record instead, pointing to scapp.io’s IP address. I tried it yesterday and it seems to work great but I’m worried that IP address might not be stable.
Any ideas whether setting an A record to 194.209.246.110 is a valid option for configuring a "naked" domain?
We don't recommend A record to IP address. The IP addresses may change without prior announcement.
See docs.developer.swisscom.com -> DNS for Domains for other options than CNAME.
Configuring DNS for Your Registered Root Domain
To use your root domain (for example, example.com) for apps on App
Cloud you can either use custom DNS record types like ALIAS and ANAME,
if your DNS provider offers them, or subdomain redirection.
Note: Root domains are also called zone apex domains.
If your DNS provider supports using an ALIAS or ANAME record,
configure your root domain with your DNS provider to point at a shared
domain in App Cloud.
What domain provider do you use?
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".