Provide a non-localhost domain for Aspire project & service endpoints

[hades200082]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

localhost, being used by so many different things, can get clogged up with cookies causing HTTP 431 "Request Header Fields Too Large" errors.

Additionally, it's not always possible to test or catch certain issues when everything uses localhost. CORS errors for example.

Describe the solution you'd like

I'd like Microsoft or the Aspire team to register a domain name specifically for Aspire to use with local development.

For the sake of my examples below, lets say you register aspire.dev.

You would then create a wildcard DNS A record *.aspire.dev pointing to 127.0.0.1 and an AAAA record *.aspire.dev pointing to ::1.

Within Aspire when running the apphost locally, you would then have it create all endpoints that would have been localhost using subdomains of aspire.dev instead.

For example:

var builder = DistributedApplication.CreateBuilder(args);

var databasePassword = builder.AddParameter("DatabasePassword", true);
var db = builder.AddPostgres("Database", password: databasePassword)
  .WithHealthCheck()
  .WithDataVolume($"AppHost-{Enum.GetName(databaseType)}-{name}-data")
  .WithPgAdmin()
  .AddDatabase("myApp");

builder.AddProject<Projects.Application_Host_Api>("MyApi")
  .WithExternalHttpEndpoints()
  .WithReference(db, dbOptions.ConnectionStringName)
  .WaitFor(db);

The above apphost would create the following endpoints:

• Database:
  • tcp - tcp://database.aspire.dev:54895 (port set as before)
• Database-pgadmin:
  • http - http://database-pgadmin.aspire.dev:54896/
• MyApi:
  • http - http://my-api.aspire.dev:5260/swagger (note kebab-casing from PascalCasing)
  • https - http://my-api.aspire.dev:7285/swagger

If more randomness is needed to avoid naming collisions, a simple 4-6 character random string could be added. e.g. http://my-api-dfghas.aspire.dev:7285/swagger

As a stretch goal, you could also add the option to configure your own base domain for this, which would allow developers and organisations to use Hosts file entries or internal corporate DNS servers to have the same functionality without needing to do a DNS lookup across the internet (for those with more stringent security requirements)

Additional context

Lando, another docker-based local development tool for PHP, does this already. When spinning up local environments using Lando it uses subdomains of lndo.site which has a 127.0.0.1 wildcard A record.

https://mxtoolbox.com/SuperTool.aspx?action=a%3aadfkljlgkh.lndo.site&run=toolpage

[DamianEdwards]

My understanding is that there are security implications of registering public DNS names that resolve to local addresses, especially when certificates are involved, and as such we would not do this. @blowdart for his comments.

[blowdart]

You'll note that the example given does not support https (https://adfkljlgkh.lndo.site/ does not respond), if memory serves those sorts of certificates have been revoked very quickly on previous occasions people tried.

To have a microsoft owned domain which wildcard resolves to localhost just seems off. Sure, developers can see the need, but it wouldn't be limited to just developers who understand the intent, and putting the burden of abuse emails on our domains team or any security team is too high a cost for the benefit provided.

[hades200082]

@blowdart I think you may have missed the part that it points to 127.0.0.1. If you want something to respond on a subdomain of lando.site you have to have something running on your local machine that can respond. That would include over https.

lando does support https on those domains. It's handled by a self-signed certificate on the local application end.

The developer can choose to make the certificate trusted on their machine or just live with the browser warning.

Since dotNET already uses local development certificates that can be trusted this shouldn't be a block.

[blowdart]

Ah, self-signed wouldn't upset the cab forum.

But, let me give you an example of why I wouldn't want Microsoft to own such a domain name.

Right now, in my spare time, I'm messing around with writing a Bluesky client library. They're about to support oauth. Part of their spec special cases localhost and 127.0.0.1/[::1] and adjusts the tokens issued accordingly. It's making security decisions based on the well-known dns entry and ip addresses.

It would treat aspire.dev like any other domain, which would be an unintended side effect. Same problem with SPA apps, if they wanted to do things on localhost, where you can't do DNS lookups to see what an fqdn actually resolves to. I'm sure there are a myriad other odd cases out there that do the same sort of thing.

So, from my security POV it's a non-starter I'm afraid.

[atrauzzi]

It would treat aspire.dev like any other domain

This is a good thing.

Inconveniencing the workaround of a single client library doesn't strike me as a comprehensive rationale.

If they want localhost behaviour, they wouldn't be using the DNS name, they'd be using localhost which isn't blocked from working...?

[hades200082]

@blowdart @atrauzzi I understand the concern.

Consider though, having a real dns entry with which to test things locally would help to debug various issues that might otherwise only arise once the application is deployed.

I did somewhat anticipate the possibility that Microsoft would not want to manage such dns however so came up with, what I believe could be, an alternative solution.

You could allow the developer to make the choice themselves.

A configuration or method call in the app host could be provided to allow the developer to use a domain that they control.

builder.UseLocalDomain("mydomain.dev");

This could apply the same principle and it would be up to the developer to decide how to make the subdomains resolve.

They could use hosts file, a lan dns server or a real dns zone.

They could also do:

builder.UseLocalDomain("local");

And have it use *.local

[blowdart]

Oh that I'm totally fine with 😀

[hades200082]

@blowdart @DamianEdwards so #4319 then 😀

[atrauzzi]

@hades200082 - I just set that up right now. It's way better than any of the local DNS mucking about I've done.

Obviously it has a cost associated with it, but I have several domains that I can use this for, and Aspire supporting a custom domain wouldn't rule out a local or intranet DNS setup.

The only thing Aspire really needs to support here is bundling a reverse proxy & certificates (like how https://nginxproxymanager.com/ does) and then supporting all the auto-wiring of entries based on what services have exposures.

Also make sure things like web sockets still work.

[hades200082]

@atrauzzi From a local development perspective, just having the ability to use something that isn't localhost would be great.

As @blowdart mentioned above, many things treat localhost differently and this makes some things hard to debug locally.

In addition, when you have a lot of projects and services running on localhost the HTTP header space can get pretty large with cookies, eventually causing a HTTP 431 error in places.

The ability to bind a custom hostname to each service and project would make life much easier on this end and solve these problems.