In order to register a reverse DNS entry for a Web App, you need to have a forward DNS entry pointing to an IP Address within the same subscription.
This is simply to prove that you have some authority over the domain.
If you need to create the reverse DNS entry at the same time as creating the Web App, then you will need to register a temporary IP Address in Azure for the Web App creation process to look up and verify your ownership of the domain.
In this case you would run something like this
$ip = New-AzureRmPublicIpAddress -Name TestIP1 `
-ResourceGroupName $ResourceGroupName `
-Location $location -AllocationMethod Static
Then to find the IP Address you have just registered run
$ip.address
On the other hand, if you have already deployed your Web App, you can simply ping it, or run (changing example
for the actual name of your app) (If the web app is already running, you don't need to register a temporary address)
(Resolve-DnsName example.azurewebsites.net).ip4address
Either way, you should get something like -
12.34.56.78
You can then register this address as an A record in DNS.
You can then register the reverse look up in Azure. For a template you can use
"properties": {
"publicIPAllocationMethod": "Dynamic",
"dnsSettings": {
"domainNameLabel": "[variables('PublicDNS2')]",
"ReverseFqdn": "[concat(parameters('vmName2'), '.', variables('domainname'))]"
}
In Powershell you would use
set-AzureRMWebApp -ResourceGroupName $AppServiceResourceGroupName
-Name $AppServiceWebAppName
-HostNames $reverseName
At that point you should have a reverse DNS entry configured.
If this is a new deployment, you would want to point the DNS entry that you pointed to the temporary IP address to the Web App you have just deployed. So again if you run
(Resolve-DnsName example.azurewebsites.net).ip4address
You can then register that IP Address in DNS and you will have a forward address working as well.
Finally, if you used one, delete the temporary address
Remove-AzureRmPublicIpAddress -Name TestIP1 `
-ResourceGroupName $ResourceGroupName -Force
I spoke with Azure support. You can, in fact, bind the same domain name to two different WebApps in this scenario, provided that:
- They are different regions
- You target them with TrafficManager endpoint first.
If you don't bind the custom domain to both WebApps, you will not be able to access your site after fail-over. The WebApp will refuse the traffic if the domain name is not bound.
This is what I was told and what ended up working:
Create Traffic Manager profiles and add both WebApps as end points. This will bind XXXX.trafficmanager.net
domains to each Web App.
WAIT for the domains to propagate through the Azure system and show up in the "Custom Domains" menu of the WebApps.
Go to bind a custom domain name as usual, but make sure you select the XXXX.trafficmanager.net
address as shown in the photo:
Best Answer
No, we can't work traffic manager in this way.
Traffic Manager works at the DNS level, it uses DNS responses to direct end-user traffic to globally distributed endpoints. Clients then connect to those endpoints directly. And traffic manager only supports Internet-facing applications. More information about traffic manager, refer to the link.