@anvu, short version:
Container here has nothing to do with being a DNS Server. If you think that when RouterOS is going to start a container, it needs to set the IP address/subnet mask/gateway and a DNS server. Typically containers don’t use DHCP to get their network settings – so the VETH setting are what’s inside container for ip-address/netmask/gateway. But how the DNS works inside a container, see the long version to answer the questions:
Q1. Did the solution you found to your issue, mean that the Container bypasses DOH for DNS and goes to the router to DND and then out to the internet?
The OP isn’t running a DNS Server in the container. But has a Linux application inside the container that needs to do DNS lookups. Like any server/desktop, it needs a DNS server to use. The DNS servers a container initially uses are set by RouterOS settings for the container. This can be set explicitly using “DNS Server” in winbox for a container; or if empty, the container will uses the router’s DNS IP address. If you’re not using DoH, this all works dandy.
The issue here is what if you don’t set DNS for the container, and the Mikrotik DNS has not IP addresses for a DNS server? This happens if RouterOS’s DNS is using DoH since it wouldn’t have IP addresses for DNS – as setting a DoH server supersedes any IP ones. Since the container DNS settings can only be “regular” DNS (e.g. using port 53, and generally UDP) IP addresss, a DNS Server IP to be used by the container’s code needs to be set explicitly in the container’s settings.
But a container can also modify its own configuration, including DNS, after install. So for something like Pi-Hole, you’d typically set the upstream DNS in those container’s web GUI (or via environment variables to container).
Q2. If not, how did you get the containers traffic to through DOH?
The idea is the regular DNS is fine internally. It’s actually faster since than DoH. But with regular DNS on port 53, the domain names being looked up aren’t encrypted. This isn’t a problem for DNS lookup from a container to the RouterOS running it. So why the container uses port 53 DNS to RouterOS’s DNS server here. And the RouterOS’s DNS does the DoH over the internet – where you’d care about hiding the domain name being looked up.
(Alpine container) --port 53/udp–> (Mikrotik DNS) --port 443/tcp–> (Internet) → DoH DNS Server
Q3. Why not run docker container for adguard for example instead of DOH?
OP’s case wasn’t about the container to be a DNS Server – it just needed an upstream one to work. But nothing would stop anyone from running a 2nd container that run Pi-Hole or Ad-Guard for ad-blocking. And inside those containers web GUI you can set the upstream DNS to use a DoH server. So the Alpine container (or ThingsBoard) could use a DNS server that lives in another container as the DNS server. e.g.
(Alpine container) --port 53/udp–> (Pi-Hole DNS) --port 443/tcp–> (Internet) → DoH DNS Server
Or more indirectly, RouterOS DNS could be used, as shown in the OP’s case with Pi-Hole/etc container upstream of the Mikrotik DNS
(Alpine container) --port 53/udp–> (Mikrotik DNS) --port 53/udp–> (Pi-Hole DNS) --port 443/tcp–> (Internet) → DoH DNS Server
Q4. Can you run DOH and adguard from within a docker/container IS THERE such a combo beast?
Basically you set DoH on the adguard/pi-hole admin web pages. So those will take care of the DoH.
Alpine is very minimum, so it doesn’t have “direct” DoH support. But other containers based on “regular Linux” like Ubuntu or Debian, you can install a package inside the container that does DoH resolution directly from the container. This is essentially what Pi-Hole (and other ad-blocking containers) do:
(Pi-Hole container) --port 443/tcp–> (Internet) → DoH DNS Server
Now if you want the rest of your network so using the IP address of the Ad-blocking Ubuntu container as the DNS Server, you the container’s IP address as DNS in your DHCP server’s network settings.
(LAN client doing DNS) --port 53/udp–> (RouterOS’s DNS) --port 53/udp–> (Pi-Hole container) --port 443/tcp–> (Internet) → DoH DNS Server
But in this case, you do have the firewall to configure for sure. And since Pi-Hole/etc may need DNS initially, you may need to explicit set the DNS Server for Pi-Hole/etc in the container setting to a real DNS server like 8.8.8.8, 1.1.1.1, 208.67.222.222.222, or 9.9.9.9 depending on your religion – you can’t have Pi-Hole/etc pointing to Mikrotik DNS and the Mikroitk DNS pointing to Pi-Hole.
Overall… Like the OP saw, the firewall for container’s IP/VETH/Bridge can get confusing & easily dropped since in default container’s bridge/VETHs are by default “!LAN” in /ip/firewall/filter.