RouterOS version: 7.23.3 (stable)
Board: RB5009UG+S+ (arch: arm64, board name "nextstep")
Feature: Container (/container)
SUMMARY
Containers get their /etc/resolv.conf nameserver from the container's
"default-dns" property, which is populated once at container start
from whatever RouterOS currently considers the active DNS server
(/ip dns dynamic-servers, when no static /ip dns servers are set).
Two problems:
-
"default-dns" cannot actually be changed, but /container/set
accepts the command without any error. -
Even when the underlying DNS server later becomes reachable again,
an already-running container never picks up the change - the value
is frozen at container start with no built-in refresh/retry, and
there is no supported way to override it to a different, more
stable resolver (e.g. the router's own LAN address).
ISSUE 1 - /container/set default-dns= is silently ignored
Steps to reproduce:
/container/print detail where name="kamailio"
-> default-dns=10.11.179.160
/container/set [find name="kamailio"] default-dns=10.10.66.1
-> command returns with no error
:put [/container/get [find name="kamailio"] default-dns]
-> still prints 10.11.179.160 (unchanged)
Also reproduced with the container fully stopped first
(/container/stop, then /container/set, then /container/get) -
same result, value never changes.
Expected behavior: either the property is genuinely settable and
persists the new value, or (if it is meant to be read-only /
derived from /ip dns) the "set" command should reject it with an
explicit error instead of silently accepting a no-op. As it stands,
an administrator has no indication the change failed.
ISSUE 2 - no refresh/retry mechanism for container DNS after boot
Real-world scenario that surfaced this:
- Router loses power for an extended period (ISP link + router
both down). - Router boots before the WAN/ISP link is back up. A container
with start-on-boot=yes starts at this point. - RouterOS writes the container's resolv.conf using the DNS
server IP that was active in /ip dns at that instant (an
ISP-assigned dynamic server). Since the WAN was not yet up,
name resolution inside the container fails. - WAN comes back up minutes later. /ip dns on the router itself
resolves correctly again (verified with ":resolve" from the
router CLI). - The already-running container's DNS resolution keeps failing
indefinitely - the resolv.conf baked in at step 3 is never
regenerated or re-checked. Only a manual container restart
fixes it.
This means a purely transient, already-resolved connectivity issue
at boot time causes a permanent (until manual intervention) DNS
outage inside any long-running container - even though the router's
own DNS proxy/resolution has been working fine for a long time by
that point.
Also attempted as a workaround: overriding the container's launch
command via the "cmd" property to run a custom entrypoint script
that would rewrite /etc/resolv.conf before starting the main
process. This does not work either, because "cmd" is appended to
the image's existing ENTRYPOINT rather than replacing it (confirmed
in the container log: the process was launched as
"kamailio -DD -E /bin/sh /etc/kamailio/entrypoint.sh", i.e. the
custom script was passed as a stray argument to kamailio instead of
being executed). There is no "default-entrypoint" override either
(/container/set ... default-entrypoint=... returns "bad parameter").
SUGGESTED FIX
- Make "default-dns" genuinely user-settable (e.g. allow pinning it
to the router's own address, such as the veth gateway or LAN IP,
so the container always queries RouterOS's own DNS proxy instead
of a raw upstream IP) - or clearly document it as read-only and
reject attempts to set it. - Regenerate/refresh the container's resolv.conf whenever /ip dns's
effective server changes, or at minimum on every container
(re)start even if that restart wasn't triggered by the mount
reload - and ideally provide a periodic re-check, since a
container may run for a very long time without restarting.
CURRENT WORKAROUND IN USE
For our use case we worked around this using the container's
"hosts" property (/container/set ... hosts="=") to
statically pin the one hostname our application depends on,
bypassing DNS resolution entirely for that destination. This is
only a viable workaround for a small number of known, stable
hostnames - it does not help for containers with broader/dynamic
DNS needs (e.g. package manager repositories on first install).
