mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-22 09:32:36 -05:00
[GH-ISSUE #820] Define internaly DNS #16631
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#16631
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @markusglaetzner on GitHub (Jun 1, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/820
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.
@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?
@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.
@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.
@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.