38 lines
1.7 KiB
Markdown
38 lines
1.7 KiB
Markdown
# `docker-zonefiled`
|
|
|
|
## What's this?
|
|
|
|
This generates DNS zone files containing DNS hostnames and aliases of running docker containers in all docker networks for a given docker host.
|
|
|
|
It generates zone files 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
|
|
```
|
|
|
|
This is currently implemented as an trivial simple bash script utilizing `docker events` for listening on changes, `docker container inspect` to query the network details and some `jq` magic.
|
|
|
|
## Why 'tho?
|
|
|
|
- I wanted sane dns resolution from the docker host to docker containers.
|
|
- nss-docker isn't enough or working.
|
|
- DNS operations are well understood. Automagic name resolution via nss leads to unexpected behavior, if container name vanished and queries drop down to dns.
|
|
- Using DNS subdomains host and aliases are structured per network name.
|
|
- 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
|
|
|
|
Specially grafted host and alias names of docker containers can inject stuff in the generated zone file, I guess.
|
|
I'm currently open to discuss, how to catch invalid characters in host names.
|
|
|
|
|
|
### 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.
|