Currently it is not possible to add web apps from different subscriptions (e.g. EU and US deployment in different enterprise accounts) to the same traffic manager configuration, not even as external endpoint via Powershell.
This seems to be an artificial restriction as it prevents endpoints with "azurewebsites.net" in the domain name, but using a CNAME to change this domain name works (nasty work around).50 votes
We have added support for endpoints from multiple subscriptions in a single Traffic Manager profile. This is now possible when using the Azure Resource Manager API for Traffic Manager. The account containing the Traffic Manager profile must simply have read permissions for each endpoint.
Unfortunately, we were unable to extend this support to include Web App endpoints, due to a restriction in how custom domain names work in Web Apps. Please see https://docs.microsoft.com/azure/traffic-manager/traffic-manager-faqs#traffic-manager-endpoints for details.
Currently for many of the resources that we allocate on Azure (websites, cloud services, vms, storage, buses, etc ...) require unique names across Azure. We've taken to prefixing many of these with our company name, but this doesn't leave many characters for service differentiation. Often we want to have some combination of dev, test and prod instances of various resources. Much of the time we likely don't care to setup a full DNS environment for the non-prod instances. It would interesting to start to look at either subscriptions or resource groups as a potential place to add the notion of a subdomain for addressing purposes. E.g. it would be nice to just have web01.projectX.azureresources.com instead of contoso-prjx-web01.cloudapp.net
Currently for many of the resources that we allocate on Azure (websites, cloud services, vms, storage, buses, etc ...) require unique names across Azure. We've taken to prefixing many of these with our company name, but this doesn't leave many characters for service differentiation. Often we want to have some combination of dev, test and prod instances of various resources. Much of the time we likely don't care to setup a full DNS environment for the non-prod instances. It would interesting to start to look at either subscriptions or resource groups as a potential place to add the notion of…22 votes
We don’t think sub-domains is the right way to offer resource grouping. In Azure Resource Manager, resource groups should be used.
AWS has a detailed list of edge locations in addition to regions on their website. Can Azure have such list as well?3 votes
We are continually adding new POPs for Azure DNS. We monitor both global and regional performance and continually strive to improve. At times we may also remove a location if we feel newer locations are providing better service. For this reason, we do not encourage customers to take a dependency on the POP locations.
Other in-market solutions such as Akamai handle have Dynamic IP filtering to handle DDOS attacks as the first line of defensive for your site/app.
It would be great it TM supported this as well.3 votes
Traffic Manager works at the DNS level. It uses DNS to direct traffic to your service endpoints. Clients then connect to those endpoints directly. Thus Traffic Manager cannot provide IP-level features.
If you require IP level filtering, you might like to look at Azure Application Gateway.
At the moment only Standard Web Sites can use it.3 votes
Thank you for the suggestion.
Our usage scenarios for Traffic Manager with Websites are focused on high availability / high performance applications. As such, we took the business decision that this feature should be limited to ‘Standard’ tier Websites.
If I want to change an A record, which is being referenced by several CNAME records... I'd ideally like to just click a "Migrate to new A record" button... which would either let me pick an existing A record, or enter the name of a new A record... and then update all CNAMEs (within the zone) to use the target record.2 votes
This feels like a very specialized scenario. I don’t think we can justify supporting this in the Azure Portal.
Please note that it should be possible for you to implement this in a script, building on the Azure PowerShell cmdlets or cross-platform Azure CLI.
For different situations, at times, you may want a different DNS name for your service than the service name. In the old Portal you could do this. The new one automatically makes them the same. Requests this feature be added back.1 vote
The behaviour hasn’t changed—the DNS name and service name have always been the same
Poderia ter um gerenciamento de dns reverso! Acho que faz muita falta...1 vote
Azure DNS is a service, not a resource! So don't require using it in a context of a resource group!0 votes
Thank you for the feedback.
Azure Resource Manager is fundamental building block of all Azure services, providing a number of cross-platform benefits such as a shared authentication and authorization framework enabling role-based access control.
A resource group is a fundamental concept in Azure Resource Manager, and that’s why Azure DNS requires DNS zones to be placed in resource groups.
We would like to understand your concerns better to look for alternative solutions. Other than needing to create a resource group and specify the resource group name when creating a DNS zone, is there another issue? We would be interested in any specific feedback if using a resource group causes any specific scenarios not to work for you.
- Don't see your idea?