Does RouterOS support DNSSEC ?

DNSSEC is making news. July deployment apparently..

MikroTik DNS cache does not support it (it does not mark answer with digital signature).

Is there any news about this?
DNSSEC becoming world standard and more and more ISP's are implementing it. But if ISP is using Mikrotik production, it can't deploy DNSSEC.
Please Mikrotik, give us more reasons to use your production

I'd add a +1 to this.

Would love to be able to turn on validation on routeros.

+1 for feature request

nope
its don't support DNSCurve too (DNSSec successor/replacement, proposed ~2yrs ago, but delayd for approval).

+1000000 for feature request

Is there any reason why DNSSEC is still not implemented?

+1 for DNSSEC

We have clients that need this feature

+1 for feature request

up ! +1 for DNSSec on the resolver

+1 for feature request

+1 for DNSSec As added feature

I can't see any extra's functionality in this that I need. The DNS functionality that is current available is in my eyes there to change the real DNS responses or to create DNS responses for only internal use. The DNS of the Mikrotik let through the DNSSEC response from the real DNSsever to the client.

The problem with just passing DNSSEC data to clients, when they ask for it, is that nothing actually does. Web browsers, as the most commonly used type of program today, couldn't care less about DNSSEC and will happily accept any fake reply. And other programs or operating systems are not any better.

To get protection, validation must happen on DNS resolver. It probably does on ISP's, but then the reply must travel through their network to you, and it's again possibly vulnerable. It's even worse for all kinds of public resolvers (longer path). If resolver in RouterOS could validate DNSSEC, it would help. On the other hand, it's a little more than just a simple addition, so MikroTik probably won't be rushing into it.

Today we have a public DNS 1.1.1.1 by Cloudflare, 8.8.8.8 by Google with DNS-over-TLS, and DNS-over-HTTPS, which both provide last mile encryption to keep DNS queries private and free from tampering. We wanna use it on our devices!!!

Full list DNS with dnssec https://download.dnscrypt.info/resolver ... solvers.md

Yes, it is not simple addition, but topic created years ago

p.s. Couple of DNS servers were hijacked to resolve http://myetherwallet.com users to be redirected to a phishing site. This is not on @myetherwallet side, we are in the process of verifying which servers to get it resolved asap.

I fully support dnssec as an additional feature !! +100500 for feature request

Cheers, Mechanic

Just switch from a draytek to ccr1009, but because lack of DNSSEC I am not sure if the CCR will go in production at all

I believe I got bitten by this today. On Ubuntu 16.04, with lxd 3.0.1 installed from xenial-backports, the following command consistently failed:
pointed to 10.12.255.1, which is Mikrotik hEX PoE. tcpdump showed that DNS packets were being sent, and responses returned by the Mikrotik. But after changing DNS to point to 8.8.8.8, it worked fine.

