Critical: .NET install domains and URLs are changing

[richlander]

Some .NET binaries and installers are 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. It is possible that .azureedge.net domains will have downtime or become permanently unavailable.

Current status:

• azureedge.net CDN domains are functional
• New CDN domains are functional
• Install scripts have been updated

Recommended action:

• Read Critical: .NET Install links are changing for an overview.
• Switch azureedge.net references to new domains
• Update your local copies of the install script
• Validate that firewall rules are resilient to using Akamai and/or Azure Front Door CDNs.

Last update: 2024.12.27
Next Update: 2025.01.02

You may need to adapt to these changes.

We expect azureedge.net domains to cease being functional in the first half of 2025. Moving your usage to the new CDN is the best path to avoiding service disruption.

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

Our plan is a work-in-progress and is expected to evolve. We recommend that affected users make changes by the end of January.

Affected resources

Domains affected:

• https://dotnetcli.azureedge.net
• https://dotnetbuilds.azureedge.net

URLs affected:

• https://dot.net/v1/dotnet-install.sh
• https://dot.net/v1/dotnet-install.ps1
• https://aka.ms/dotnet/ (various)

Not affected:

• https://dotnet.microsoft.com/
• https://download.visualstudio.microsoft.com/

There are many users of these resources, for example:

• https://github.com/search?q=dotnetcli.azureedge.net&type=code
• https://github.com/search?q=dot.net%2Fv1%2Fdotnet-install&type=code

On December 23rd, we switched the two azureedge.net domains above to use Azure Traffic Manager. After that change, those domains continued to send 100% of traffic to our edg.io CDNs. We expect to drop edgio traffic to zero on December 27th by sending all traffic to a different CDN. These changes could break users with conservative firewall rules.

Users should not consider azureedge.net to be a long-term usable domain. Please move to the new domains as soon as possible. It is likely that these domains will be retired in the first half on 2025. No other party will be able to use them. We are not able to control the timing of these events.

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

The updated scripts prefer the new CDNs, while enabling fallback to the legacy azureedge.net domains. The legacy domains will be removed at a later point.

• 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/docs #44052

Notes (for the install script):

• The -NoCdn or --no-cdn argument can be used to bypass using the CDN, which may help some users.
• The -AzureFeed or --azure-feed argument can be used to specify an alternate storage account or CDN.

Plan for domains

There are multiple domains, used for different purposes.

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

Note: Official builds are tested and signed by Microsoft. A microsoft.com domain was chosen to reflect that.

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 early January.

Tracking PR:

• dotnet/arcade #15365

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.

• Currently forward to: https://dotnetbuilds.azureedge.net.
• Will be changed to forward to: https://ci.dot.net.

We expect these links to be changed in early January.

Tracking PR:

• dotnet/arcade #15365

CI build pages use the CI short links.

Example build pages:

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

Azure DevOps and GitHub Actions

• GitHub Actions has been updated to use the new domains, per actions/setup-dotnet #570
• 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.

[richlander]

FYI @dotnet/distro-maintainers

[Varorbc]

Azure DevOps UseDotnetTask will be updated in January
We also noticed that there is a lot of use of our storage account: dotnetcli.blob.core.windows.net. Please also search for it. The storage account is unaffected, however, it would be much better for everyone if you used our new CDN. It will deliver better peformance.

@richlander I noticed your pipeline team only updated the download links. Did they maybe miss something or not fully understand the issue? Could you also fix the release index links when you push out the update in January?

[richlander]

I will share this with them @Varorbc.

[Rand-Random]

maybe a noob question why didn’t just keep the old domain? why would a domain change be needed? couldn’t the old domain name not simply resolved to the new servers?

[richlander]

We asked the same question. We were told that this option wasn't being made available. We don't have more information on that.

[chrarnoldus]

What's the difference between getting official builds from builds.dotnet.microsoft.com and download.visualstudio.microsoft.com? Most of the links in the JSON files seem to point to the latter.

[richlander]

No difference. Both are fine. download.visualstudio.microsoft.com is/was unaffected by this situation.

We'll be publishing new guidance after we've had a chance for some "downtime". It's likely that the new guidance will apply more to how the install script, GitHub Actions, and AzDo Tasks are implemented than requiring a typical user to do something significantly different.

[mitchcapper]

It is unfortunate but understandable that MS is now in full control of the azureedge.net domain yet is unable to setup redirects.
A bit more confusing is this part:

URLs affected:

• https://dot.net/v1/dotnet-install.sh
• https://dot.net/v1/dotnet-install.ps1
• https://aka.ms/dotnet/ (various)

These are already aliases, aka.ms is literally a redirect service. Can these urls not be updated to the correct locations? Infact it looks like some already are redirect to "not affected" domains:

wget2 https://dot.net/v1/dotnet-install.ps1
HTTP response 301  [https://dot.net/v1/dotnet-install.ps1]
URL 'https://dotnet.microsoft.com/download/dotnet/scripts/v1/dotnet-install.ps1'

wget2 https://dot.net/v1/dotnet-install.sh
HTTP response 301  [https://dot.net/v1/dotnet-install.sh]
URL 'https://dotnet.microsoft.com/download/dotnet/scripts/v1/dotnet-install.sh'

Should they be removed from the affected list?

It does look like several of the aka.ms urls will 301 redirect as mentioned in this ticket already or showing in the actual location 301 returned that is is pointing to a safe domain.

[mairaw]

@mitchcapper the contents of those scripts were changed to use the new CDNs. It should be transparent to most folks, but depending on how your infrastructure is set up like allow lists, copy of the scripts, etc. you might need to take action.

[richlander]

I updated the content above. It addresses the change in the install script. Thanks for asking for that clarification @mitchcapper. Good question.