[GH-ISSUE #183] Resolving host IP address without DPS network #73

New issue

Closed

opened 2026-02-26 04:33:58 +03:00 by kerem · 3 comments

kerem commented

2026-02-26 04:33:58 +03:00

Owner

Originally created by @mrubli on GitHub (Jan 7, 2020).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/183

This is part question, part feature request, and part offer to help. 😉

It appears that host.docker always resolves to the DPS container's IP address instead of the host machine IP unless the DPS network is enabled. I've observed this on two systems and glancing at the code seems to confirm my suspicion because the gateway IP address is only obtained if the DPS network is active.

Maybe there are some scenarios I'm not thinking of right now but falling back to e.g. the bridge network and obtaining its gateway should give an IP address that's routable from most Docker networks. If this is not true for the general case perhaps a "try harder to find the host IP address" or "use network X's gateway as the host IP address" a command line switch would be useful, so that users can enable it in cases where it does work.

Any thoughts? I'd be happy to help out with the implementation if this sounds useful. (It certainly would be for me cause that's pretty much the only thing missing right now in my personal use cases.)

Originally created by @mrubli on GitHub (Jan 7, 2020). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/183 This is part question, part feature request, and part offer to help. 😉 It appears that `host.docker` always resolves to the DPS container's IP address instead of the host machine IP unless the DPS network is enabled. I've observed this on two systems and glancing at the code seems to confirm my suspicion because the gateway IP address is only obtained if the DPS network is active. Maybe there are some scenarios I'm not thinking of right now but falling back to e.g. the `bridge` network and obtaining its gateway should give an IP address that's routable from most Docker networks. If this is not true for the general case perhaps a "try harder to find the host IP address" or "use network X's gateway as the host IP address" a command line switch would be useful, so that users can enable it in cases where it does work. Any thoughts? I'd be happy to help out with the implementation if this sounds useful. (It certainly would be for me cause that's pretty much the only thing missing right now in my personal use cases.)

kerem

2026-02-26 04:33:58 +03:00

closed this issue
added the
bug

confirmed
labels

kerem commented

2026-02-26 04:33:58 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 9, 2020):

It appears that host.docker always resolves to the DPS container's IP address instead of the host machine IP unless the DPS network is enabled.

Confirmed, there's a bug

Maybe there are some scenarios I'm not thinking of right now but falling back to e.g. the bridge

I think it makes sense

use network X's gateway as the host IP address

Yep, it can be used as fallback if bridge network don't exists for some reason, I'm getting the first network listed

I've implemented these behaviors

@mageddo commented on GitHub (Jan 9, 2020): > It appears that host.docker always resolves to the DPS container's IP address instead of the host machine IP unless the DPS network is enabled. Confirmed, there's a bug > Maybe there are some scenarios I'm not thinking of right now but falling back to e.g. the `bridge` I think it makes sense > use network X's gateway as the host IP address Yep, it can be used as fallback if bridge network don't exists for some reason, I'm getting the first network listed I've implemented these behaviors

kerem commented

2026-02-26 04:33:58 +03:00

Author

Owner

@mageddo commented on GitHub (Jan 9, 2020):

Fixed, please make a mention if you have some issue.

Regards

@mageddo commented on GitHub (Jan 9, 2020): Fixed, please make a mention if you have some issue. Regards

kerem commented

2026-02-26 04:33:58 +03:00

Author

Owner

@mrubli commented on GitHub (Jan 9, 2020):

After some initial testing everything looks great and works as expected. Thanks a lot for implementing that so soon! 👍

@mrubli commented on GitHub (Jan 9, 2020): After some initial testing everything looks great and works as expected. Thanks a lot for implementing that so soon! 👍

kerem referenced this issue

2026-02-26 04:34:38 +03:00

[PR #73] [MERGED] Update documentation: How to use on Windows/MAC #255