Docker IP to container name for clientLookup

[sn0opy]

I am running several containers on the same host blocky is running on. DNS lookups for these containers are logged by blocky, but unfortunately they appear with their docker-internal ip.

There are projects like dvddarias/docker-hoster which adds containers with specific parameters to a mounted hostfile. Since blocky already has a hostfile lookup, this would be a valid solution.

I was wondering if there's an oversight on my end to provide proper names in my logs/stats for containers, or if this is even a feature that could be added to blocky. This change would not introduce any new dependencies since blocky could read the information directly from the docker socket via standard libs.

[kwitsch]

You could use the internal Docker DNS server to resolve container names if you use docker networks.
Simply forward arpa requests of the internal subnets to 127.0.0.11 and define hostnames during container start or in your compose-file.

Or did I miss the point? 😅

[sn0opy]

It's totally what I want, yes. I was looking for a built-in way in Docker, but was probably looking for the wrong thing. Having a way to do this without defining a hostname would be perfect, but this should work as well.

I went ahead and tested it, but it doesn't seem to register the container's hostname properly or at least it keeps returning NXDOMAIN while requesting IP from within another container. Is there something else that is required to make this work or is it simply not a reliable solution?

[sn0opy]

Guess I am able to answer my own question. Looks like you have to assign them to a custom bridge network as well. The default bridge does not seem to resolve names.

https://docs.docker.com/network/bridge/

User-defined bridges provide automatic DNS resolution between containers.
Containers on the default bridge network can only access each other by IP addresses, unless you use the --link option, which is considered legacy. On a user-defined bridge network, containers can resolve each other by name or alias.

[kwitsch]

Sorry my Docker knowledge outside of swarm-mode is somewhat limited.
Using overlay networks the name resolution works pretty well(most of my dns stack depends on it 😅)

blocky config snippet:

# use recursive service as upstream
bootstrapDns: 127.0.0.11
upstream:
  default:
    - recursive

# use localdaomain service for MAC to hostname mapping
conditional:
  mapping:
    168.192.in-addr.arpa: localdomain
    ddv: localdomain
clientLookup:
  upstream: localdomain

compose file snippet:

x-network-internal:
  &network-internal
  - int
x-network-both:
  &network-both
  - int
  - ext

services:
  # default dns resolution
  recursive:
    image: kwitsch/unbound:monthly
    networks: *network-both
  # Omada DNS server for local domain
  localdomain:
    image: ghcr.io/kwitsch/omadasitedns:0.5
    networks: *network-both
    secrets:
      - OSD_SITE_PASSWORD
    environment:
      - ... # needed env variables
  # blocky as main dns server
  blocky:
    image: ghcr.io/0xerr0r/blocky
    networks: *network-both # internal won't allow ports expose in host mode
    ports: # dns ports in host mode to get client ips
      - target: 53
        published: 53
        protocol: tcp
        mode: host
      - target: 53
        published: 53
        protocol: udp
        mode: host
    configs:
      - source: blocky_config
        target: /app/config.yml

# seperate networks for stack and internet communication
networks:
  ext:
  int:
    internal: true

[0xERR0R]

You could use the internal Docker DNS server to resolve container names if you use docker networks.
Simply forward arpa requests of the internal subnets to 127.0.0.11 and define hostnames during container start or in your compose-file.

Or did I miss the point? 😅

Can it work if containers are assigned to different docker networks (e. g. by using the docker-compose)?

[kwitsch]

You could define an attachable network and atach all services that needs to be resolved to it.
Every service resolves it's name as DNS entry of 127.0.0.11.
Containers without services need a hostname defined as far as i know.

[sn0opy]

So, I was looking into implementing this into its own resolver (similar to the host file resolver) since the configuration "effort" one has to do to get this up and running was quite a lot and requires changes in one's Docker setup (no offense @kwitsch, I appreceate the detailed example you gave).

Initially I thought I could implement this purely by connecting to the socket and reading the returned json, but I decided against it and used the official docker SDK for Go instead. There are other dependencies in blocky, that are probably not used by many (database connections for example) so I thought adding another lib shouldn't hurt that much and it makes development when it comes to error handling and maintenance easier.

I implemented basic functionality in my fork. It's still missing further error handling, documentation and probably some QOL enhancements because people's setups are different and only using the container's name is probably not everyone's preference - especially when it comes to container names in a docker-compose setup.

Before I continue to work on tests and documentation I'd like to know if this is something you're (@0xERR0R) interested in merging into the project or if this is too niche.

My changes so far: development...sn0opy:blocky:feature/docker_resolver

[kwitsch]

This actually looks like a pretty nice feature. 👍

Skimmed over your changes and have some suggestions:

• as the docker socket could be external an option for a bootstrap DNS resolver may be necessary
• consider also indexing overlay networks for swarm mode compatibility
• it would be handy if the resolver could be used for bootstrap resolving other resolvers

[0xERR0R]

I think, I got the idea from your docker resolver implementation. But I think, you want to resolve the clientName (with client name resolver), do you use blocky itself as client resolver?
Maybe it would make sense to implement the reverse name resolution as a standalone service, like https://github.com/0xERR0R/fritzbox-rdns? This can run independently and must be configured in blocky as client names resolver.

Regarding the implementation: it is a good idea to use the library and not to parse the JSON. It would also make sense to use docker event listener to be notified if a new container was started etc., in this case the periodical reload is not necessary.

[sn0opy]

Sorry for the late response. You're right. My main intention was to resolve client names for proper statistics. Resolving docker's internal IPs in the wohle network could even result in funky behaviour with docker running on other machines on the same network.

I found this project with already implements a docker DNS resolver based on container names: https://github.com/phensley/docker-dns

Blocky has no way to configure multiple client resolvers since upstream.host must be a single host address, right? As far as I know conditional.mapping isn't even used by blocky itself to resolve client names and it would make docker's IPs resolvable "globally" again.

Is there an existing way to add a 2nd upstream? Chaining requests would make things kinda complicated again in my opinion. Like blocky -> docker-dns -> router

[0xERR0R]

Currently, you can define only one rDNS server for client lookup. Maybe we should make it more configurable:

• Configuration with multiple rDNS, blocky should try with first and if result is negative, use second as fallback and so on
• Configuration for subnet: for example use rDNS X for 192.168.x.x and rDNS Y for 172.100.x.x

[sn0opy]

Probably blowing up the main purpose of this conversion, but would you prefer a backward compatible configuration for upstream or should it become a list/map without being backward compatible?

My Go skills are somewhat rusty but I may look into it.

[ThinkChaos]

You should be able to use the same trick as was used for BootstrapConfig (and others) to use a list/map and be backwards compatible, see here for an example.