I have setup a wildcard A record so *.mydomain.com resolves to the fixed IP address of my reserved WAWS. I have also set up a few test a and cname records for various subdomains.
The guide here explicitly mentions wildcard a records:
A record
With an A record, you map a domain (e.g., contoso.com or
www.contoso.com) or a wildcard domain (e.g., *.contoso.com) to the
single public IP address of a deployment within a Windows Azure web
site.
The main benefit of this approach over using CNAMEs is that you can
map root domains (e.g., contoso.com) and wildcard domains (e.g.,
*.contoso.com), in addition to subdomains (e.g., www.contoso.com).
In the Azure portal, I am able to add various domains which get validated before being accepted. I can add the root mydomain.com plus any explicit a and c subdomains eg test.mydomain.com. Navigating to mydomain.com, www.mydomain.com and test.mydomain.com all work fine but if I try something.mydomain.com where I have not explicitly set this up, I get a 404.
something.mydomain.com resolves to the correct IP but just does not work. When using a wildcard a record, what do I need to configure in azure to get it working?
mydomain.com is already there but does not seem to allow just any subdomain
*.mydomain.com is not accepted
Even explicitly trying to add each required subdomain (eg something.mydomain.com) does not seem to work as the validation fails (unless I create a separate DNS record for each subdomain which defeats the purpose of the wildcard).
I am at a loss as to how to proceed. Given the mention of wildcard domains in the windowsazure.com article mentioned above, it seems as though they should be supported but in that same article, there is a comment stating that they are not supported and I certainly have not manage to get it working so far.
Any idea whether this is possible right now?
Wilcard domains aren't supported by WAWS currently. Its in the works for now.
To be honest, most documentation on Azure is out of date, for example the pages about CDN.
It's to bad that you can't rely on whats written.
I assume there's been no change to this wildcard matter since March?
Related
We are planning to use cloudfront distribution for our main domain and the setup will be as follows.
Cloudfront Origin - route.domain.com -> Remote Server IP address(xx.xx.xx.xx)
www.domain.com, domain.com -> d123.cloudfront.com
As we know, we can setup CNAME for www.domain.com to point to cloudfront distribution(d123.cloudfront.net). However, for domain.com we should point A record to IP address and its not possible to setup CNAME record.
In route53, there is an option called Alias which can be used to point the domain to Cloudfront. But, our domain.com nameserver uses different provider and we would like to stick with current nameserver.
Any help would be appreciated.
Since this is a limitation in DNS itself, there is no way to accomplish this without a DNS hosting provider that supports an alias-like feature, sometimes called an "ANAME" or "flattened CNAME". Route 53 is of course the canonical example. CloudFlare and DNS Made Easy are others.
Or use a service like this one¹ to redirect your naked domain name to the www address, which would be your "real" site. They give you a single IP address for your A record. Note that your current DNS provider may have a "redirection" option that does this. It is not properly a part of DNS, but some providers allow you to configure domain redirections in their DNS portal.
Or migrate your DNS hosting to Route 53, keeping your DNS registration with your current vendor. In my mind, there is really no compelling reason not to use Route 53. See Making Route 53 the DNS Service for a Domain That's in Use for migrating to Route 53 without disruption, noting that the final step -- Transfer Domain Registration to Amazon Route 53 -- is entirely optional, as mentioned in the docs.
¹ this one is not a service I am affiliated with or have ever used in production, because I built my own service for that purpose using EC2, which is another option but outside the scope of this answer. This is intended as an example, not an endorsement.
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!
I think I have just successfully connected my domain to my web host and have done so by following an article. There seems to be 2 different ways of doing so and I wonder if there is a difference between the two.
method 1
Go to your domain provider. Create an A record that points to your web host's ip address.
method 2
Go to your domain provider and edit the nameservers according to what your web host indicated. Go back to your web host and add a DNS record indicating the domain.
I have followed method 1 and it works. Is it any different from the second method? In addition, when typing out a record at the domain provider, what does #, www, and * mean?
The A record maps a name to one or more IP addresses, when the IP are known and stable.
# * are same as known as domain name (e.g. yourdomain.com) some domain registrar using # instead of entire domain and some uses *. In hosting control panel under DNS records there domainname is mentioned instead of # OR *
If you work with method 1 and changing A record then you will have to change A record to WWW as well to work your domain with www else your domain with www will ended up with no result. You will also have to change all required records such as CNAME (if you have any subdomain), mail (if it is working through hosting provider).
So best practice is to use namererver so you don't need to change every record under Domain Control Panel.
I managed to get my custom subdomain name assigned to my Azure website, following this (very carefully):
link to azure custom domain name instructions
Is it necessary to keep the "awverify" DNS records after the custom domain names linkage has been established?
I deleted the awverify DNS record for the test subdomain, and was able to add another subdomain pointer to my azurewebsites test site.
Maybe I did not wait long enough. Does anyone else have any experience with this, to say one way or the other?
Not sure if I understand the issue you are running into... but the CNAME entry with the 'awverify' subdomain is used to "prove" to Azure that you own that domain when you are wiring up a custom domain name. Once that is established, you no longer need that.
From the looks of it the new Azure Websites Feature still does not support hosting them under a naked domain such as example.com instead of www.example.com. Am I missing something?
Azure Websites have now released support for naked domains. Websites that are run on Shared or Reserved instances does support naked domains through an A record. Domain management is available through the Azure management portal.
Update 2012-10-21:
I previously stated that free instances could rely on CNAME to redirect a subdomain to their free Azure-website, but this appear to be incorrect, at least at the moment. Doing a CNAME to your Azure-website will result in an HTTP 404, as reported by MemeDeveloper in his comment.
However, if you run your website on a Free instance, you are still limited to CNAME, so for those websites naked domains are not possible.
Update:
As MemeDeveloper suggest in his comment, there are web services you can use that will take your naked-domain example.com and redirect it to www.example.com for you. For your www subdomain you could then have a CNAME to your Azure-URL.
Not as clean as a simple A record that is available for your paid websites, but a workaround for your free sites.
The conversations above are a bit dated. This entry however, comes up at the top of the list when folks are hunting/searching for Azure Naked Domain support.I'd update the answer.
Azure now supplies an IP in shared and > plans, and you can configure a naked domain.
Check out the following articles for more info:
https://azure.microsoft.com/en-us/documentation/articles/web-sites-custom-domain-name/
http://blogs.msdn.com/b/waws/archive/2014/10/01/mapping-a-naked-url-to-your-azure-web-site-url-with-no-www.aspx
Azure does not support naked domain, because this requires to map definitively an IP address to the domain name. To map a naked domain name, you need a 1 record in the DNS. So, in this case, services like load balancing are more difficult to put in place.
Most registrars provide a way to redirect a naked domain request to another name, through HTTP redirect mechanism. For instance, you could redirect example.com to www.example.com.
There seems to be some confusion about this. I don't know what the deal with Websites is, but normal Azure Web Roles provide a virtual IP address that is guaranteed not to change unless you delete a webrole deployment.
You can bind a domain name A-record to that VIP, as described here.
In practice, that means that when I want to update my website, I have to do a staging deployment first; and then switch it with the production deployment, and finally delete the staging deployment. The only caveat that I've been aware of, is that you can't do this if you switch your endpoint configuration (not even names).
I'm currently looking if there are same kinds of guarantees for websites, but haven't found appropriate documentation yet.