Mikrotik DNS missing features

RouterOS General
1

Hi,

I would like to request basic fixes in DNS cache support in Mikrotik. I have latest stable Mikrotik, which offers DNS over HTTPS. I don’t need that. I trust my ISP.

I would like, if my systems could rely on Mikrotik cache without features missing. Mikrotik DNS is not able to answer with EDNS https://tools.ietf.org/html/rfc2671. That extension is 20 years old. It enables bigger answer negotiation. You can check it by dig tool on Linux.

$ dig @192.168.88.1 | grep -A 2 OPT
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:

Worse is, above is a requirement for Security Extensions of DNS https://tools.ietf.org/html/rfc4035. They are 15 years old. Mikrotik cannot do DNSSEC validation itself. That is unfortunate, but validation is not simple to do properly. Unfortunately Mikrotik also does BLOCK validation attempts to any systems using it as a cache. DNSSEC is ultimate protection against DNS poisoning. It ensures original data from authoritative server is unmodified anywhere in the chain of caching servers. It can then be used for verifying authenticity of signed domains. It can help in verifying SSHFP records are valid and not ask for guessing of fingerprint.

DNSSEC helps with protection against http://saddns.net, renewed attack to poison DNS caches. Compare two outputs of delv, which verifies domain integrity.

$ delv @192.168.88.1
;; validating ./NS: got insecure response; parent indicates it should be secure
;; insecurity proof failed resolving './NS/IN': 192.168.88.1#53
;; resolution failed: insecurity proof failed

$ delv @8.8.8.8
; fully validated
.			85631	IN	NS	i.root-servers.net.
.			85631	IN	NS	j.root-servers.net.
.			85631	IN	NS	e.root-servers.net.
.			85631	IN	NS	h.root-servers.net.
.			85631	IN	NS	m.root-servers.net.
.			85631	IN	NS	b.root-servers.net.
.			85631	IN	NS	d.root-servers.net.
.			85631	IN	NS	f.root-servers.net.
.			85631	IN	NS	c.root-servers.net.
.			85631	IN	NS	g.root-servers.net.
.			85631	IN	NS	a.root-servers.net.
.			85631	IN	NS	l.root-servers.net.
.			85631	IN	NS	k.root-servers.net.
.			85631	IN	RRSIG	NS 8 0 518400 20201129050000 20201116040000 26116 . B7WRRgtaFLLyv4lLSnjwaQ1D960t9wA94pRjld1guuA75veJ2Ocgw3/a e0sFAhNNm72IBfLNiVBL0fMKfijcuEPUxCRKqnMxBPlh+06BuHG667SJ j9Al+Egsjl51voI6tO9I9MureaHtkIHlw2t3kIzhiSZxJpDWLMV8bcIa DKpQyUpXVr+Fw4eyZp2JlijDLEPt+jwdDW2R7MY0OhRydcOQTq2gUtQH RtWv5P8VYAHLoVH0ZLNuLYNM+MYNvNScG1eDhKdH8jp/KcOUy0RP7ozo tjegv2KePcIgbxjoI38U0sFFsSUhA1ToY8usfl3ZBzZFBzXtdXbhqPLV NGSA1Q==

Until Mikrotik can do validation, please stop at least blocking of Security Extensions records. Not, following dig output is missing OPT PSEUDOSECTION and RRSIG records.

$ dig +dnssec @192.168.88.1

; <<>> DiG 9.16.8-RedHat-9.16.8-1.fc32 <<>> +dnssec @192.168.88.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12344
;; flags: qr rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 13, ADDITIONAL: 26

;; QUESTION SECTION:
;.				IN	NS

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

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

;; ADDITIONAL SECTION:
h.root-servers.net.	76408	IN	A	198.97.190.53
e.root-servers.net.	76408	IN	A	192.203.230.10
k.root-servers.net.	76408	IN	A	193.0.14.129
i.root-servers.net.	76408	IN	A	192.36.148.17
m.root-servers.net.	511859	IN	A	202.12.27.33
g.root-servers.net.	113513	IN	A	192.112.36.4
l.root-servers.net.	76408	IN	A	199.7.83.42
c.root-servers.net.	76408	IN	A	192.33.4.12
a.root-servers.net.	508409	IN	A	198.41.0.4
b.root-servers.net.	579151	IN	A	199.9.14.201
d.root-servers.net.	461114	IN	A	199.7.91.13
f.root-servers.net.	461114	IN	A	192.5.5.241
j.root-servers.net.	76408	IN	A	192.58.128.30
e.root-servers.net.	76408	IN	A	192.203.230.10
k.root-servers.net.	76408	IN	A	193.0.14.129
i.root-servers.net.	76408	IN	A	192.36.148.17
m.root-servers.net.	511859	IN	A	202.12.27.33
g.root-servers.net.	113513	IN	A	192.112.36.4
l.root-servers.net.	76408	IN	A	199.7.83.42
c.root-servers.net.	76408	IN	A	192.33.4.12
a.root-servers.net.	508409	IN	A	198.41.0.4
b.root-servers.net.	579151	IN	A	199.9.14.201
d.root-servers.net.	461114	IN	A	199.7.91.13
f.root-servers.net.	461114	IN	A	192.5.5.241
j.root-servers.net.	76408	IN	A	192.58.128.30
h.root-servers.net.	76408	IN	A	198.97.190.53

