I had a structured lab research task to map MikroTik RouterOS DNS proxy: what /ip dns can do, how it would sit next to Pi-hole and Unbound, and whether turning it on was worth the operational cost. The question was simple: should clients keep using Pi-hole directly, or should the router accept DNS on port 53 and forward to upstream resolvers?

I did the research, mapped how it would fit my network, and decided not to turn it on. This post is the distilled outcome, not a paste of internal notes.

Hardware context: my RouterOS edge is an RB4011; switching that shows up in these stories is often a CRS326. Both run RouterOS, but DNS proxy is a policy choice, not a model-specific feature.

The problem

Homelab DNS was already working. I run multiple Pi-hole nodes for redundancy, Unbound upstream for recursion, and DHCP hands resolvers to clients per VLAN policy. The router was not acting as a DNS server for LAN clients.

The open question was whether router-level DNS caching would help enough to justify the change. RouterOS can answer DNS for clients when you allow remote requests and point the router at upstream servers. That pattern shows up in vendor docs and forum threads as a way to centralize DNS or add a cache closer to clients.

I wanted a clear answer before changing DHCP, firewall assumptions, Pi-hole logging behavior, or where internal static records live.

What RouterOS DNS proxy actually means here

In RouterOS terms, the moving parts are familiar. You enable the router to accept DNS queries from clients (for example with allow-remote-requests=yes under /ip dns), configure upstream servers, and the router resolves on behalf of clients and can cache responses. RouterOS can also hold static names under /ip dns static, which matters if you are deciding whether DNS for internal names lives on the router, on Pi-hole, or in both places.

Clients would talk to the router instead of talking to Pi-hole directly. That is the architectural shift. Everything downstream (which upstreams the router uses, how you split VLANs, how you failover) becomes a router configuration problem first.

That model has real benefits in some networks: one place to change upstream DNS, less repeat traffic to the same upstream if the router cache hits, and the option to apply router-side policy around DNS if you need it.

It also changes what you see in Pi-hole. If every client uses the router as its resolver, Pi-hole often sees one source address (the router) unless you work around that with extra plumbing. I care about per-client visibility in Pi-hole, so that mattered in the evaluation.

Cache behavior is another axis. A router cache can serve stale answers until TTL expires, which is normal for DNS but is one more place to reason about when something looks “wrong” after a change.

Investigation: how this compares to what I already run

The internal write-up walked through concrete integration steps: enable remote DNS, point upstreams at the Pi-hole cluster, then shift DHCP so clients use the VLAN gateway (or a single router address) as their DNS server instead of the Pi-hole IPs. It also called out firewall rules that today allow DNS toward an internal resolver list, and noted that flipping this model means the router listens on UDP/TCP 53 for clients while still needing outbound access toward Pi-hole. None of that is impossible. It is just a bundle of edits across DHCP, DNS, and firewall that has to stay coherent.

I already have redundant Pi-hole capacity. One node acts as the primary; replicas cover failure and load without asking the router to be another caching layer in front.

Pi-hole already caches. Adding a RouterOS cache in front is not free complexity: it is another resolver hop, another place to tune TTL behavior, and another component in the path when something misbehaves.

Static DNS ownership would need a deliberate rule. I already treat Pi-hole as the place where internal records land. Turning on RouterOS static entries for the same names would duplicate truth unless I moved ownership entirely. RouterOS static entries can override upstream behavior in ways that are powerful and easy to get subtly out of sync with the rest of the lab.

DHCP already encodes the policy I want. Trusted VLANs get internal Pi-hole addresses. Guest or work-style segments can use public resolvers such as Cloudflare (1.1.1.1 / 1.0.0.1) without sending that traffic through the ad-blocking path. Moving DNS to the router would not simplify that story unless I recreated the same logic in RouterOS scripts or address lists, which is more moving parts, not fewer.

The router already has a job. I would rather not spend CPU and memory on DNS caching when the dedicated Pi-hole hosts are the right place for that work, and when I am not seeing a performance problem that points at the edge.

Failure modes matter. If the router becomes the only DNS entry point for clients, DNS depends on the router being healthy in a different way than today. I still have upstream redundancy on Pi-hole, but I would be trading a clean “clients to Pi-hole” path for a funnel that adds coupling I do not need.

Decision: keep clients on Pi-hole directly

I am not enabling RouterOS DNS proxy for this network.

The best arguments for the feature did not match my constraints. Centralized caching sounds nice until you remember Pi-hole already does it, my nodes are redundant, and I value accurate client lists in Pi-hole more than shaving duplicate queries at the router.

Simplicity won. Fewer resolver layers between the client and the service I use for blocking and logging means less ambiguity when I debug a weird query or a misbehaving device.

This is a homelab-specific conclusion. If I had a tiny branch site, strict policy that had to live only on the router, or clients I could not configure via DHCP, I would reopen the question.

When DNS proxy on the router might still make sense

Consider it if you need router-centric policy or you cannot steer clients any other way.

Consider it if Pi-hole is not in the path at all and you only want a small cache toward public DNS.

Consider it if you accept the visibility trade and you have a plan for client attribution (or you do not need it).

Reflection

The useful output of the research was not a config snippet. It was a checklist: caching already exists where I want it, redundancy is handled at Pi-hole, DHCP already expresses per-VLAN DNS policy, static DNS has a single home today, and pushing DNS into the router would have obscured client identity in Pi-hole without fixing a problem I actually have. The internal notes also made clear how many surfaces would move together if I had said yes.

If my symptoms change (for example, measurable load problems on Pi-hole or a new segment where DHCP cannot set DNS), I will revisit RouterOS DNS with real metrics, not just feature capability.

Disclosure: This article contains affiliate links. If you purchase through these links, I may earn a commission at no extra cost to you.