Page 1 of 1

DNSSEC

Posted: Tue Jun 15, 2010 7:53 pm
by Xymox
Does RouterOS support DNSSEC ?

DNSSEC is making news. July deployment apparently..

Re: DNSSEC

Posted: Wed Jun 16, 2010 1:15 pm
by sergejs
MikroTik DNS cache does not support it (it does not mark answer with digital signature).

Re: DNSSEC

Posted: Wed Nov 06, 2013 3:04 pm
by EMOziko
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 :)

Re: DNSSEC

Posted: Mon Feb 24, 2014 6:08 am
by itchycube
I'd add a +1 to this.

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

Re: DNSSEC

Posted: Wed Oct 01, 2014 12:01 pm
by oreggin
+1 for feature request

Re: DNSSEC

Posted: Wed Oct 01, 2014 3:58 pm
by Zorro
nope :(
its don't support DNSCurve too (DNSSec successor/replacement, proposed ~2yrs ago, but delayd for approval).

Re: DNSSEC

Posted: Sun Feb 15, 2015 5:13 pm
by mhoungbo
+1000000 for feature request

Re: DNSSEC

Posted: Sun Apr 26, 2015 5:08 pm
by zopper
Is there any reason why DNSSEC is still not implemented?

Re: DNSSEC

Posted: Sun Apr 26, 2015 6:15 pm
by IPANetEngineer
+1 for DNSSEC

We have clients that need this feature

Re: DNSSEC

Posted: Thu May 28, 2015 3:14 pm
by papuas
+1 for feature request

Re: DNSSEC

Posted: Tue May 24, 2016 9:34 am
by chebedewel
up ! +1 for DNSSec on the resolver

Re: DNSSEC

Posted: Mon Jan 16, 2017 8:52 pm
by loredo
+1 for feature request

Re: DNSSEC

Posted: Mon Feb 06, 2017 4:24 am
by Tabco2
+1 for DNSSec As added feature

Re: DNSSEC

Posted: Mon Feb 06, 2017 9:58 am
by msatter
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.

Re: DNSSEC

Posted: Mon Feb 06, 2017 3:51 pm
by Sob
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.

Re: DNSSEC

Posted: Fri Apr 20, 2018 10:34 am
by lysanev
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.

Re: DNSSEC

Posted: Fri Apr 20, 2018 1:20 pm
by MechanicF
I fully support dnssec as an additional feature !! +100500 for feature request

Cheers, Mechanic

Re: DNSSEC

Posted: Tue May 22, 2018 8:52 am
by DummyPLUG
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

Re: DNSSEC

Posted: Fri Jul 06, 2018 7:41 pm
by candlerb
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:
root@nuc1:~# lxc launch images:debian/jessie/amd64 snf-image-jessie
Creating snf-image-jessie
Error: Failed container creation: Get https://images.linuxcontainers.org/streams/v1/index.json: lookup images.linuxcontainers.org on 10.12.255.1:53: read udp 10.12.255.11:46962->10.12.255.1:53: i/o timeout
/etc/resolv.conf
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):
root@nuc1:~# dig @10.12.255.1 images.linuxcontainers.org +dnssec +multi
...
;; ANSWER SECTION:
images.linuxcontainers.org. 900	IN CNAME canonical.images.linuxcontainers.org.
canonical.images.linuxcontainers.org. 900 IN A 91.189.91.21
canonical.images.linuxcontainers.org. 900 IN A 91.189.88.37
versus
root@nuc1:~# dig @8.8.8.8 images.linuxcontainers.org +dnssec +multi
...
;; ANSWER SECTION:
images.linuxcontainers.org. 77 IN CNAME	canonical.images.linuxcontainers.org.
images.linuxcontainers.org. 77 IN RRSIG	CNAME 8 3 900 (
				20180718083502 20180704052307 23359 linuxcontainers.org.
				NdCMnXYwpegRTCx0b92mylHnjgS7msdjnfTvz+ozjZOc
				JqA2DQxYFqsbKETc2nE3U2eOSi3UEFtR3V2959oMNTQv
				Du8R6OdZb9hFrXh6woEyAPe93fbk+hnehKP4UtqfPRG8
				uRJn6Tiqjdqt8TubHGQqpn9uJDpNMzSArXyZhyM= )
canonical.images.linuxcontainers.org. 334 IN A 91.189.91.21
canonical.images.linuxcontainers.org. 334 IN A 91.189.88.37
canonical.images.linuxcontainers.org. 334 IN RRSIG A 8 4 900 (
				20180710143450 20180626095643 23359 linuxcontainers.org.
				Uumc8LbdvVrbtuihoZo1dsDZTylkDLZNzK6V+Z66i+L0
				CIFRkbyRuHM8x2A1LQknuhwQfDJcZftjl5fPtNaztLYk
				hkhGVZ86vVwgqCS7clZLqpr38oSroB/NbqOxP/R7ibcJ
				l2h3UqNvLev4FpqqVYHLD/KIN62llCi7MoK7HNo= )

Re: DNSSEC

Posted: Fri Jul 06, 2018 10:02 pm
by pe1chl
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)

Re: DNSSEC

Posted: Sat Jul 07, 2018 3:34 am
by eXS
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.

Re: DNSSEC

Posted: Sat Jul 07, 2018 12:30 pm
by pe1chl
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)

Re: DNSSEC

Posted: Sat Jul 07, 2018 2:42 pm
by R1CH
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.

Re: DNSSEC

Posted: Sun Jul 08, 2018 9:17 am
by DummyPLUG
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?

Re: DNSSEC

Posted: Sun Jul 08, 2018 7:08 pm
by pe1chl
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.

Re: DNSSEC

Posted: Sun Jul 08, 2018 7:12 pm
by Cha0s
such as when you need to force some domain resolve into specific IP?
Ever heard of hosts file?

Re: DNSSEC

Posted: Wed Jul 11, 2018 12:33 am
by Buster2
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.

Re: DNSSEC

Posted: Sat Sep 15, 2018 8:43 pm
by Anastasia
+1 for DNSSec
how long will you do it? why so long?

Re: DNSSEC

Posted: Sun Sep 16, 2018 3:13 am
by Sob
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.

Re: DNSSEC

Posted: Sun Sep 16, 2018 12:57 pm
by pe1chl
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)

Re: DNSSEC

Posted: Sun Sep 16, 2018 6:43 pm
by Sob
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.

Re: DNSSEC

Posted: Sun Sep 16, 2018 8:12 pm
by Joni

Re: DNSSEC

Posted: Sun Sep 16, 2018 8:23 pm
by pe1chl
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.

Re: DNSSEC

Posted: Sun Sep 16, 2018 9:31 pm
by Sob
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.