Critical: .NET install domains and URLs are changing

[richlander]

.NET binaries and installers have moved to a new domain -- builds.dotnet.microsoft.com -- backed by a new Content Delivery Network (CDN). You may need to make changes to adjust.

Tracking issue: #9674

.NET Team Status:

• All domains and installer/scripts are functional
• No domains are using Edgio CDN
• https://dot.net/v1/dotnet-install.* redirects to new domain

Recommended action:

• Read Critical: .NET Install links are changing for an overview.
• Update azureedge.net references
• Update local copies of install script
• Update pinned references to actions/setup-dotnet
• Validate that firewall rules are resilient to using Akamai and Azure Front Door CDNs.

Last update: 2025.01.10
Next update: 2025.01.15

Context

Some .NET binaries and installers have been hosted on Azure Content Delivery Network (CDN) domains that end in .azureedge.net. These domains are hosted by edg.io, which will soon cease operations due to bankruptcy. We are required to migrate to a new CDN and will be using new domains going forward.

We expectazureedge.net domains to cease to function around 3/31.

.NET Team Remediation

New domains were created:

• builds.dotnet.microsoft.com for signed official builds
• ci.dot.net for signed builds

Test links for new CDN:

• https://builds.dotnet.microsoft.com/dotnet/Sdk/LTS/latest.version
• https://builds.dotnet.microsoft.com/dotnet/release-metadata/releases-index.json

Test links for old CDN:

• https://dotnetcli.azureedge.net/dotnet/Sdk/LTS/latest.version
• https://dotnetcli.azureedge.net/dotnet/release-metadata/releases-index.json

The following resources have been updated to use new domains.

• releases-index.json
• .NET install script
• actions/setup-dotnet
• CI short links

Other changes are in progress.

User Remediation

Please make the following replacements:

• dotnetcli.azureedge.net -> builds.dotnet.microsoft.com
• dotnetcli.blob.core.windows.net -> builds.dotnet.microsoft.com
• dotnetbuilds.azureedge.net -> ci.dot.net
• dotnetbuilds.blob.core.windows.net -> ci.dot.net

All the new domains are path-compatible with old domains, as they share the same origin.

Please also make the following changes:

• Update local copies of the install script
• Update setup-dotnet Action references
• Validate that firewall rules work with the new domains

Install script

The .NET install script is used to install .NET from our CDN. We are changing CDNs (documented in a following section), which requires us to change the install script to use the new CDN.

Updated scripts:

• https://dot.net/v1/dotnet-install.sh
• https://dot.net/v1/dotnet-install.ps1
• https://github.com/dotnet/install-scripts/tree/main/src

Notes:

• Users who have local copies of these scripts will need to update their copies.
• Users who rely on the remote copy (at the URLs above) do not need to do anything other than validate no observed change in behavior (due to new domains and CDNs being used).

Tracking PRs:

• dotnet/install-scripts #554
• dotnet/install-scripts #555
• dotnet/install-scripts/issues #558
• dotnet/install-scripts #564
• dotnet/docs #44052

Official builds

Official builds and JSON files are hosted via a CDN, available for use by the install script and other installers.

• New: https://builds.dotnet.microsoft.com
• Old: https://dotnetcli.azureedge.net

Notes:

• Official builds are tested and signed by Microsoft. A microsoft.com domain was chosen to reflect that.
• We also plan to stop using dowload.visualstudio.microsoft.com for new content. That CDN will continue to function.
• Microsoft.Deployment.DotNet.Releases has been updated

You can change from old to new domains by changing the domain section of the URL. The other parts of the URL do not need to change.

Example URLs:

• New: https://builds.dotnet.microsoft.com/dotnet/Runtime/8.0.11/dotnet-runtime-8.0.11-linux-x64.tar.gz
• Old: https://dotnetcli.azureedge.net/dotnet/Runtime/8.0.11/dotnet-runtime-8.0.11-linux-x64.tar.gz
• New: https://builds.dotnet.microsoft.com/dotnet/release-metadata/releases-index.json
• Old: https://dotnetcli.azureedge.net/dotnet/release-metadata/releases-index.json

A set of short links are available for official builds.

Link pattern:https://aka.ms/dotnet/[x.y]/[package].

Example URLs:

• https://aka.ms/dotnet/9.0/dotnet-sdk-win-x64.zip
• https://aka.ms/dotnet/8.0/aspnetcore-runtime-linux-x64.tar.gz

These links produce301 HTTP results that forward to our CDN.

• Currently forward to: https://dotnetcli.azureedge.net.
• Will be changed to forward to: https://build.dotnet.microsoft.com.

We expect these links to be changed in mid January.

Tracking PR:

• dotnet/core #9683

CI builds

Continuous integration (CI) builds are hosted via a CDN, available via the install script and GitHub README files.

• New: https://ci.dot.net
• Old: https://dotnetbuilds.azureedge.net

Note: CI builds include a mix of tested and untested builds, signed and unsigned builds.

Example URLs:

• New: https://ci.dot.net/public/Runtime/9.0.1-servicing.24610.11/dotnet-runtime-9.0.1-win-x64.exe
• Old: https://dotnetbuilds.azureedge.net/public/Runtime/9.0.1-servicing.24610.11/dotnet-runtime-9.0.1-win-x64.exe

A set of short links are available for CI builds.

Link pattern:https://aka.ms/dotnet/[x.y]/daily/[package].

Example URLs:

• https://aka.ms/dotnet/9.0/daily/dotnet-runtime-win-x64.exe
• https://aka.ms/dotnet/9.0/daily/aspnetcore-runtime-linux-arm.tar.gz
• https://aka.ms/dotnet/10.0.1xx/daily/dotnet-sdk-osx-arm64.pkg

