IP address now not showing for any webapp that doesn't have a dedicated ip

Question

IP is blank (eg, Overview, Custom Domains). Because of this, we can't add any custom domains using an A record. We can use cname for www but the root domain requires an A record. It gives us the asuid but for the A record the text is blank. We obtained the IP with a ping but using it doesn't work because it doesn't match what Azure is looking for. This is happening with all our web apps that don't have a dedicated IP. What to do?

Answer 1

@Jamie Colpitts Thanks for reaching out to Microsoft Q&A, apologize for any inconvenience caused on this.

Based on the information shared, I have understood that you are not able to bind the root/apex domain as custom domain in app service and the value of record A is showing as blank.

An App Service app runs in an App Service plan, and App Service plans are deployed into one of the deployment units in the Azure infrastructure (internally called a webspace). Each deployment unit is assigned a set of virtual IP addresses, which includes one public inbound IP address and a set of outbound IP addresses.

When inbound IP changes

Regardless of the number of scaled-out instances, each app has a single inbound IP address. The inbound IP address may change when you perform one of the following actions:

• Delete an app and recreate it in a different resource group (deployment unit may change).
• Delete the last app in a resource group and region combination and recreate it (deployment unit may change).
• Delete an existing IP-based TLS/SSL binding, such as during certificate renewal (see Renew certificate).

You can pull the IP address of the App service using this web-based tool digiwebinterface.com to create A record in your DNS zone and further to bind the apex custom domain to your app service.

Feel free to reach back to me if you have any further questions on this.

Answer 2

Hi folks, i'm experiencing exactly the same issue. Trying to create an managed certificate to apex/root domains, reading the message we found out that public ip isn't set ("Ensure that your domain xxx.com has an A record which is set to .") it ends with a blank info.

Any news about how we can solve it by ourselves ?

Thanks

Answer 3

These are known issues. Support has given us a workaround until the issue is permanently fixed.

The way to do it is to use the Azure Powershell CLI.

for SSL:
$resourceGroupName="ReplaceResourceGroupName"
$appServiceName="ReplaceAppName"
$domainName="ReplaceDomainName"
az webapp config ssl create --resource-group $resourceGroupName --name $appServiceName --hostname $domainName

for custom domains:

az webapp config hostname add --webapp-name replacewebappname --resource-group replacemyResourceGroup --hostname replacefqdn

Answer 4

This issue is still not resolved. The Azure Portal is still not displaying an IP Address in Custom Domains which blocks you from validating an A record or adding SSL bindings. After more than 2 months without a resolution this sounds more like a business decision than a technical issue (ie. Microsoft wants clients to pay for a dedicated IP address). If so, this is extremely disappointing.

Answer 5

After an extensive period of trial and error, I managed to unearth a solution for setting up SSL for both the www subdomain and the naked domain of an Azure App Service. Here's a more detailed and clarified approach:

1. Start by Setting Up a Custom Domain with www.yourdomain.com:
   • The first crucial step involves creating a custom domain specifically for www.yourdomain.com. During this process, it's imperative to opt for an IP-based SSL certificate. This choice is strategic; it assigns a virtual IP address to your Azure App Service, enabling the subsequent association of APEX domains through A records. This step is essential for directing traffic to your service using the www prefix.
2. Patiently Wait for the Custom www Subdomain to Activate:
   • After configuring your custom www subdomain, allow a few minutes for the setup to complete. This waiting period is necessary for the changes to propagate and for the new IP address, provided by the IP-based SSL certificate, to be recognized as associated with your Azure App Service.
3. Configure DNS for the Naked Domain:
   • With the www subdomain configured and the virtual IP assigned, the next phase involves setting up the DNS for your naked domain (e.g., yourdomain.com). If your DNS is managed by Azure, this can simplify the process. At this juncture, choosing an SNI-based SSL certificate is crucial. Unlike IP-based SSL, SNI SSL doesn't require a dedicated IP for each certificate, a limitation you must navigate since Azure App Service cannot generate unlimited virtual IPs.
   • The selection of an SNI-based SSL for the naked domain ensures that the SSL binding process is automated when creating the custom domain. This is because SNI SSL can secure multiple domains or subdomains on a single IP address, facilitating the management of SSL for both the www subdomain and the naked domain concurrently.
4. Final Outcome – Secured www Subdomain and Naked Domain:
   • By following these steps diligently, you will successfully direct traffic to your Azure App Service via both the www subdomain and the naked domain. Moreover, both domains will be safeguarded by SSL encryption. This approach negates the need for purchasing external SSL certificates, offering a cost-effective solution to secure your domains.

This method elegantly addresses the challenge of securing both the www subdomain and the naked domain with SSL, utilizing the capabilities of Azure App Service and the different types of SSL certificates available. It underscores the importance of understanding the distinction between IP-based and SNI-based SSL certificates and their respective applications in configuring SSL for Azure App Services efficiently.More details and pictures in my blog.