starred/dns-proxy-server-mageddo

Fork 0

mirror of https://github.com/mageddo/dns-proxy-server.git synced 2026-04-25 17:35:54 +03:00

[GH-ISSUE #89] Resolving container using an address from a specific network. #42

New issue

Closed

opened 2026-02-26 04:33:52 +03:00 by kerem · 8 comments

kerem commented

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

Owner

Originally created by @wzsanders on GitHub (Oct 16, 2018).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/89

The DNS server picks an IP address arbitrarily from one of two connected networks in docker compose.

To Reproduce
Steps to reproduce the behavior:

Start proxy container using docker-compose.
Start other container using docker-compose with two external networks.
Attempt to ping the container using its host name.
I can ping it, but it proxy resolves the IP address using the wrong network, (network1 instead of network2)

Expected behavior
I want it to resolve the IP using a network of choice, or override it in the web interface.
If it was resolving using an IP in network1, I want it to resolve with an IP in network2.
Example:
ping containername.{domain} (172.40.200.3) becomes (172.10.0.2)

Specs:

OS: Manjaro, kernel 4.19.0-1MANJARO
Docker Version: 18.06.1-ce
DPS Version: 2.7.0

Originally created by @wzsanders on GitHub (Oct 16, 2018). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/89 The DNS server picks an IP address arbitrarily from one of two connected networks in docker compose. **To Reproduce** Steps to reproduce the behavior: 1. Start proxy container using docker-compose. 2. Start other container using docker-compose with two external networks. 3. Attempt to ping the container using its host name. 4. I can ping it, but it proxy resolves the IP address using the wrong network, (network1 instead of network2) **Expected behavior** I want it to resolve the IP using a network of choice, or override it in the web interface. If it was resolving using an IP in network1, I want it to resolve with an IP in network2. Example: ping containername.{domain} (172.40.200.3) becomes (172.10.0.2) **Specs:** - OS: Manjaro, kernel 4.19.0-1MANJARO - Docker Version: 18.06.1-ce - DPS Version: 2.7.0

kerem

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

closed this issue
added the
feature
label

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Oct 16, 2018):

@wsanders99 thanks for your contribution, this really is the actual behavior. I think make user able to specify the nework can be a great feature, anyway I don't know how to expose that feature friendly, we can discuss about that.

You said about user choose the network at the graphic interface, it works, but I'm thinking if there is a better way to do that, cause if user have to choose the right network every time then it will be so tedious.

A proposal, we can add the network to hostname as a suffix, example

$ docker network create network1
$ docker network create network2
$ docker run --rm --hostname acme.com --network network1 --network network2 nginx

then you can solve your hostname as it is today

$ nslookup acme.com
Server:		13.0.0.7
Address:	13.0.0.7#53

Non-authoritative answer:
Name:	acme.com
Address: 172.25.0.2

Or you can specifcy from which network you want to solve it

nslookup acme.com.network1
Server:		13.0.0.7
Address:	13.0.0.7#53

Non-authoritative answer:
Name:	acme.com.network1
Address: 172.30.0.1

What you think about that, it solves your problem?
Another question: are you trying to solve that hostname from host machine or from another docker container?

@mageddo commented on GitHub (Oct 16, 2018): @wsanders99 thanks for your contribution, this really is the actual behavior. I think make user able to specify the nework can be a great feature, anyway I don't know how to expose that feature friendly, we can discuss about that. You said about user choose the network at the graphic interface, it works, but I'm thinking if there is a better way to do that, cause if user have to choose the right network every time then it will be so tedious. A proposal, we can add the network to hostname as a suffix, example ```bash $ docker network create network1 $ docker network create network2 $ docker run --rm --hostname acme.com --network network1 --network network2 nginx ``` then you can solve your hostname as it is today ```bash $ nslookup acme.com Server: 13.0.0.7 Address: 13.0.0.7#53 Non-authoritative answer: Name: acme.com Address: 172.25.0.2 ``` Or you can specifcy from which network you want to solve it ```bash nslookup acme.com.network1 Server: 13.0.0.7 Address: 13.0.0.7#53 Non-authoritative answer: Name: acme.com.network1 Address: 172.30.0.1 ``` 1. What you think about that, it solves your problem? 2. Another question: are you trying to solve that hostname from host machine or from another docker container?

kerem commented

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

Author

Owner

@wzsanders commented on GitHub (Oct 17, 2018):

That would work, although it creates longer urls.

My use case is for routing to services behind a reverse proxy like traefik. These requests are coming from another container with net_admin capabilities.
It resolves correctly from the host since it can see all networks.

