Kernaali ToolsIf the router resolves a name but a LAN client does not, first verify which DNS server the client actually queries. RouterOS can resolve for itself with allow-remote-requests=no. Enabling the cache for clients is appropriate only when TCP and UDP port 53 are restricted to the intended local sources.
Applies to: RouterOS 7 IPv4 LAN clients using the router as a DNS cache, checked against the current DNS and DHCP manuals. Browser-managed encrypted DNS, IPv6 resolver advertisement and multi-VRF DNS designs require separate resolver-path checks; they are not silently covered by an IPv4 DHCP setting.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Separate the client query from the router query
/ip/dns/print
/ip/dhcp-server/network/print detail
/ip/dns/static/print detail
/ip/firewall/filter/print stats where chain=inputOn one authorized client, inspect its actual DNS server list and query a known name explicitly against the router’s LAN address. Compare that result with the client’s default resolver. If only the default query fails, correct DHCP/static resolver selection or the application resolver, not the router’s upstream list. Reconnect or renew only the test client after changing its lease options.
The DNS manual distinguishes router-only resolution from the cache listener. The DHCP server network options determine what an IPv4 DHCP client is told; an existing lease or a manually configured resolver can retain a different choice.
Interpret the response before opening access
| Result | Likely layer to examine |
|---|---|
| Timeout only when querying the router | allow-remote-requests, input policy and client-to-router reachability |
| NXDOMAIN or an unexpected address | Static names, wildcard/regular-expression entries, upstream answer or filtering |
| Explicit router query succeeds; browser still fails | Browser encrypted DNS, proxy/VPN resolver and cached application result |
| Router and clients both fail upstream lookups | Router route, upstream DNS reachability, time/certificates if DoH is configured |
| Small replies work but some lookups fail | TCP fallback, larger responses and path filtering; allow both DNS transports |
Enable the intended service with a bounded input policy
If clients are meant to use this router and the listener is disabled, first confirm the existing input rules permit only the approved LAN sources to TCP/UDP 53 and reject untrusted access. A forward-chain permit does not authorize traffic addressed to the router itself. Then change the listener:
/ip/dns/set allow-remote-requests=yesDo not copy a rule accepting DNS from every interface. If the intended resolver is an external server instead, advertise that server and leave the router cache listener disabled. For a local static name such as printer.example.com, check the exact record and query it directly; do not assume a client using another resolver can see RouterOS static entries.
Verify application resolution and recover
Confirm the test client queries the chosen resolver, receives the expected A/AAAA result, and opens the intended service by name. A successful router ping to an IP address does not validate client DNS. Test that an unauthorized network still cannot use the cache.
Restore the recorded allow-remote-requests value and the exact edited DHCP/static record or input rule if the change fails. Avoid flushing every cache to hide an unresolved path problem; expire or clear only the test application’s stale result where supported. Stop temporary captures, which may contain private domain queries.
Technical references
Found an issue? Send a correction with a reproducible example.