question

MarkW-3630 avatar image
0 Votes"
MarkW-3630 asked MarkW-3630 commented

Web App IP address for DNS A-record configuration changed without notice

We noticed that the IP address of our WebApp's custom domain name in Europe West has changed after several years.

This morning our DNS had a different IP than the one listed in the Azure portal. This caused issues with our TLS certificate and it took us quite some time to figure out what was going on.

We weren't informed about this address change. This would have helped us a lot.

Did we miss anything? Is there some sort of mailing list we can subscribe to?

Regards from Germany,
Mark.

azure-webappsazure-webapps-ssl-certificatesazure-webapps-ip-addresses
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

1 Answer

brtrach-MSFT avatar image
0 Votes"
brtrach-MSFT answered MarkW-3630 commented

@MarkW-3630 We apologize for the frustration you encountered with your inbound IP address changing for your web app.

There have not been any official inbound IP address changes made to our knowledge and our internal alert system. Inbound IP change events are very rare (can only recall 1 in the last seven years) and are communicated many months in advance to customers via portal alerts, emails, and official Microsoft documentation.

When customers state their inbound IP address has changed, this is normally due to them rotating their IP based SSL certificate improperly. If you delete your old IP SSL binding and then upload your new certificate/bind the new IP SSL certificate, this is improper. When you delete the IP SSL binding, it releases the IP address back into the pool of available addresses for other customers. Your resource can continue using the old IP address so you might not notice the mistake for 1-3 weeks until the IP address is assigned to another Azure service.

The proper way to rotate certificates is to simply bind the new certificate with the old binding still in place. The Web App will automatically then apply the newer binding. Once this is complete, verify that your site is serving the newer thumbprint before deleting your old certificate.

  1. Upload the new certificate.

  2. Bind the new certificate to the same custom domain without deleting the existing (expiring) certificate. This action replaces the binding instead of removing the existing certificate binding. To do this, navigate to the TLS/SSL settings blade of your App Service and select the Add Binding button.

  3. Delete the existing certificate.

This limitation is called out here.

Lastly, we recommend that customers use a CNAME binding as a best practice over using an A-record. Unless you need to hard code IP addresses into your app, most customers do not need an A-record. A-records risk your sites high availability by taking them offline if a certificate/binding is rotated improperly or if there were to be an inbound IP address change in the future (rare) it would require action on your end. For more information on configuring your app via CNAME, please see here.

Please let us know if you have any further questions or concerns.

· 1
5 |1600 characters needed characters left characters exceeded

Up to 10 attachments (including images) can be used with a maximum of 3.0 MiB each and 30.0 MiB total.

Thanks, it looks like this is the solution to our issue which we fixed yesterday by adjusting the A record in our DNS.

We recently changed the TLS certificate for one of our domains and all of its subdomains with a new wildcard cert. It looks like we accidentally confused SNI and IP based binding, switched to IP, switched back to SNI, ... . This very likely caused the IP address change and consecutive issues.

We will verify if CNAME is a better option for us instead of using A-record.

Thanks for your comprehensive help.




0 Votes 0 ·