Authoritative Dnsmasq in a MikroTik Container

This post is about setting up and configuring a dnsmasq container on a MikroTik RouterOS device to be used as an authoritative DNS server and a forwarding cache at the same time.

Recently I joined DN42 , a world-wide overlay network created for experimenting with IP routing and for connecting communities, hack-spaces, and networking nerds who are not allowed 😜 to break the real Internet.

I wanted to play on hard mode, so I configured the DN42 tunnels in a VRF on my home lab switch, a MikroTik RB4011. And of course I wanted to provide authoritative DNS for my .dn42 zone from the same switch.

MikroTik routers come with a built-in DNS service, but it can't act as an authoritative server, and there is a shared DNS cache for all clients, which would leak my home lab to DN42.

I already run prosody and iperf on my switch, so the "obvious" "solution" was to add another container.

MikroTik routers with ARM and ARM64 CPUs support Docker containers . The manufacturer strongly recommends using external USB / SD card storage to not wear out internal flash. Ignoring that recommendation might cause the flash in your router to fail and turn the router into an expensive paperweight .

The RB4011 doesn't have USB or SD ports, and adding NVMe looks complicated . It is possible to use the Storage package to mount remote disks, but I hate circular dependencies between my devices. Then again, people reports millions of flash writes , so I'm going to YOLO my containers on the internal 512MB flash, using /docker for the images and volumes.

Nevertheless, if you look for a MikroTik router to run containers, maybe pick one with ARM64 and a physical storage port .

Enabling containers requires a walk to the switch to ensure physical presence, and will increase your attack surface. Then we can configure it to fetch from Docker Hub, which gives us access to some 117k ARM images :

/ container config set registry -url = https :// registry -1 .docker.io tmpdir =/ docker Installing a dnsmasq container I've settled with the dockurr/dnsmasq image based on Alpine which needs around 12MB of flash space. It accepts DNS1 to DNS4 from the environment and allows to bind-mount /etc/dnsmasq.d for additional config files:

/ container envs add key = DNS1 list = ENV_DNSMASQ value = fd42 : d42 : d42 : 54 :: 1 add key = DNS2 list = ENV_DNSMASQ value = fd42 : d42 : d42 : 53 :: 1 / container mounts add dst =/ etc / dnsmasq.d list = MOUNT_DNSMASQ_DNSMASQD src =/ docker / dnsmasq -dnsmasq .d / container add remote -image = dockurr / dnsmasq name = dn42 -dnsmasq \ envlists = ENV_DNSMASQ mountlists = MOUNT_DNSMASQ_DNSMASQD \ root -dir =/ docker / images / dnsmasq interface = veth5 start -on-boot = yes The two upstream servers are taken from the DN42 anycast DNS .

The veth5 interface is a virtual interface bridged into my DN42 LAN on a dedicated dn42 VRF. I've added two addresses to veth5 , ::2 for the authoritative DNS, and ::53 for the forwarder. Initially, I only had one address, but dnsmasq refuses to operate a DNS forwarder on the same IP/interface as an authoritative server.

/ inteface bridge add comment = "dn42 bridge with containers" name = dn42 -bridge / ipv6 address add address = fd16 : 9939 : ecc0 :: 1 / 64 advertise = no interface = dn42 -bridge / ip vrf add interfaces =< snip >, dn42 -bridge name = dn42 / inteface veth add address = fd16 : 9939 : ecc0 :: 2 / 64 , fd16 : 9939 : ecc0 :: 53 / 64 comment = "DN42 dnsmasq" \ gateway6 = fd16 : 9939 : ecc0 :: 1 name = veth5 / interface bridge port add bridge = dn42 -bridge interface = veth5 Note: don't add the veth to your VRF, or you'll end up with "port is already slave" !

When you add the container, RouterOS will download and extract the image in the background. Later you can update it with /container/update - both will show the download progress in the UI:

