How to delete Dangling DNS record for an App Service resource

Question

We recently deleted a number of resources in Azure that were no longer needed but now we have some security alerts for 5 dangling dns records. The App Services, Resource Groups and DNS ZOnes are no longer around (perhaps I cant see the DNS Zone). The remediation suggests that I delete the CNAME record in the DNS Zone but I dont have a DNS Zone in this subscription.

the error is:

A DNS record that points to a recently deleted App Service resource (also known as "dangling DNS" entry) has been detected. This leaves you susceptible to a subdomain takeover. Subdomain takeovers enable malicious actors to redirect traffic intended for an organization’s domain to a site performing malicious activity.

again in our case the resource group and affected resource app service is no longer around.

thanks in advance

Answer 1

@Lance Lyons Thank you for reaching out to us.

To delete dangling DNS entries if this is necessary, there many options you have to implement this.

You can follow at least one of the below steps to prevent dangling DNS entries:

NB: Anyone of the option should suite your need.

1. Enable Azure Defender for App Service

Azure Security Center's integrated cloud workload protection platform (CWPP), Azure Defender, offers a range of plans to protect your Azure, hybrid, and multi-cloud resources and workloads. The Azure Defender for App Service plan includes dangling DNS detection. With this plan enabled, you'll get security alerts if you decommission an App Service website but don't remove its custom domain from your DNS registrar. Azure Defender's dangling DNS protection is available whether your domains are managed with Azure DNS or an external domain registrar and applies to App Service on both Windows and Linux.

2. Use Azure DNS alias records

Azure DNS's alias records can prevent dangling references by coupling the lifecycle of a DNS record with an Azure resource. For example, consider a DNS record that's qualified as an alias record to point to a public IP address or a Traffic Manager profile. If you delete those underlying resources, the DNS alias record becomes an empty recordset. It no longer references the deleted resource. It's important to note that there are limits to what you can protect with alias records. Today, the list is limited to:

• Azure Front Door
• Traffic Manager profiles
• Azure Content Delivery Network (CDN) endpoints
• Public IPs

Despite the limited-service offerings today, we recommend using alias records to defend against subdomain takeover whenever possible.

3. Use Azure App Service's custom domain verification

When creating DNS entries for Azure App Service, create an asuid.{subdomain} TXT record with the Domain Verification ID. When such a TXT record exists, no other Azure Subscription can validate the Custom Domain that is, take it over. These records don't prevent someone from creating the Azure App Service with the same name that's in your CNAME entry. Without the ability to prove ownership of the domain name, threat actors can't receive traffic or control the content.

4. Build and automate processes to mitigate the threat

It's often up to developers and operations teams to run cleanup processes to avoid dangling DNS threats. The practices below will help ensure your organization avoids suffering from this threat.

• Create procedures for prevention:
• Educate your application developers to reroute addresses whenever they delete resources.
• Put "Remove DNS entry" on the list of required checks when decommissioning a service.
• Put delete locks on any resources that have a custom DNS entry. A delete lock serves as an indicator that the mapping must be removed before the resource is deprovisioned. Measures like this can only work when combined with internal education programs.
• Create procedures for discovery:
• Review your DNS records regularly to ensure that your subdomains are all mapped to Azure resources that:
• Exist - Query your DNS zones for resources pointing to Azure subdomains such as *.azurewebsites.net or *.cloudapp.azure.com
• You own - Confirm that you own all resources that your DNS subdomains are targeting.
• Maintain a service catalog of your Azure fully qualified domain name (FQDN) endpoints and the application owners. To build your service catalog, run the following Azure Resource Graph query script. This script projects the FQDN endpoint information of the resources you have access to and outputs them in a CSV file. If you have access to all the subscriptions for your tenant, the script considers all those subscriptions as shown in the following sample script. To limit the results to a specific set of subscriptions, edit the script as shown.
• Create procedures for remediation:
• When dangling DNS entries are found, your team needs to investigate whether any compromise has occurred.
• Investigate why the address wasn't rerouted when the resource was decommissioned.
• Delete the DNS record if it's no longer in use, or point it to the correct Azure resource (FQDN) owned by your organization.

Hope this helps! Kindly let us know if the above helpful and solve the issue.

Cheers.

Answer 2

@Lance Lyons

Thank you for reaching out to us on the Microsoft Q&A forum.

You can follow the documentation here to identify the dangling DNS records. To run the query you at least need a reader level access to the Azure subscription OR read access to Azure resource graph.

As the DNS zones have been deleted this can be a false positive alert.

Please let us know if you need any additional help, we will be glad to continue with our discussion. Thank you!