The ECS assertion grepped for `edns0-client-subnet`, which matches the substring inside Google's *negative* reply "edns0-client-subnet was not used". So the test's green state was Google telling us ECS was not used, and it never verified ECS at all. The sut container's address is 172.18.0.2, so unbound forwards 172.18.0.0/24 upstream. Authorities won't use an RFC1918 prefix, hence the "was not used" answer. Whether that answer reaches the client is up to Google's anycast fleet: if the reply echoes the ECS option unbound keeps it and the substring matches, but if the reply omits the option unbound logs "Authority indicates no support", re-resolves without the subnet, and returns a single TXT record with no substring to match. Both are RFC 7871-legal, so re-running just rolled the dice again -- roughly half the Test docker jobs failed on this line, on every platform. Have the client supply a routable prefix via +subnet instead, and assert that unbound echoes the option back. unbound returns a CLIENT-SUBNET option whenever the client sent one -- with the upstream scope, or scope 0 via cp_edns_bad_response when upstream declines -- so the assertion no longer depends on any authority's ECS policy. It also fails when the subnet module is absent, which the old one could not. Signed-off-by: Kyle Harding <kyle@balena.io>
unofficial unbound multiarch docker image
Unbound is a validating, recursive, and caching DNS resolver.
Note that this image is distroless!
"Distroless" images contain only your application and its runtime dependencies. They do not contain package managers, shells or any other programs you would expect to find in a standard Linux distribution.
Usage/Examples
Run a recursive dns server on host port 53 with the default configuration.
docker run --name unbound \
-p 53:53/tcp -p 53:53/udp \
klutchell/unbound
Optionally mount
custom configuration
from a host directory. Files must be readable by user/group 101:102 or world.
docker run --name unbound \
-p 53:53/tcp -p 53:53/udp \
-v /path/to/config:/etc/unbound/custom.conf.d \
klutchell/unbound
Optional: Enable CacheDB Module with Valkey (Redis-compatible) backend
The cache DB module was compiled into daemon, but is disabled by default. To enable this module, follow this steps:
- You will need a Redis-protocol-compatible backend (e.g. Redis or Valkey) running and reachable from the Unbound container; see examples/redis for a full docker-compose example;
- Create a
cachedb.confunder your custom configuration directory/path/to/config/custom.conf.d; - Add a
serverdirective with module configuration to enablecachedbmodule; - Add a
cachedbdirective with Valkey (Redis-compatible) credentials;
server:
module-config: "validator cachedb iterator"
cachedb:
backend: "redis"
redis-server-host: valkey
redis-server-port: 6379
redis-expire-records: yes
Files must be readable by user/group 101:102 or world.
Examples of docker-compose usage can be found in examples.
License
This software is licensed under the BSD 3-Clause License.
Original software is by NLnet Labs: https://unbound.net