So there's something about the responses from the Mikrotik DNS forwarder that lxd doesn't like; and the obvious difference is DNSSEC (although I can't prove this is the cause):
versus

Simple: do not use the resolver in the MikroTik for clients, but let them directly use 1.1.1.1 or 8.8.8.8 or similar.
(advertised via DHCP)

Simple: do not use the resolver in the MikroTik for clients, but let them directly use 1.1.1.1 or 8.8.8.8 or similar.
(advertised via DHCP)

I think there's a lot of reasons people wouldn't want to do that though.

Simple: do not use the resolver in the MikroTik for clients, but let them directly use 1.1.1.1 or 8.8.8.8 or similar.
(advertised via DHCP)

I think there's a lot of reasons people wouldn't want to do that though.

What are those reasons?
With most routers on the market, the built-in resolver is limited and sometimes buggy, and it is usually preferred not to use it and
directly refer to the internet resolvers of the ISP or one of those public resolvers. (there are others)

Using an external resolver also fixes latency issues caused by high CPU, routed packets through the kernel still proceed but user mode DNS server is starved, leading to slow DNS response. I also couldn't find a way to do DNS rebinding protection with Mikrotik which was the main reason I switched away.

Simple: do not use the resolver in the MikroTik for clients, but let them directly use 1.1.1.1 or 8.8.8.8 or similar.
(advertised via DHCP)

I think there's a lot of reasons people wouldn't want to do that though.

What are those reasons?
With most routers on the market, the built-in resolver is limited and sometimes buggy, and it is usually preferred not to use it and
directly refer to the internet resolvers of the ISP or one of those public resolvers. (there are others)

such as when you need to force some domain resolve into specific IP?

such as when you need to force some domain resolve into specific IP?

Then you are already in I-like-broken-networks territory. And DNSSEC is preventing you from doing it.
It is like "I need to do a redirect on a https:// URL". You may feel the need to do these things,
but the internet at large is trying harder and harder to prevent you from doing it.

such as when you need to force some domain resolve into specific IP?

Ever heard of hosts file?

Simple: do not use the resolver in the MikroTik for clients, but let them directly use 1.1.1.1 or 8.8.8.8 or similar.

I think there's a lot of reasons people wouldn't want to do that though.

such as when you need to force some domain resolve into specific IP?

I can imagine many situations where you want to
- inject an internal domain into DNS or
- use split DNS or
- just not let Google know which websites your clients are visiting ...

Ever heard of hosts file?

Hosts file are a mess for multiple clients or any client not under your control.

+1 for DNSSec
how long will you do it? why so long?

Simple: do not use the resolver in the MikroTik for clients, but let them directly use 1.1.1.1 or 8.8.8.8 or similar.
(advertised via DHCP)

I think there's a lot of reasons people wouldn't want to do that though.

What are those reasons?

A late reply, but since the thread was dug up by someone else...

You need to be sure that something verifies DNSSEC signatures. None of client programs does, so it needs to be the resolver. It you use ISP's resolvers, the path between them and you is still vulnerable. If you use 1.1.1.1, 8.8.8.8 or similar, it's the same, but the path is longer. If you want to be safe, you need your resolver to verify signatures. Client programs will still not care, but securing your internal network is in your hands. Unlike ISP's network, or the whole way to 8.8.8.8 and such.

True, so there could be some utility in a DNSSEC validating resolver inside RouterOS that returns errors to the clients for nonvalidating replies.
However, I would not consider it a first priority. It will cause unexplainable problems to many users that just turn this on "because it should be a good idea".
(similar to what you experience when enabling IPv6: initially many sites that stopped working or became unbearingly slow, currently better but still the occasional problem)

Yes, it would be interesting to watch how many things it would break. All kinds of DNS overrides would stop working. You could still set static records on your own router, but if done upstream, they would not pass the validation.

Yes, it would be interesting to watch how many things it would break. All kinds of DNS overrides would stop working. You could still set static records on your own router, but if done upstream, they would not pass the validation.

About 1.5 years ago I enabled DNSSEC on a caching resolver used by a number of users, and there were massive problems.
Many domains that were said to have DNSSEC in their parent domain but actually did not have it or had configured wrongly, so many domains failing validation.
About two months ago I enabled it again and now the problems are much less. I now leave it to the domain owners to get their act together.
(and to the users to complain)

However, I could understand when in other regions of the world the situation may still be bad. And when a manufacturer like MikroTik would make this available, they probably hit a lot of those regions.
As I mentioned, it is like IPv6: introduction of IPv6 to your clients does not bring any apparent benefits (lots of happy customers) but there is a serious risk that it will cause some issues (unhappy customers). So therefore many ISPs choose not to do that. This is of course a shame, but it is understandable.

My experience with DNSSEC from user perspective is positive. I have it on small hobby network for years, as an experiement, since the root zone was signed. I used to watch resolver logs and majority of failures were from various testing sites with intentionally broken DNSSEC. From admin perspective, it's a little less enjoyable, because it's easy to shoot yourself in foot. And it has happened in the past, e.g. one of local registrars, who also hosted DNS for customers, messed up DNSSEC for throusands of domains. Then next half a day everyone could see what ISPs do DNSSEC validation and what don't. Irony being that those caring about security had it seemingly broken. But I wouldn't worry about it much today, a lot of ISPs validate DNSSEC, big public DNS services too, so any broken domain won't stay broken for too long.

@Joni: DNS over TLS solves the problem between validating resolver and client. But you still have to trust the resolver. If it's something like Google's servers, they probably won't tamper with responses. But if you're at least slightly paranoid, you still can't trust them. So ideally RouterOS should have both, DNS over TLS for users where the biggest danger is evil or incompetent ISP, and also an option to actually validate DNSSEC.

+1 for DNSSEC

We use DNS on RouterOS as backup DNS server in geographically separated location. But one client using Turris router had weird problems with resolving domain names. Sometimes it worked and sometimes it doesn't. We found out that it was caused by DNSSEC or rather by not having that support in RouterOS. Turris router was not able to communicate with RouterOS if DNSSEC was enabled. At the same time our primary DNS running with BIND server in Linux is working with DNSSEC. So in the result some queries were ok and some not. That may be just the tip of the iceberg.
So we will probably need to run another router or Linux device just for a backup DNS.

Will RouterOS support DNSSEC in near future?
Would it be possible to use virtualization to run different DNS server?
Will RouterOS 7 support DNSSEC? It is hard to find some complete feature list for 7.0beta and 7.1beta.

At the moment, the DNS resolver in RouterOS is in a sad state. Problems with DoH, problems with the cache integrity, lack of DNSSEC support.
We can only hope that the developers at MikroTik have finally noticed this and will switch over to a proven opensource DNS resolver in RouterOS v7 and if we are lucky also as fix for v6.

I also suggested to add lightweight virtualisation to RouterOS: possibility to run a portable program stored in a folder on the Flash as a user process with very limited access to the remainder of the router (running as chroot in the folder, as an unprivileged user).
That program should then be able to open (or be configured with) some network sockets (TCP/UDP or a plain ethernet network) so that it can be wired into the router configuration.

Such a feature would be very useful to run things like a custom DNS resolver, and others.

Only check DNSEC once in a local network and it should be implemented as close as possible to the upstream (server).

If local Bind is offering it's own for local DNSEC records then have the other clients connect directly to it. I remember that ROS can now redirect DNS request to different server.

Dear all,

I am quite surprised that Mikrotik RouterOS DNS cache strips DNSSEC information.
This allows man-in-tje middle attack inside a network.

So +1 for cache DNSSEC support.

If you have a resolver that handles DNSSEC in front of RouterOS it won't return an IP address when the DNSSEC it invalid.

Cache poisoning can also happen on the client. The AD flag could be stored to indicate a valid DNSSEC or AD is False to to indicate why IP is not returned.

RouterOS has a basic DNS system despite new functionality was added lately.

I'm starting to hate the RouterOS DNS service more and more. Especially in current v7.7rc releases.
It just breaks things. And it is difficult to find why. I e.g. made a trace of the DNS lookups both in front of and behind the RouterOS DNS resolver, while the client application is failing. It returns nonstandard responses that might be considered valid but are not understood by all clients.
It might even be that this client was expecting DNSSEC to work and it did not...

It is time that MikroTik ditch this thing and install a known and trusted DNS resolver. That supports all modern usages and has all expected quirks.

+1. I'd be fine using the RouterOS resolver if it returned at least the AD bit in the response for use by my mail server for DANE checking. But it doesn't. I can appreciate that validation as such is hard, but couldn't we at least have proxying the DO and CD bits in queries and AD bits in responses from a configured DoH upstream? You can still cache the supported RR sets in responses—just make sure DNSSEC-enabled queries and replies are proxied direct.

Or, yeah, as others here have suggested, just use another resolver. Dnsmasq, for preference—then you can have tight DHCP and DNS integration, with DHCP-supplied hostnames registered automatically in DNS: a nice feature, if not absolutely necessary. But please don't leave us with this half-baked resolver and make it necessary to run a dedicated machine on the network for functioning DNS resolution and questioning the whole point of an integrated router (or alternatively looking at other options that'll just let you run Linux yourself).

for now till MT add this feature, use container + adguard

Do you know if the MikroTik DoH proxy is a separate listening interface that can be configured? Or does the container need to have DoH or DoT support itself as well?

When going to the trouble of setting up a container with a good DNS resolver, I would not rely on the behavior of the existing DNS resolver in RouterOS.
Let the container make its own queries and if necessary use RouterOS only to NAT them to the outside world, not to resolve them.
You can then configure the RouterOS resolver to not accept outside queries.