;; Query time: 3 msec
;; SERVER: 192.168.88.1#53(192.168.88.1)
;; WHEN: Po lis 16 19:25:42 CET 2020
;; MSG SIZE  rcvd: 813

Note, DNS over HTTPS helps with protection against cache poisoning in one hop. But it does not provide any integrity protection against spoofing on remote endpoint. DNSSEC can to that with or without DNS over HTTPS. It is not replacement, but an addition to it.

Please, if you would like modern DNS cache like me, raise a ticket at support. Do not require users to skip using Mikrotik as their cache. Thanks!

2

My apologies, I dont have the requisite knowledge to comment.
So far I have not had any serious DNS issues so not sure what the concern is.
In any case, maybe Sindy will pop by and chime in. His input I do trust.

3

You know you don’t have to, right? :wink:

As for the request itself, yes please, dns improvements are good. For a long time it looked completely hopeless, with MikroTik showing no interest, but recently there were some additions, so hopefully it’s not the end of it.

4

Sob, I never thought of not responding, what a great idea>>>>>>>>> Damn why did I respond to you just now, didnt have too!!
Oh well, it was out of human decency and courtesy to respond to the person- didn’t want him/her to think we were ignoring their post.

5

Well, we could upgrade your firmware and give you new role, “anav, the welcome bot”. In addition to already tested and I’d say successful “anav, the config requester bot”. :slight_smile:

6

For me the DNS server of Mikrotik is only a DNS forwarder
A DNS forwarder only has a subset of the DNS server capabilities.

7

bpwl you nailed it. We have been calling it wrong all this time lol. There, expectations reset!

8

Mozilla are currently conducting an experiment to see if RRSIG records are being stripped out (https://blog.mozilla.org/security/2020/11/17/measuring-middlebox-interference-with-dns-records/)

Once browsers start relying on DNSSEC validation it’ll become a basic requirement for all DNS forwarder/caches, then Mikrotik will be forced to fix it.
Mikrotik needs to start supporting DNSSEC forwarding, from what I’ve seen the forwarder doesn’t know what to do with the RRSIG record, so it ignores it/strips it out.

Is there any chance Mikrotik would just open the source for RouterOS or whatever it’s called? People would fix these bugs for free. Not to mention making the entire platform more transparent, open and more secure.

9

I’m sure they will do the right thing… eventually. That means implementing at least the bare basics required for DNSSEC. Because even minimum requirement evolve. There was no DNSSEC when they added DNS forwarder many years ago, but now that it exists for fifteen years, clients can reasonably expect that their resolver knows about it.

I wouldn’t hold my breath for open source RouterOS. Anything is possible, it’s just that some things don’t seem very likely. RouterOS can go open source, Martians and Yetis can fight over the Earth, …

10

I was thinking more along the lines of… no matter what SOB does, be it botox or makeup he will always look like Yoda ! ;-PP

11

There is no reason to omit DNSSEC from forwarder. RouterOS has caching forwarder, similar to dnsmasq. But unlike it, it always breaks and dnssec enabled queries. If it just forwarded requests and delivering back responses, it would work. But it does not.

12

Well, as it was already written above there recently were some long-requested additions to the DNS resolver and also addition of DoH support.
However, as obvserved by the behavior of the resolver when new features and DoH are enabled at the same time, and also when testing boundary cases like large replies, it is very apparent that the current DNS resolver in RouterOS is a pile of manure that is best removed and replaced by something of better quality.
There are enough open-source DNS servers/resolvers that will work much better than what we have now, the only challenge for MikroTik would be to integrate them with their configuration environment, preferably in a compatible way.
I do not believe in fixing this resolver. There are just to many problems.