How to get raw IP addresses for .NET Aspire containers to assign them to dependencies before the dependencies start, and resolve DNS queries from external .NET projects

[121GWJolt]

Hello!

So... as said in the title, I'm using .NET Aspire to make a networking tool for myself that would coordinate a lot of other tools. It requires me to work with a self-hosted DNS and I'm trying to integrate it into the project itself. That being said, this has been a slightly rough path getting there. So...

1. At least one of my resources needs to have an environment variable set with specifically the IP address of a resource it depends on. Hostname has, thus far, been unacceptable to the consuming program, and I need these all to run on the same network in order to simulate prod. I need some way of retrieving the Aspire network addresses or forcing a specific one to be chosen during runtime in order to accomplish all of this. Ideally, I would be able to have two co-dependent services both be able to have each other's addresses, but for testing purposes I can get away with only the dependent service knowing the IP address of the service it depends on.
2. I am currently trying to make DNS calls from within my project to the DCP server in addition to my own self-hosted one. However, when using the System.Net.Dns class to make queries for IPs to my dependency services, they instead attempt to make queries to the host. How would I be able to run my API project as if it were within the Aspire network itself, including referencing the DCP for its services?
3. Is there a cleaner way to expose both TCP and UDP ports at the same time than making two separate endpoints and then having both of them separate from the DCP? (I might file a bug report since the DCP outright errors when I try to open the same port on TCP and UDP even though it's standard practice....)

If further details are needed, I can provide, but I'm trying to find a good way to do this at the moment and could use some guidance, since we currently can't configure the Aspire network at all as far as I can tell.

[davidfowl]

What aspire network are you looking for? I assume you don’t mean container network but something else? I think we need more details in order to better help here. If you are trying to run a make dns work outside of containers then nothing in aspire will help you, there’s no system wide dns server installed. Service discovery today is all configuration based (via environment variables, not by hijacking your process’ dns configuration). If you’re talking about containers then you have a lot more control but it’s also more complex. You can also just edit the OS’ host file and make it work that way as well.

Is there a cleaner way to expose both TCP and UDP ports at the same time than making two separate endpoints and then having both of them separate from the DCP? (I might file a bug report since the DCP outright errors when I try to open the same port on TCP and UDP even though it's standard practice....)

Sounds like a bug @danegsta. UDP isn’t used in mainline scenarios much so I wouldn’t be surprised if there are issues here.

[danegsta]

Yeah, redis containers are the only example I can think of off the top of my head that use a UDP port; definitely warrants some investigation.

[121GWJolt]

Thank you both for your responses! I apologize for not getting back to this discussion sooner; busy times.

The service I am trying to make works with a large portion of the network stack, so I am trying to run containers for the network stack in question. Specifically, I'm having issues with orchestrating the PowerDNS Authoritative and Recursor servers via Aspire. While I can get the authoritative server to run just fine and even query the API, there are several different configuration variables that ONLY take IP addresses which render it, and the recursive server by extension, unable to call into each other properly.

Outside of Aspire, the simplest way I could find to do what I want to do is manually specifying a container network subnet/gateway, and then assigning the IP address of the static services manually. I am not certain if this approach most directly fits the Aspire approach, but this (and similar approaches via standard Docker commands) is the only approach I know of that will allow me to configure these services properly. Everything else is fine for using service names; these two just do not accept anything but IP addresses in their configurations. I already tried using injected hosts and feeding those hostnames as values (in a separate compose file), but the programs still did not like that for the configuration options in question.

An extra bonus of being able to manually specify the network is that one could easily grab the gateway address to point services to, say, an upstream, for example.

Alternatively, if we can't get gateway addresses to be known, being able to access endpoints from within the aspire network by querying their external ports

I COULD use externally-hosted versions, but I'm trying to get everything orchestrated by Aspire instead if possible.

Yeah, redis containers are the only example I can think of off the top of my head that use a UDP port; definitely warrants some investigation.

Understood! I'll file a bug ticket later.

[121GWJolt]

Realizing a potential concern now, and want to say that I'm less concerned with the publisher supporting the IP address as that would most likely have either some manual configuration involved or something of that sort; I just want some way to do this with the Aspire orchestrator itself so I can develop entirely without having to rely on external services/VMs/networks.

[davidfowl]

I'm not sure I understand the usecase nor and what doesn't work.

[121GWJolt]

My tool works with PowerDNS, which has several configurations that require IP addresses only and will not take DNS hostnames. PowerDNS Recursor especially requires it because it needs to know the IP address of PowerDNS Authoritative Server in order to send queries it receives that way, and possibly the gateway address so I could provide it as upstream. Likewise, PowerDNS Authoritative Server needs to know the IP address of the Recursor to resolve ALIAS IP records. The tool I am trying to build in Aspire would partially work with these programs, so I'd still like to be able to spin those up as local docker containers.

Finally, I'd like to be able to spin up an Edge Browser as a container (which I can already do thanks to a few containers already available) within the network and be able to provide the IP address for the recursor directly to it.

What ISN'T working is that I have no reliable way to predict what subnet the aspire network will be assigned, nor a way to predict what container will get what IP address. Because of that, I cannot pass IP addresses to the settings that specifically require IP addresses. If I had some way of knowing what IP addresses would get assigned to what, I'd be able to pass in the PowerDNS configuration options as IP addresses, and could always change the DNS address of the Edge Browser container by passing the "--dns" option to the container runtime. Without a way to obtain IP addresses, or to statically configure the subnet, I cannot configure PDNS Authoritative or Recursor and need to host them elsewhere.