These links produce301 HTTP results that forward to our CDN.

• New builds now forward to: https://ci.dot.net
• Old builds forward to: https://dotnetbuilds.azureedge.net.

We expect these links to be changed in mid January.

Tracking PR:

• dotnet/core #9683

CI build pages use the CI short links.

Example build pages:

• dotnet/runtime
• dotnet/aspnetcore
• dotnet/sdk

Azure DevOps and GitHub Actions

• Major versions tags for actions/setup-dotnet have been updated. References to pinned versions will require updating to the most recent version.
• We expect that GitHub Enterprise Server will be addressed in January.
• Azure DevOps UseDotnetTask will be updated in January
• We do not yet have a date for updating Azure DevOps Server.

Other changes

The following resources are also affected.

• dotnet/dotnet-docker Dockerfiles
• dotnet/core JSON files
• dotnet/templating template data
• iis.net is affected

[KalleOlaviNiemitalo]

Is there a risk that a malicious party later acquires azureedge.net and starts serving malware to systems that still use the old URLs? From WHOIS, it looks like azureedge.net is registered to Microsoft, not to Edgio. (Just wondering how urgent it is to update URLs in old version-control branches that are not actively developed but might get built some day.)

Have there been any NuGet feeds in the domain?

[shanselman]

@KalleOlaviNiemitalo we took it over, so it won’t be taken away.

[zarlo]

@KalleOlaviNiemitalo we took it over, so it won’t be taken away.

so why not keep the current urls for like 1-2 more dont net versions so after .net 11 you have to use the new urls this would give people time to update their whitelists

[klemmchr]

Given this issue I'm wondering when Microsoft will provide their own domain registrar on Azure to prevent such issues in the future. Currently this is the only thing that is really missing on the Azure platform. I can host virtually anything on Azure but when it comes to domains I still need to resort to a third party. I can point all my nameservers to Azure, sure. But the domain itself needs to be hosted somewhere else.

[charles-Graham-Keilman]

Does this affect the installers in the Azure Devops pipelines? We use a mix of classic and Yaml pipelines.

[klemmchr]

Does this affect the installers in the Azure Devops pipelines? We use a mix of classic and Yaml pipelines.

Yes, it does.

Azure DevOps and GitHub Actions installation tools are dependent on some of these resources. We are working directly with those teams to maintain continuity of service. They are moving to the new domains at best speed.

[Odraio]

The command npx playwright install redirects to https://playwright.azureedge.net/*. Is the install affected by https://devblogs.microsoft.com/dotnet/critical-dotnet-install-links-are-changing and necessary to update the links?

[baronfel]

@Odraio I believe these urls were updated in microsoft/playwright#34061, perhaps if you ask on their repo they will have information about release cadences?

[cetinbug]

@richlander For our Azure Functions, we currently use the URL functionscdn.azureedge.net to retrieve extension bundles. However, after reviewing the issue, I noticed that there is no specific mention of the subdomain functionscdn in the migration details. Could you please clarify if this subdomain will also be migrated and, if so, to which domain?

For example, we are getting extension bundles from a url like: "https://functionscdn.azureedge.net/public/ExtensionBundles/Microsoft.Azure.Functions.ExtensionBundle.Preview/$EXTENSION_BUNDLE_VERSION"

[asatrur]

We use the URL https://azcopyvnext.azureedge.net for downloading Azcopy, as it mentioned in all of MS's documentation as the location for downloading from. This stopped working yesterday and is not mentioned in your update. What is the new URL for this?

[o-l-a-v]

@cetinbug: Maybe it's better to ask in one of these repos:

• https://github.com/Azure/Azure-Functions
• https://github.com/Azure/azure-functions-extension-bundles

---

@asatrur: Azure/azure-storage-azcopy#2903.

The aka ms links will now point to URLs that start with https://azcopyvnext-awgzd8g7aagqhzhe.b02.azurefd.net/

If using the aka.ms links, they already point to azcopyvnext-awgzd8g7aagqhzhe.b02.azurefd.net.

• https://www.whatsmydns.net/redirect-checker?q=https%3A%2F%2Faka.ms%2Fdownloadazcopy-v10-windows

[asatrur]

@asatrur: Azure/azure-storage-azcopy#2903.

The aka ms links will now point to URLs that start with https://azcopyvnext-awgzd8g7aagqhzhe.b02.azurefd.net/

If using the aka.ms links, they already point to azcopyvnext-awgzd8g7aagqhzhe.b02.azurefd.net.

* https://www.whatsmydns.net/redirect-checker?q=https%3A%2F%2Faka.ms%2Fdownloadazcopy-v10-windows

Thanks, it would have been nice if they mentioned that somewhere before screwing us

[schoag-msft]

@asatrur: Azure/azure-storage-azcopy#2903.

The aka ms links will now point to URLs that start with https://azcopyvnext-awgzd8g7aagqhzhe.b02.azurefd.net/

If using the aka.ms links, they already point to azcopyvnext-awgzd8g7aagqhzhe.b02.azurefd.net.

* https://www.whatsmydns.net/redirect-checker?q=https%3A%2F%2Faka.ms%2Fdownloadazcopy-v10-windows

Thanks, it would have been nice if they mentioned that somewhere before screwing us

Please don't pull from any of the *.azureedge.net or *.azurefd.net for any service - you should be using the custom domains that front the CDN endpoints or the canonical aka.ms links. In the case of AzCopy, those links can always be found at https://aka.ms/downloadazcopy. Each platform we distribute for has its own aka.ms link that points to the most current release.