Define internaly DNS #398

New Issue

2025-11-13T11:59:16-06:00

GiteaMirror commented

2025-11-13 11:59:16 -06:00

Originally created by @markusglaetzner on GitHub (Jun 1, 2025).

I have pangolin installed on a VPS. In my homelab I use Cosmos-Server as reverse proxy and docker-management. With Cosmos Server I have the advantage that I do not have to publish ports of my Docker applications (like treafik does). This means that in the homelab, I only can access my applications via the HTTPS domain defined in Cosmos Server (i.e., instead of "http://application:port" only "https://application.mydomain.org"). When I define access rules in pangolin in order to reach this "internal" service and use domain-names instead of ip-addresses and ports, pangolin tries to resolve this domain directly and gives me an error because this domain is not publicly accessible. The solution would be if I could specify internal DNS servers per service in pangolin.

Originally created by @markusglaetzner on GitHub (Jun 1, 2025). I have pangolin installed on a VPS. In my homelab I use Cosmos-Server as reverse proxy and docker-management. With Cosmos Server I have the advantage that I do not have to publish ports of my Docker applications (like treafik does). This means that in the homelab, I only can access my applications via the HTTPS domain defined in Cosmos Server (i.e., instead of "http://application:port" only "https://application.mydomain.org"). When I define access rules in pangolin in order to reach this "internal" service and use domain-names instead of ip-addresses and ports, pangolin tries to resolve this domain directly and gives me an error because this domain is not publicly accessible. The solution would be if I could specify internal DNS servers per service in pangolin.

GiteaMirror added the stale label 2025-11-13 11:59:16 -06:00

GiteaMirror closed this issue

2025-11-13 11:59:17 -06:00

GiteaMirror commented

2025-11-13 11:59:17 -06:00

@markusglaetzner commented on GitHub (Jun 1, 2025):

IT seems a Cosmos-server problem. I get the error "Bad Request: Invalid hostname. Use your domain instead of your IP to access your server. Check logs if more details are needed.". When I expose the port and use this in pangolin, it works just fine. So my Cosmos-Server recognizes, that there is a request with a different route, so this request is blocked - this behavior is fine, too. Maybe I have to add some entries in "Custom Host Header" in pangolin?

@markusglaetzner commented on GitHub (Jun 1, 2025): IT seems a Cosmos-server problem. I get the error "Bad Request: Invalid hostname. Use your domain instead of your IP to access your server. Check logs if more details are needed.". When I expose the port and use this in pangolin, it works just fine. So my Cosmos-Server recognizes, that there is a request with a different route, so this request is blocked - this behavior is fine, too. Maybe I have to add some entries in "Custom Host Header" in pangolin?

GiteaMirror commented

2025-11-13 11:59:18 -06:00

@pterabyte-dev commented on GitHub (Jun 3, 2025):

Not familiar with Cosmos-Server, but as you said Pangolin will try to resolve this using the DNS servers configured on the host (8.8.8.8,1.1.1.1, etc). You could potentially try create static host entries in your resolv.conf file pointing to the docker network IP of you Cosmos-Server instance that is reachable from newt. Frankly I think the best thing to do is to just attach each container, including the newt container, to an internal docker network, and access them via the internal docker host name and port. If your concerned about the containers talking to each other you could disable icc and setup IP tables to allow the containers to only talk to newt.

@pterabyte-dev commented on GitHub (Jun 3, 2025): Not familiar with Cosmos-Server, but as you said Pangolin will try to resolve this using the DNS servers configured on the host (8.8.8.8,1.1.1.1, etc). You could potentially try create static host entries in your resolv.conf file pointing to the docker network IP of you Cosmos-Server instance that is reachable from newt. Frankly I think the best thing to do is to just attach each container, including the newt container, to an internal docker network, and access them via the internal docker host name and port. If your concerned about the containers talking to each other you could disable icc and setup IP tables to allow the containers to only talk to newt.

GiteaMirror commented

2025-11-13 11:59:18 -06:00

@kalikid021 commented on GitHub (Jun 5, 2025):

If your newt container on the local network is using --network=host it should use the host network details (ie DNS server advertised by your network/router), as @pterabyte-dev also states, you can try to configure domains in your hosts file, resolv.conf, or attach the newt container to your docker network that Cosmos is using.

@kalikid021 commented on GitHub (Jun 5, 2025): If your newt container on the local network is using --network=host it should use the host network details (ie DNS server advertised by your network/router), as @pterabyte-dev also states, you can try to configure domains in your hosts file, resolv.conf, or attach the newt container to your docker network that Cosmos is using.

GiteaMirror commented

2025-11-13 11:59:18 -06:00

@github-actions[bot] commented on GitHub (Jun 20, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

@github-actions[bot] commented on GitHub (Jun 20, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.