No description
- Go 100%
| dns | ||
| docker | ||
| edns | ||
| go.mod | ||
| LICENSE.md | ||
| main.go | ||
| README.md | ||
container-resolved-go
What's this?
This is a go service that listens on a docker event stream and exposes a DNS service with A/AAAA RRs for each running container per docker network.
DO NOT use this on a public dns server / resolver. It is expected that this may only be used on a local docker deployment.
The exposed DNS RRs are grouped by docker network name below the domain in-docker.internal. and look somewhat like this:
container_name.network_name.in-docker.internal. A 172.25.1.2
alias.network_name.in-docker.internal. AAAA 2a02:F00:BA4::1:2
container_name.backend_network.in-docker.internal. A 192.168.42.2
Why 'tho?
- I wanted sane dns resolution from the docker host to docker containers.
- nss-docker isn't quite enough, if it works at all.
- DNS operations are well understood. Automagic name resolution via nss leads to unexpected behavior, if container name vanished and queries fall back to dns.
- Using DNS subdomains docker container and aliases are structured on a per network name basis.
- Your networking, routing and firewalling decides if you're able to reach the container interfaces.
- Passing a different docker socket and alternative domain zone name can support multi-docker-setups.
Remarks
Input sanitization of user controlled values
Special chars and punycode is currently not support. Please use sane aliases on your deployments.
Currently used .internal TLD
This is currently used since it should never be resolved in the internet.
Since it could be used in a private / enterprise context, it could be conflicting existing setups.
I'm very open to discuss if a .in-docker TLD would be a sane idea.