/ container update dn42 -dnsmasq / container print * snip * # NAME ROOT-DIR INTERFACE CONTAINER-SIZE TAG ;;; downloading layer 0 / 6 0 %/ 7.7 M 3 E dn42 -dnsmasq / docker / images / dnsmasq veth5 7.7 MiB registry -1 .docker.io / dockurr / dnsmasq : latest * snip * Dual-use dnsmasq dnsmasq strictly separates authoritative DNS (being the main DNS server for a specific domain) and forwarding DNS (providing DNS responses for whatever a client is asking for). Normally, when you run dnsmasq on a router, you can configure it to be authoritative on the WAN interface and forwarding on the LAN interface.

If you misconfigure it, it will return Host not found: 5(REFUSED) for remote domains, and/or will fail to return a SOA for your domain.

When we run it in a container, we could either add two different virtual interfaces, or we set up two different addresses for the two tasks.

Now, we can create a ge0rg.conf file either directly in the container ( /container/shell dn42-dnsmasq and it helpfully comes with busybox' vi ), or on our computer, and scp it to /docker/dnsmasq-dnsmasq.d/ge0rg.conf on the RB4011:

# Be the authoritative server on the ::2 address auth -server=ns1 . ge0rg . dn42 , fd16 : 9939 : ecc0 :: 2 # Serve two zones: ge0rg.dn42 and reverse lookups for the ULA IPv6 range auth -zone=ge0rg . dn42 , fd16 : 9939 : ecc0 :: / 48 # Define the Start of Authority resource record parameters: # <serial>,<email>,<refresh>,<retry>,<expire>,<min_ttl> auth -soa= 2026072403 , ge0rg . ge0rg . dn42 , 1200 , 120 , 1209600 , 86400 # Create the actual AAAA and PTR records, one line per host: # <primary hostname>,<hostnames>,<IPv6> host -record=gw . ge0rg . dn42 , gw , fd16 : 9939 : ecc0 :: 1 host -record=dnsmasq . ge0rg . dn42 , dnsmasq , ns1 . ge0rg . dn42 , fd16 : 9939 : ecc0 :: 2 host -record=lan . gw . ge0rg . dn42 , lan . gw , fd16 : 9939 : ecc0 : 42 :: 1 host -record=wg . gw . ge0rg . dn42 , wg . gw , fd16 : 9939 : ecc0 : 7390 :: 1 You need to restart dnsmasq after each change to a config file (it will only reload /etc/hosts on SIGHUP):

/ container / restart dn42 -dnsmasq DN42 comes with a helper script to verify the correct working of your DNS zone:

$ . / validate -my-dns .py GE0RG -MNT NOTE : ge0rg.dn42 doesn 't have any ds-rdata specified NOTE: 0.c.c.e.9.3.9.9.6.1.d.f.ip6.arpa doesn' t have any ds -rdata specified Summary : domain name | success | dnssec fail | wrong NS | wrong SOA | NXDOMAIN | REFUSED | SERVFAIL | timeout ---------------------------------- | --------- | ------------- | ---------- | ----------- | ---------- | --------- | -------- | ------- ge0rg.dn42 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 0 .c.c.e .9.3.9.9.6.1 .d.f.ip6.arpa | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 The missing ds-rdata is about DNSSEC . If you want to sign your zone, use a "grown-up" DNS implementation 😉

The final result looks like this, taken from my peer:

$ mtr --report darkwing.ge0rg.dn42 Start : 2026 -07-24T15 : 49 : 32 + 0200 HOST : peerhost Loss % Snt Last Avg Best Wrst StDev 1 . | -- dn42 -peerhost .mypeer.dn42 0.0 % 10 124.0 82.4 31.8 132.8 36.0 2 . | -- gw.ge0rg.dn42 0.0 % 10 96.6 100.8 48.8 153.6 34.6 3 . | -- darkwing.ge0rg.dn42 0.0 % 10 55.3 108.7 55.3 159.5 35.8 Discuss on Mastodon