pjhtech Tools
MikroTik

MikroTik DNS Works on the Router but Not on Clients

Check DHCP-advertised DNS, allow-remote-requests, TCP and UDP 53, static records and application DNS when RouterOS resolves names but LAN clients fail.

When the router resolves names but clients time out querying it, check allow-remote-requests. If it is no, enable it and allow LAN UDP/TCP 53 in input. If an explicit query to the router already works, fix the client’s DNS selection instead.

Allow clients to use the router’s DNS cache

Read /ip/dns/print. If allow-remote-requests=no, first ensure the input firewall permits DNS only from the intended LAN sources, then enable the listener:

Configuration change • requires a restricted DNS input policy
/ip/dns/set allow-remote-requests=yes

Explicit router query works, but the client uses the wrong DNS server

If DHCP advertises the wrong resolver and this subnet should use the router, correct its existing network entry:

Configuration change • adapt the example identifiers
/ip/dhcp-server/network/set [find where address="10.42.50.0/24"] dns-server=10.42.50.1

On a Windows DHCP client, run ipconfig to identify its adapter, then ipconfig /renew "Ethernet" using that adapter name. On other clients, renew the lease with their network controls. Repeat the default nslookup.

A manually configured client needs its DNS setting changed on that client.

Scope: RouterOS IPv4 clients using the router as a DNS cache.

Compare the intended and actual resolver

Read-only
/ip/dns/print
/ip/dhcp-server/network/print detail
/ip/dns/static/print detail
/ip/firewall/filter/print stats where chain=input

Check which server the client actually queries. DHCP network options advertise a resolver, but existing leases, manual settings and application DNS can override that choice. For the example LAN, the router is 10.42.50.1 on br-lan. Run these on the failing client (Windows, or a system with nslookup installed):

Client terminal • read-only DNS queries
nslookup example.com 10.42.50.1
nslookup example.com

The first command selects the router explicitly. The second uses the client’s configured resolver; compare its Server/Address with 10.42.50.1. Use the actual failing name as well. A timeout differs from an NXDOMAIN answer: NXDOMAIN means a DNS server replied that the name does not exist.

The router’s input firewall drops DNS

Router DNS uses input, not forward. If filter counters show a DNS request being dropped, print the input rules with /ip/firewall/filter/print detail where chain=input. For this trusted LAN, insert the missing permits before the drop that blocks DNS; replace the placeholder with that rule’s number. Retain any earlier deliberate restrictions.

Configuration change • adapt the example identifiers
/ip/firewall/filter
add chain=input action=accept in-interface=br-lan src-address=10.42.50.0/24 protocol=udp dst-port=53 place-before=<input-drop-id> comment="LAN DNS UDP"
add chain=input action=accept in-interface=br-lan src-address=10.42.50.0/24 protocol=tcp dst-port=53 place-before=<input-drop-id> comment="LAN DNS TCP"

If the router returns a wrong static answer

If the router returns a wrong static answer, find the matching name in /ip/dns/static/print detail; disable only the confirmed stale record with /ip/dns/static/disable <record-id> to allow the upstream answer. Do not remove an intentional local override. DNS cache reference.

Verify the client path

Test an uncached name from the client and open the service by name. Confirm an untrusted network cannot use the router’s DNS cache. Restore the previous listener, DHCP option or static record if reverting; do not flush every cache before locating the mismatched resolver.

References