moby: --dns and --net=host should not be mutually exclusive

I understand that docker will attempt to do what it thinks is best with my container’s /etc/resolv.conf, such as when in --net=host mode and using the host’s resolv.conf, or by replacing 127.0.0.1 when that is seen. I also understand that --dns is a wonderful way to be explicitly sure about what’s in your container’s resolv.conf:

# docker run -it --dns=1.2.3.4 ubuntu cat /etc/resolv.conf                             
search ...
nameserver 1.2.3.4

However, I would like to run a container with --net=host, and I want to tell the container what it’s upstream DNS servers are, so I go to use the --dns parameter with docker run/etc, but docker errors out:

# docker run --dns=127.0.0.1 --net=host -it ubuntu bash
WARNING: Localhost DNS setting (--dns=127.0.0.1) may fail in containers.
Error response from daemon: Conflicting options: --dns and the network mode (--net)

Why does docker get confused about which detail is more important, but then goes on to block me from resolving its confusion. Or am I overlooking something painfully obvious?

To add to the insult from docker, it’ll happily accept DOCKER_OPTS="--dns=127.0.0.1" provided to the daemon, and even use that as expected when in --net=host mode.

Here is an example with an empty DOCKER_OPTS:

$ docker run -it --net=host ubuntu cat /etc/resolv.conf                                
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
search ...

nameserver 8.8.8.8
nameserver 8.8.4.4

Versus this, when DOCKER_OPTS has --dns=127.0.0.1:

$ docker run -it --net=host ubuntu cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search ...

From my perspective, blocking users from using --dns with --net=host seems arbitrary and wrong, do others agree?