Since the reverse-proxy has the host name as '.acme.com' from your example
Links for services would now be in these forms, correct?

service1.acme.com.network1
service2.acme.com.network1
service3.acme.com.network1

I am assuming that without the suffix, it just does what it is already doing.

This solution meets the requirements for allowing the user to choose the network that it resolves from.

However, the solution I really want is to be able to set the default network, i.e without adding the suffix to the address bar (if you want to override the default network, then I think this a solution there too).

compose example

version: '3'
services:
  proxy:
    image: {proxy}
    hostname: .acme.com
    networks:
       network1:
       network2:
    labels:
       - "{dns-proxy-identifier}.network=network1"

Then it would resolve to 172.30.0.1 as it does when having network1 as the suffix in your example when using these links.

service1.acme.com
service2.acme.com
service3.acme.com

And to change the network after changing the default, append the suffix manually as .network2, etc.

@wzsanders commented on GitHub (Oct 17, 2018): That would work, although it creates longer urls. My use case is for routing to services behind a reverse proxy like traefik. These requests are coming from another container with net_admin capabilities. It resolves correctly from the host since it can see all networks. Since the reverse-proxy has the host name as '.acme.com' from your example Links for services would now be in these forms, correct? - service1.acme.com.network1 - service2.acme.com.network1 - service3.acme.com.network1 I am assuming that without the suffix, it just does what it is already doing. This solution meets the requirements for allowing the user to choose the network that it resolves from. However, the solution I really want is to be able to set the default network, i.e without adding the suffix to the address bar (if you want to override the default network, then I think this a solution there too). compose example ``` version: '3' services: proxy: image: {proxy} hostname: .acme.com networks: network1: network2: labels: - "{dns-proxy-identifier}.network=network1" ``` Then it would resolve to 172.30.0.1 as it does when having network1 as the suffix in your example when using these links. - service1.acme.com - service2.acme.com - service3.acme.com And to change the network after changing the default, append the suffix manually as .network2, etc.

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Oct 17, 2018):

Okay, I think we can build a great feature with these two options.

To make it clear for me, you proposal is that every container could set it's default network by specifying a label like {dns-proxy-identifier}.network=network1?

@mageddo commented on GitHub (Oct 17, 2018): Okay, I think we can build a great feature with these two options. To make it clear for me, you proposal is that every container could set it's default network by specifying a label like `{dns-proxy-identifier}.network=network1`?

kerem commented

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

Author

Owner

@wzsanders commented on GitHub (Oct 17, 2018):

Yes, that is my proposal. I very much appreciate you looking into this.

@wzsanders commented on GitHub (Oct 17, 2018): Yes, that is my proposal. I very much appreciate you looking into this.

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Oct 17, 2018):

Okay, I will probably break this feature into two stories and priorize to develop the "ability to set default network on container start" first.

It's important to say and you probably already figured that out, as you are calling one container(service1) from another (reverse proxy) then both of them must be on an common network.
It's probably why you want DPS to solve container IP from another network

@mageddo commented on GitHub (Oct 17, 2018): Okay, I will probably break this feature into two stories and priorize to develop the "ability to set default network on container start" first. It's important to say and you probably already figured that out, as you are calling one container(service1) from another (reverse proxy) then both of them must be on an common network. It's probably why you want DPS to solve container IP from another network

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Oct 17, 2018):

@wsanders99 I just released 2.8.0 can you check it out and confirm if works for you? If yes then we can close this issue

@mageddo commented on GitHub (Oct 17, 2018): @wsanders99 I just released [2.8.0](https://github.com/mageddo/dns-proxy-server/releases/tag/2.8.0) can you check it out and confirm if works for you? If yes then we can close this issue

kerem commented

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

Author

Owner

@wzsanders commented on GitHub (Oct 17, 2018):

Sorry for the delay.

I have pulled the new image and added the label dps.network={network} to my compose file.

After testing I have determined that it produces the expected behavior depending on the network set in the label.
Thank you for your quick response and implementation.

@wzsanders commented on GitHub (Oct 17, 2018): Sorry for the delay. I have pulled the new image and added the label `dps.network={network}` to my compose file. After testing I have determined that it produces the expected behavior depending on the network set in the label. Thank you for your quick response and implementation.

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Oct 17, 2018):

You're welcome

@mageddo commented on GitHub (Oct 17, 2018): You're welcome

kerem referenced this issue

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

[PR #43] [MERGED] Local Resolution Optimizations #241

kerem referenced this issue

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