build: install bind9-dnsutils instead of the virtual dnsutils

[joshiste]

What

The runtime image installs dnsutils to get dig. Since the bind9 9.16 packaging split, dig lives in bind9-dnsutils — which is what the deb package already depends on (.goreleaser.yaml). This aligns the Dockerfile with it. Same change as steadybit/extension-host#249.

Why it matters

On the image's own base, debian:13-slim, dnsutils is a pure virtual package:

$ docker run --rm debian:13-slim apt-cache policy dnsutils
dnsutils:
  Installed: (none)
  Candidate: (none)          # <-- no version at all

apt-get install dnsutils works there only because apt resolves a virtual package when exactly one package provides it, and bind9-dnsutils is currently the sole provider (apt-get install -s dnsutils confirms that is what gets pulled). A second provider appearing, or Debian dropping the Provides, turns the build into Package 'dnsutils' has no installation candidate.

Compatibility

bind9-dnsutils is a real, versioned package everywhere still supported — checked by querying apt in each image:

Release	bind9-dnsutils	dnsutils
Ubuntu 20.04	1:9.18.30	1:9.18.30
Ubuntu 22.04	1:9.18.39	1:9.18.39
Debian 11	1:9.16.50	1:9.16.50
Debian 12	1:9.18.49	1:9.18.49
Debian 13	1:9.20.26	no candidate (virtual)

Only Debian 10 / Ubuntu 18.04 ever had dnsutils alone, and both are long EOL.

Verification

Installed the full new package list in debian:13-slim and confirmed every binary the extension execs is present: dig → /usr/bin/dig, plus ip, tc, iptables-restore, fallocate, capsh, stress-ng.

No runtime behaviour change — the same package ends up installed either way today. Prefixed build: so it doesn't trigger a patch release on its own.

[claude]

Claude finished @joshiste's task in 24s —— View job

---

Review of PR #496

• Check for previously unresolved Claude review threads
• Review the Dockerfile change
• Post final review

No unresolved prior review threads to address.

Change: Dockerfile:69 swaps dnsutils → bind9-dnsutils in the runtime image's apt-get install line.

This is correct and low-risk:

• The runtime base image is debian:13-slim (Dockerfile:45), which matches the PR's finding that dnsutils is a virtual package there with no installation candidate — bind9-dnsutils is the real, versioned package that provides dig.
• bind9-dnsutils is a strict drop-in today (single provider of the virtual dnsutils package across all currently supported Debian/Ubuntu releases per the PR's compatibility table), so there's no behavioral change, just a more resilient/explicit dependency.
• Consistent with the same fix already applied in steadybit/extension-host#249.
• No security, performance, or concurrency concerns — this is a one-line build dependency fix.

Nothing else to flag.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud