Docker executor: invalid dns/mac_address config now fails jobs instead of being silently ignored (moby v29 migration)

Summary

Any project using the docker executor where a runner's config.toml has [runners.docker] dns = [...] or mac_address = "..." set to something that isn't a valid IP address / MAC address will start failing jobs once MR !6902 (Docker SDK migration to moby v29, required to fix CVEs in docker/docker and docker/cli) ships. Filing proactively before release so support and release notes are aware ahead of time, rather than after the first customer report.

Introduced by: !6902 (merged). Not yet released — no milestone assigned at time of writing.

What changed

Previously, whatever string was in dns = [...] or mac_address = "..." was forwarded to the Docker daemon completely unvalidated. A typo or a hostname (instead of an IP) in dns didn't error — it just silently produced a broken /etc/resolv.conf in the build container, which usually surfaced later as a confusing DNS-resolution failure inside the job script, not at container creation. mac_address behaved the same way — no confirmation this was even correct until asked.

As of !6902 (merged), both fields are now parsed and validated before the container is created (forced by an upstream change: moby v29's HostConfig.DNS field is now typed []netip.Addr instead of []string, so free-form strings can no longer be passed through even if we wanted to). An invalid entry now fails the job immediately, before any script runs.

What the customer will see

For an invalid dns entry (e.g. dns = ["my-dns-server"] instead of an IP):

ERROR: Job failed (system failure): prepare environment: invalid DNS server address "my-dns-server": ParseAddr("my-dns-server"): unable to parse IP

For an invalid mac_address (e.g. a malformed MAC string):

ERROR: Job failed (system failure): prepare environment: invalid MAC address "<value>": address <value>: invalid MAC address

The job fails at the "Preparing environment" stage — before Getting source from Git repository — so no job script output will be visible at all.

Note on failure_reason: at initial release this will report as runner_system_failure (shown above as "system failure"), which is misleading — this is a user configuration problem, not a runner malfunction. A follow-up fix (MR !6942, draft, not yet merged) reclassifies it to runner_configuration_error. Until that lands, support should treat the exact error text above (invalid DNS server address / invalid MAC address) as the reliable signal, not the failure reason field.

How to confirm this is the cause

Grep the job trace (or ask the customer) for invalid DNS server address or invalid MAC address. If present, the fix is entirely on the customer's side.

Fix for the customer

Correct the dns/mac_address value in the runner's config.toml under [runners.docker] to a valid IP address / MAC address. There is no runner-side workaround — the value must be valid, since it's no longer possible to forward an invalid one to the daemon at all.

Why this can't be reverted

The type change is forced by the upstream moby v29 client, which is required to fix the underlying CVEs tracked in https://gitlab.com/gitlab-org/gitlab-runner/-/issues/39536. There is no version of this fix that preserves the old permissive behavior.

Related