Container Doing All DNS Lookups For Containers AND Host

Hello. This is my first post. I hope it abides by all the rules.

There is a single host scenario I’m looking at. I have a user-defined bridge network - let’s call it “net1” - which works very well (the container name resolution is such a great feature).

Without much success, I’ve been doing some trial and error on adding a new container to net1 which is a caching, forwarding DNS-over-TLS resolver. The best way to do this is via two applications: unbound as the cache and stubby as the stub-resolver (one could use only unbound but the stubby lookups are better handled) so in practice there will be two containers but for the purposes of this question, I believe it’s okay to assume I’m only adding one container that provides all the functionality (however, I will divide it up in reality).

I want this container to: (i) resolve all DNS lookups for other members of net1; (ii) resolve all DNS lookups for the host (this raises a docker-compose question - which is not my central enquiry - but would I need to restructure the compose files for the existing containers to include a “depends on” section for the DNS container. I’d really like to avoid this).

To be honest I’m a bit stuck. If I took the host out of the equation, perhaps I could mount a new “/etc/resolv.conf” file into each container (assuming it would override the embedded DNS) with a single line saying “nameserver dns-container” (am I right in presuming “dns-container” would resolve to an IP address when used in the resolv.conf file or would I need to add something like “dns-container dns-container” to “/etc/hosts”). Or I seem to remember the compose file can take a “dns” entry specifying the resolver. However, I don’t know how to direct the host’s lookups to "dns-container". I have some thoughts on how this should work but haven’t managed to pull it together. Ideas include:
I - create a new bridge to which the host is attached and route that subnet to net1 (this would have to have container name resolution though, if I start using fixed IPs it’s going to become very clunky).
II - modifying the “/etc/hosts” file on the host but tbh, this is just a guess and, again, it’s no good if it requires a fixed IP
III - perhaps there is some docker DNS functionality which can help me; I’ve been through the compose reference guide several times but couldn’t see anything that applies to this, likewise re. the networking sections
IV - there’s macvlan and while I know that, out-of-the-box, it prevents host-container communication I believe that can be ‘bridged around’. However this brings in fixed IPs.
V - abandon “dns-container” and implement it all on the host - that would definitely work but I want to do this with containers - to learn and because no DNS cache is going to object to an extra level of isolation :slight_smile:

In summary then here are both the things I want to do:

net1 container                       host
     |                                 |
     |                                 |
dns-container                        net1
     |                                 |
     |                                 |
pub. recursive dns               dns-container
                                       |
                                       |
                                  pub. recursive dns

Perhaps I am missing something really fundamental but this doesn’t seem like a complicated set up yet I found no references to it on the web and feel I may be missing something obvious. Oh, one other thing: I appreciate I could use ‘host’ network mode but I want to stick with the bridge.

I’m seriously curious as to how/if this can be done so any and all replies would be most welcome. For reference, my compose file is below (assume the indentations are correct) although it’s basically unchanged from the one that the image builder provided (the ports will need to change plus whatever else).

=============================
version: ‘3.2’
services:
stubby:
image: “mvance/stubby:latest” container_name: “stubby”
networks:
- net1
volumes:
- type: bind
source: /home/adam/docker/unbound-stubby/stubby.conf
target: /opt/stubby/etc/stubby/stubby.conf:ro
restart: unless-stopped
unbound:
image: “mvance/unbound:1.9.1-stubby” container_name: “unbound”
depends_on:
- “stubby”
ports:
- “53:53/udp”
networks:
- net1:
volumes:
- type: bind
source: /home/adam/docker/unbound-stubby/unbound.conf
target: /opt/unbound/etc/unbound/unbound.conf:ro restart: unless-stopped networks:
net1: