Simply put:
I have a domain called erik.com, two azure websites (east and west), and one traffic manager that is setup to manage the two azure websites.
When I take east offline (by throwing a non-2** status code) erik.com goes offline. This should not be the case! Right?
However, when I add a sub domain to the two azure websites (www.erik.com) then it works! I take one or the other offline and the traffic manager resolves to the available website.
I'm hearing/reading things that tell me that Traffic manager doesn't work with root domains like that... Say what?! Why?
As explained in the FAQs at https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-how-traffic-manager-works/#faq , Traffic Manager does not support 'naked' / apex domain names.
*Can I use Traffic Manager with a ‘naked’ (www-less) domain name?
Not currently.
The DNS CNAME record type is used to create a mapping from one DNS name to another name. As explained in the Traffic Manager example, Traffic Manager requires a DNS CNAME record to map the vanity DNS name (e.g. www.contoso.com) to the Traffic Manager profile DNS name (e.g. contoso.trafficmanager.net). In addition the Traffic Manager profile itself returns a second DNS CNAME to indicate which endpoint the client should connect to.
The DNS standards do not permit CNAMEs to co-exist with other DNS records of the same type. Since the apex (or root) of a DNS zone always contains two pre-existing DNS records (the SOA and the authoritative NS records), this means a CNAME record cannot be created at the zone apex without violating the DNS standards.
To work around this issue, we recommend that services using a naked (www-less) domain that want to use Traffic Manager should use an HTTP re-direct to direct traffic from the naked domain to a different URL, which can then use Traffic Manager. For example, the naked domain ‘contoso.com’ can re-direct users to ‘www.contoso.com’ which can then use Traffic Manager.
Full support for naked domains in Traffic Manager is tracked in our feature backlog. If you are interested in this feature please register your support by voting for it on our community feedback site.*
Related
I currently have 3 traffic managers, 1 entry point for our domain, which does geolocation routing to 2 other traffic managers. One global, one for the US.
These traffic managers are priority traffic managers which point to application gateways. By having the priority traffic managers, it allow us to have a 'failover' if one site / application gateway goes down.
The reason we have a application gateway in the different countries is to allow path manipulation so if the user is from the US, they get a /us path instead of a /.
I have configured our CNAMES like www. and blog. in the application gateways for both, global and US which works fine. I can point the CNAME records to the entry traffic manager no problem.
The problem I have having is pointing the A record root domain to the traffic manager. Since traffic managers don't have IP addresses, I get an error because in Azure, the root domain can be pointed at a traffic manager, but only one that uses external endpoints using a IP Address.
Has anyone else ran into this issue and have a way to solve it?
Thanks
Adding a root/apex domain to Azure Traffic Manager should be possible as it is integrated with Azure DNS. So, you should be able to create A record to ATM as shown below from Azure DNS,
I'm having issue configuring my DNS to make all traffic routed from the root domain (no www) to the Azure front door. The below is what I have done so far:
Create the front door (frontend/backend/routing)
On-Board my custom domain (let's say hello.com) on front door
Now as per Microsoft guide I have to add a CNAME record to the DNS hosting provider (domain.com) to route the traffic to front door. But I have been told by domain.com that I cannot have A record and CNAME record named #
So I've found this solution https://learn.microsoft.com/en-gb/azure/frontdoor/front-door-how-to-onboard-apex-domain
Then I have created a DNS Zone on my Azure environment named "hello.com" and followed the guide.
Still I cannot see the traffic going through the front door.
Is that because I have 2 DNS servers? (one hosted on domain.com and another one on Azure)?
Can It be propagation time ?
Also how does azure know that I'm the owner of hello.com domain ?
As the linking document, to onboard a root or apex domain on your Front Door, you could use alias records in Azure DNS.
There are other DNS providers as well that support CNAME flattening or
DNS chasing, however, Azure Front Door recommends using Azure DNS for
its customers for hosting their domains.
If you select to use Azure DNS to host DNS domains, first you need to create an Azure DNS zone (hello.com) in Azure and delegate the domain to Azure DNS via changing the name server records for the domain in your original DNS registrar. You can verify the delegation by using a tool such as nslookup to query the Start of Authority (SOA) record for your zone. It can take up to 72 hours to propagate worldwide, although it typically takes a few hours.
Then, you can add an alias record for the zone apex in the DNS configuration for the domain to be onboarded. After this, you can add the apex domain name in the custom host name field on the Front Door designer tab.
To access your backend web app with the custom domain, ensure that you have created appropriate routing rules for your apex domain or added the domain to existing routing rules. Or, you may enable HTTPS on your custom domain.
Hi I have too webapps in 2 different regions
webapp1.azurewebsites.net
webapp2.azurewebsites.net
webapp1.azurewebsites.net has a custom domain name (www.myrealdomainname.com) associated with it and is mapped via A Record on my providers dns record.
I have also added a cname record to webapp1.azurewebsites.net like this - www.myrealdomainname.com to mywebapp.trafficmanager.net
My question is when I visit www.myrealdomainname.com it doesnt go through traffic manager. Why is this? The dashboard on the portal shows nothing.
Also if I disable webapp1.azurewebsites.net leaving only webapp2.azurewebsites.net, and visit www.myrealdomainname.com it shows me content from webapp1.azurewebsites.net - again it doesnt go through traffic manager.
Is this because of the A record?
That is most likely the case. I do not understand why you have some DNS records pointing directly at one of the apps anyway if you are using Traffic Manager. Just point all records to Traffic Manager and configure it to distribute your traffic as you need.
Here is a link to the documentation: https://azure.microsoft.com/en-us/documentation/articles/web-sites-traffic-manager-custom-domain-name/
A quote from there: "When your website is configured as a Traffic Manager endpoint, you will use the .trafficmanager.net address when creating DNS records. You can only use CNAME records with Traffic Manager"
I am working with a company, developing and managing a web site for them.
I have control over the web servers, but the company is managing DNS for the domain.
Due to their security policy, the web servers are prohibited from issuing outbound email - they won't add the appropriate SPF/DKIM records to DNS to permit this. Instead, I've been told that they will "delegate" the authority of the domain to me by forwarding traffic to nameservers (of my choice), where I am responsible for creating new DNS records to handle that traffic. In these new DNS records, I would add in the appropriate SPF/DKIM records.
It is like I am managing the DNS, but the company still owns it.
The problem is very strange to me, and I am not familiar with the inner workings of nameservers. Is the relationship of a zone file to a domain name one-to-one? Would I need a second zone file registered somewhere to hold these new DNS records? Do I need direct control over the nameservers, or can I work with nameservers provided by a third-party hosting company?
Sorry for the lack of direction - this is new territory for me in a world that I'm already not that well-versed in.
Thanks in advance
The delegation is a DNS server owning a zone (ie. example.com) and announcing to everyone that a part of this zone (say deleg.example.com) is delegated to another DNS server which can define its own records as long as they are in the deleg.example.com zone.
In your case, it means that you will maintain a subdomain that will hold your NS and SPF/DKIM records. This subdomain behaves in a similar way as the main domain thus you will need a second DNS zone file (and another DNS server).
This is similar to what root servers do with top level domains (they own the com / net / whatever zones) and subdomains sold to companies / people (ie. google.com handles whatever lies in the google.com zone but does not affect the "com" zone).
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.