Add support to enable regional DNL for Azure App Service by ShilpiRach · Pull Request #14001 · microsoft/aspire

ShilpiRach · 2026-01-19T11:56:51Z

Description

Added a feature to enable regional DNL with Scope set to TenantReuse. Regional DNL (Domain Name Label) is the App Service platform feature that generates regionalised, unique default hostnames for Web Apps. Details: https://techcommunity.microsoft.com/blog/azurenetworkingblog/improve-dns-security-by-using-domain-name-label-scope/4093371.

The feature is disabled by default and can be enabled for AzureAppServiceEnvironment with method WithRegionalDnl().

Changes:

Added method WithRegionalDnl() to AzureAppServiceEnvironment.
This method sets property EnableRegionalDnl for the environment resource.
If true, it adds the following property to website resource:
dashboard.AutoGeneratedDomainNameLabelScope = AutoGeneratedDomainNameLabelScope.TenantReuse
Since the hostname cannot be constructed (as it is random and generated by the platform), to specify dependencies between app services, we need to query the platform.
- Added provisioning parameters to AppServiceWebsiteContext for website and slot host names
- Added a pipeline step fetch-website-hostname that makes ARM call to endpoint /subscriptions/{armContext.SubscriptionId}/providers/Microsoft.Web/locations/{armContext.Location}/CheckNameAvailability to fetch the hostname. It sets the provisioning parameters.
- The pipeline steps to fetch-website-hostname are executed before provisioning to resolve the dependencies.

Fixes # (issue)

Checklist

Is this feature complete?
- Yes. Ready to ship.
- No. Follow-up changes expected.
Are you including unit tests for the changes and scenario tests if relevant?
- Yes
- No
Did you add public API?
- Yes
  - If yes, did you have an API Review for it?
    - Yes
    - No
  - Did you add <remarks /> and <code /> elements on your triple slash comments?
    - Yes
    - No
- No
Does the change make any security assumptions or guarantees?
- Yes
  - If yes, have you done a threat model and had a security review?
    - Yes
    - No
- No
Does the change require an update in our Aspire docs?
- Yes
  - Link to aspire-docs issue (consider using one of the following templates):
- No

github-actions · 2026-01-19T11:57:00Z

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 14001

Or

Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 14001"

Copilot

Pull request overview

This PR adds support for enabling regional Domain Name Label (DNL) for Azure App Service resources in the Aspire hosting model. Regional DNL allows Azure App Services to use region-specific hostnames with tenant reuse capabilities, providing more predictable and stable DNS names.

Changes:

Adds a new WithRegionalDNL() extension method to configure regional DNL for Azure App Service environments
Refactors hostname resolution to support both standard and regional DNL naming patterns
Introduces runtime hostname fetching via Azure ARM API calls to retrieve DNL-generated hostnames
Updates the provisioning pipeline to fetch and configure hostnames before provisioning resources

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 13 comments.

Show a summary per file

File	Description
AzureAppServiceWebsiteContext.cs	Refactored hostname handling to use provisioning parameters instead of computed Bicep values; added methods to get/set website hostnames
AzureAppServiceWebSiteResource.cs	Added pipeline step to fetch DNL hostnames via ARM API; introduced new length constraints for DNL scenarios; refactored hostname construction logic
AzureAppServiceEnvironmentUtility.cs	Updated dashboard creation to support regional DNL configuration with comprehensive XML documentation
AzureAppServiceEnvironmentResource.cs	Added EnableRegionalDNL property and early return in PrintDashboardUrlAsync when dashboard is disabled
AzureAppServiceEnvironmentExtensions.cs	Added public WithRegionalDNL API method; updated dashboard URI generation to use DefaultHostName

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-23T05:43:51Z

src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs

+    /// <param name="builder">The AzureAppServiceEnvironmentResource to configure.</param>
+    /// <param name="enable">The regional DNL host name for all App Services in the App Service Environment.</param>
+    /// <returns><see cref="IResourceBuilder{T}"/></returns>
+    public static IResourceBuilder<AzureAppServiceEnvironmentResource> WithRegionalDNL(this IResourceBuilder<AzureAppServiceEnvironmentResource> builder, bool enable = true)


The XML documentation for this method is missing required parameter descriptions, return value description, and sufficient detail for public API documentation. According to the coding guidelines, public APIs require comprehensive documentation including detailed remarks and parameter descriptions. The documentation should explain what DNL (Domain Name Label) is, when to use regional DNL, and what behavior changes when it's enabled.

src/Aspire.Hosting.Azure.AppService/AzureAppServiceWebSiteResource.cs

src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentResource.cs

src/Aspire.Hosting.Azure.AppService/AzureAppServiceWebSiteResource.cs

Copilot · 2026-01-23T05:43:54Z

src/Aspire.Hosting.Azure.AppService/AzureAppServiceWebSiteResource.cs

+            var trimmedSlotName = TruncateToMaxLength(deploymentSlot, MaxDeploymentSlotNameLengthWithDnl);
+            websiteName += $"-{trimmedSlotName}";
+
+            return websiteName;


When regionalDnlEnabled is true and there's a deployment slot, the method returns the combined website name without applying a final length check (line 296). Unlike the non-DNL path which applies TruncateToMaxLength on the final combined string (line 308), the DNL path relies on the sum of pre-truncated parts. While the math appears correct (23 + 1 + 18 = 42), it would be more defensive and consistent with the non-DNL path to apply a final truncation to ensure the combined name never exceeds expected limits.

Suggested change

return websiteName;

