Errors With Mikrotik DNS Resolver

RouterOS General
1

I started using the DNS resolver in my Mikrotik router, and I have found two issues with it.

If I have a static entry A record for service.domain.com, running dig service.domain.com resolves correctly.
If I run nslookup service.domain.com, this fails due to IPv6:

Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
Name:	service.domain.com
Address: 192.168.x.x
** server can't find service.domain.com.com: NXDOMAIN

This causes things like crictl pull to fail internally, because nslookup returns a 1 error exit code.
I have a hack/workaround for this where I add a AAAA record that resolves to ::1, but I am not pleased with this.

The second issue is the Mikrotik DNS resolver is stripping DNSSEC records.

Using google public DNS:

dig @8.8.8.8 cloudflare.com +dnssec

; <<>> DiG 9.20.24 <<>> @8.8.8.8 cloudflare.com +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53703
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;cloudflare.com.			IN	A

;; ANSWER SECTION:
cloudflare.com.		300	IN	A	104.16.132.229
cloudflare.com.		300	IN	A	104.16.133.229
cloudflare.com.		300	IN	RRSIG	A 13 2 300 20260707182610 20260705162610 34505 cloudflare.com. Ak04/OvFhqbG6yG1V3YT22x39XMq530P3b8OWlUBx+cvqbHUIvPOHvM7 l3lGF0GcrMYM8imX59GVhcJhBZDQ8g==

;; Query time: 39 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Mon Jul 06 17:26:10 UTC 2026
;; MSG SIZE  rcvd: 185

Using the Mikrotik DNS resolver:

dig cloudflare.com +dnssec

; <<>> DiG 9.20.24 <<>> cloudflare.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63117
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;cloudflare.com.			IN	A

;; ANSWER SECTION:
cloudflare.com.		164	IN	A	104.16.132.229
cloudflare.com.		164	IN	A	104.16.133.229

;; AUTHORITY SECTION:
.			8623	IN	NS	i.root-servers.net.
.			8623	IN	NS	a.root-servers.net.
.			8623	IN	NS	j.root-servers.net.
.			8623	IN	NS	m.root-servers.net.
.			8623	IN	NS	k.root-servers.net.
.			8623	IN	NS	h.root-servers.net.
.			8623	IN	NS	b.root-servers.net.
.			8623	IN	NS	l.root-servers.net.
.			8623	IN	NS	c.root-servers.net.
.			8623	IN	NS	e.root-servers.net.
.			8623	IN	NS	f.root-servers.net.
.			8623	IN	NS	g.root-servers.net.
.			8623	IN	NS	d.root-servers.net.

;; Query time: 30 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Mon Jul 06 17:26:15 UTC 2026
;; MSG SIZE  rcvd: 275

As you can see, the Mikrotik resolver strips out the ad flag instead of forwarding it.

This is vital for things like email servers to be able to run DNSSEC validation.

2

https://forum.mikrotik.com/t/dnssec/38478/48

DNSSEC.zip

Try adding my certs to your mikrotik routers certificate store and see if it will passthough RRSIG keys.

Then let me know.

dig cloudflare.com +dnssec

; <<>> DiG 9.20.18-1ubuntu2.1-Ubuntu <<>> cloudflare.com +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63289
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
;; QUESTION SECTION:
;cloudflare.com.                        IN      A

;; ANSWER SECTION:
cloudflare.com.         144     IN      A       104.16.132.229
cloudflare.com.         144     IN      A       104.16.133.229
cloudflare.com.         144     IN      RRSIG   A 13 2 300 20260707195901 20260705175901 34505 cloudflare.com. qkvEubWMvzWnSyZyBDhvk28u0ROg7TEYaBNxMHjpym2sC+3444j6V2p3 c6CAEHLTvHsXLpMzOHOLjL4GJF7Ccw==

;; Query time: 48 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Jul 06 15:01:30 EDT 2026
;; MSG SIZE  rcvd: 185
3

@thedarkula, I'm not sure this is related, but it’s possible that something has changed in the resolver. Absolute FQDNs with a trailing dot no longer work:

# Absolute FQDN with trailing dot fails
[A@E7B401] > :put [:resolve xxx.yyy.com.]
failure: bad name

# Normal FQDN without trailing dot works
[A@E7B401] > :put [:resolve xxx.yyy.com]
nnn.nnn.nnn.nnn
4

My guess MT changed the behavior and the trailing dot or full stop is assumed.

But other systems allow with or without full stop.

5

Yeah, that might be the case, but then :resolve xxx.yyy.com. should still not fail with bad name IMO.

A trailing dot is the standard DNS syntax for an absolute FQDN, so even if ROS now assumes it internally, accepting the explicit absolute form would still be expected behavior.

6

I uploaded all the certificates, and then added them individually through System -> Certificates -> Import

I re-ran the dig, but it still strips the adinformation.

7

Can you re run this and post it.

8

I am not sure, but I think this is purely a IPv4/IPv6 issue.

Logically, routeros should only return an IPv4 result if there are no IPv6 entries in the static DNS.

Currently, if you add an IPv4 record like something.domain.com and have it be 1.2.3.4, routeros returns the IPv4 record, but shows a failure because the IPv6 AAAA record does not exist.

9

What version of RouterOS are you on?

Maybe the IPv6 RA bug?

10

As of today, I am running version 7.23.2.

11

Try disabling IPV6 network discovery interface all.

I would reboot after that change.