Docker container not using host /etc/resolv.conf

I think what you are hitting here is a subnet conflict between OpenVPN's subnet, and local subnets that docker uses for containers internally. If you do ip addr and look for the bridge adapter that docker has created for your network, you will find a subnet range it has allocated to that bridge. Commonly it is 172.20.0.1/16 which will overlap your OpenVPN subnet. As that makes the OpenVPN DNS IP addresses "local to docker", it is removing them from the container's /etc/resolv.conf.

If you have multiple docker networks and don't know which bridge you should be looking at, you can do docker network list and take the network ID and prefix it with br0. For example a docker network with ID 28881c0a72ad is serviced by bridge adapter br0-28881c0a72ad.

There are a few solutions to this issue. One option is to change the default pool of addresses docker will use, by setting it in daemon.json:

vi /etc/docker/daemon.json
{
  "default-address-pools" : [
    {
      "base" : "172.240.0.0/16",
      "size" : 24
    }
  ]
}

Once done, restart your docker daemon to reconfigure the default network. Other networks will need to be deleted and recreated. Another solution is to create placeholder network that covers the range:

docker network create --driver=bridge --subnet 172.18.0.0/24 openvpn

Future networks created by docker-compose or similar tools will then not allocate to that subnet.

The resolv.conf file appears to be getting updated by multiple daemons, systemd and resolvconf. You may need to restart the docker daemon to pickup changes to the resolv.conf file after the latest change.

Once that's done, the second sentence (and following paragraph) explain the difference in the nameserver lines for anyone with a 127.0.0.1 nameserver:

Docker makes each container’s /etc/resolv.conf look like the /etc/resolv.conf of the host machine (where the docker daemon runs). When creating the container’s /etc/resolv.conf, the daemon filters out all localhost IP address nameserver entries from the host’s original file.

With your scenario, the docker engine may be configured with different name servers. There are various locations this value can be injected. If it's done in the systemd config files, then systemctl show docker | grep ExecStart should show an argument. Or it can be set with the /etc/docker/daemon.json file.

For other's that experience this issue, docker runs a DNS server internally that relays to servers (with the exception of localhost) for containers in user created networks. So a resolv.conf file with 127.0.0.53 will be expected when you don't use the default bridge. This allows containers to resolve each other using DNS.