return TruncateToMaxLength(websiteName, MaxWebsiteHostNameLengthWithSlotAndDnl);

src/Aspire.Hosting.Azure.AppService/AzureAppServiceWebSiteResource.cs

…urce.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…to dnlsupport2

src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs

Fix tests

eerhardt · 2026-02-04T18:27:50Z

...s/AzureAppServiceTests.AddAppServiceContainerWithoutTargetPortUsesDefaultPort.verified.bicep

 @description('The location for the resource(s) to be deployed.')
 param location string = resourceGroup().location

+param container1websiteHostName string = '${take('${toLower('container1')}-${uniqueString(resourceGroup().id)}', 60)}.azurewebsites.net'


Can we make it so these parameters are not added if they aren't used?

eerhardt · 2026-02-04T18:34:18Z

src/Aspire.Hosting.Azure.AppService/AzureAppServiceWebSiteResource.cs

+            var fetchWebsiteHostNameSteps = context.GetSteps("fetch-website-hostname");
+            provisionSteps.DependsOn(fetchWebsiteHostNameSteps);


Can we add a test that ensures when one app service references another app service that the steps are ordered correctly? From the code, I see that we are saying all app service provision steps depend on all other apps' fetch-website-hostname steps.

I see that we are saying all app service provision steps depend on all other apps' fetch-website-hostname steps.

Yes, this is needed to ensure that all hostnames are available before provisioning steps to resolve any references to other app services.

eerhardt · 2026-02-04T18:39:29Z

...sts/Snapshots/AzureAppServiceTests.AddAppServiceToEnvironmentWithoutDashboard.verified.bicep


 param project2_containerport string

+param project1websiteHostName string


Does this work? Who fills in this parameter?

It is set by pipeline step that fetches hostname. It also has a default value for azd cli.

…to dnlsupport2

Changes for DNL support

d31f00a

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Jan 19, 2026

ShilpiR added 9 commits January 19, 2026 20:58

changing step dependencies

1d03607

nit fix

0f1fa54

Fixing bugs

b4ce993

fix

18bbf35

Adding bicep parameter

a4ac204

Using output for dashboard uri

ae373cc

Cleanup

ae027d3

Removing annotation file no longer needed

e06c71b

fixed comments

eefd2e0

ShilpiRach marked this pull request as ready for review January 23, 2026 05:33

ShilpiRach requested review from captainsafia and eerhardt as code owners January 23, 2026 05:33

Copilot AI review requested due to automatic review settings January 23, 2026 05:33

Copilot started reviewing on behalf of ShilpiRach January 23, 2026 05:34 View session

ShilpiRach marked this pull request as draft January 23, 2026 05:38

Copilot AI reviewed Jan 23, 2026

View reviewed changes

ShilpiRach and others added 3 commits January 22, 2026 21:54

Update src/Aspire.Hosting.Azure.AppService/AzureAppServiceWebSiteReso…

1eb321f

…urce.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

Doc fixes

abe425f

Merge branch 'dnlsupport2' of https://github.com/ShilpiRach/aspire in…

feb7b5a

…to dnlsupport2

eerhardt reviewed Jan 23, 2026

View reviewed changes

src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs Outdated Show resolved Hide resolved

eerhardt reviewed Jan 23, 2026

View reviewed changes

src/Aspire.Hosting.Azure.AppService/AzureAppServiceEnvironmentExtensions.cs Outdated Show resolved Hide resolved

ShilpiR added 6 commits January 28, 2026 04:04

Fixing naming based on PR comments

68b44e0

Fixing tests

8682a6b

Merge from main

af07039

fixing build break

ca7f0a2

Merge branch 'main' into dnlsupport2

80f0798

bug fix

15ea4b2

ShilpiRach changed the title ~~[Testing] Add support to enable regional DNL for Azure App Service~~ Add support to enable regional DNL for Azure App Service Feb 3, 2026

ShilpiR added 4 commits February 3, 2026 02:00

Added defaults to work with azd cli

5e460a1

nit

890d99f

Setting default value conditionally

9f0cd26

bug fix

9083828

ShilpiRach marked this pull request as ready for review February 3, 2026 11:56

eerhardt self-assigned this Feb 4, 2026

PR review feedback

df7a584

Fix tests

eerhardt reviewed Feb 4, 2026

View reviewed changes

eerhardt added 2 commits February 4, 2026 15:29

more PR feedback

858cef5

Fix tests

ac498fe

github-actions bot mentioned this pull request Feb 6, 2026

[pull requests] Review required #13834

Open

ShilpiR and others added 4 commits February 6, 2026 09:44

Removed adding host name parameters to a website bicep unless needed

dedde54

Merge branch 'dnlsupport2' of https://github.com/ShilpiRach/aspire in…

08acd2b

…to dnlsupport2

Merge from main

38c8b39

Accept new baselines

4f5791a

	return websiteName;
	return TruncateToMaxLength(websiteName, MaxWebsiteHostNameLengthWithSlotAndDnl);

		var fetchWebsiteHostNameSteps = context.GetSteps("fetch-website-hostname");
		provisionSteps.DependsOn(fetchWebsiteHostNameSteps);


		param project2_containerport string

		param project1websiteHostName string

Conversation

ShilpiRach commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Checklist

Uh oh!

github-actions bot commented Jan 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI Jan 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

eerhardt Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

eerhardt Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

ShilpiRach Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

eerhardt Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

ShilpiRach Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

ShilpiRach commented Jan 19, 2026 •

edited

Loading

github-actions bot commented Jan 19, 2026 •

edited

Loading