Mikrotik DNS infrastructure broken since Jun 17th

Site Feedback
1

RIPE-Atlas-measurement-181717798.json (14.8 KB)

Since yesterday, June 17th at around 12:02 UTC the DNS servers for the mikrotik[.].com and mt[.].lv are not responding to a good part of the Internet.

The servers are: 159.148.147.24 and 159.148.172.248.

They seem to be answering to some well known public recursive DNS services (Google, Cloudflare, Quad9) but seem to be ignoring queries from others.

As a matter of fact I have tested it with RIPE Atlas using 50 random probes around the world and 46 out of 50 have failed.

Some networking change, firewall rule or whatever has triggered this error. It seems that, for anyone not using one of the well known recursive DNS servers, Mikrotik is out.

I include the RIPE Atlas report.

2

Good point...

https://s.ping.pe/L/1/snap_L1rChab2.html

3

Seems that it is working now, first responses received at 10:07 UTC today.

4

I can also confirm that it's working again and that I had the same problem.

dig moon.mt.lv +trace

; <<>> DiG 9.20.23-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu <<>> moon.mt.lv +trace
;; global options: +cmd
. 428569 IN NS h.root-servers.net.
. 428569 IN NS m.root-servers.net.
. 428569 IN NS e.root-servers.net.
. 428569 IN NS b.root-servers.net.
. 428569 IN NS j.root-servers.net.
. 428569 IN NS d.root-servers.net.
. 428569 IN NS c.root-servers.net.
. 428569 IN NS f.root-servers.net.
. 428569 IN NS a.root-servers.net.
. 428569 IN NS i.root-servers.net.
. 428569 IN NS g.root-servers.net.
. 428569 IN NS k.root-servers.net.
. 428569 IN NS l.root-servers.net.
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 0 ms

;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for moon.mt.lv failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for moon.mt.lv failed: network unreachable.
;; no servers could be reached
;; UDP setup with 2001:7fe::53#53(2001:7fe::53) for moon.mt.lv failed: network unreachable.
;; UDP setup with 2001:503:c27::2:30#53(2001:503:c27::2:30) for moon.mt.lv failed: network unreachable.
lv. 172800 IN NS b.nic.lv.
lv. 172800 IN NS a.nic.lv.
lv. 172800 IN NS c.nic.lv.
lv. 172800 IN NS d.nic.lv.
lv. 172800 IN NS n.nic.lv.
lv. 172800 IN NS nu.nic.lv.
lv. 172800 IN NS sunic.sunet.se.
lv. 86400 IN DS 42018 8 2 7E932A4F9CF9B1CD047C277E3CD323A53D42347D47C7BF1DD6018FF4 B344FC1C
lv. 86400 IN RRSIG DS 8 1 86400 20260701050000 20260618040000 54393 . sXdz8qwNWEt4YCYKvQgDJP2a43ZWC7UeG29HTpM8V7Uph0DDoN7hYCbC V6F3PbPdQNLPkp0bxZT4XzAKVswS5ZlSkOYiEGQqyZQ/ZLz5WuA0GMGB 6yory7BJQJmCwSv+fNML1+kr4DSDqsY/HJPKFFuh4+pKVuAotBI04YAP P2KRUvkqh5LbJ8Pu/ZuihHduaYNMVlU1s4RklMIIOPSfL4iml9AIo1r9 3OzMLMlgCSDnV2RrF6bSU2i4jdPTd4DRJpQF7T8r221W89XJ5/Si5M6d ZeV1dB4udTJ557O84d3TmnPU361l+b/PuoW9yIhFWpvuHfEtaz1V3qJ2 e7ebPg==
;; Received 811 bytes from 192.36.148.17#53(i.root-servers.net) in 5 ms

;; UDP setup with 2001:678:7c::7c#53(2001:678:7c::7c) for moon.mt.lv failed: network unreachable.
;; UDP setup with 2a01:3f0:0:312::53#53(2a01:3f0:0:312::53) for moon.mt.lv failed: network unreachable.
mt.lv. 1800 IN NS ns1.mt.lv.
mt.lv. 1800 IN NS ns2.mt.lv.
98069SFTH4TTNF008C49C783M75J5J7B.lv. 1800 IN NSEC3 1 1 10 4DDE32DD446FBC9D 981LBIH44EE4AFFH9I63SCQ57CLA7R3B NS SOA RRSIG DNSKEY NSEC3PARAM
98069SFTH4TTNF008C49C783M75J5J7B.lv. 1800 IN RRSIG NSEC3 8 2 1800 20260622110043 20260612100101 31113 lv. DQLanZNdfLLFA+0nMVnDiUduuZkgrIeqLR6vODreQynxVPOM3Sw0tqBv NydKiI4ig4VTIo/m3Or00nrfA51xJj3ULTM2tJDa8ox996GIId1HY7Wv Czng0w2JAKxH7+ghnu+Q2HqbCz9TC+4gXz/2GY7KkdyayOtcVkFJCcVw 49B5X5sgI1YiJKDWljwcB9QwZZ+TBYUpBNnKO4uxME8zN7uHmA7MsF4W H0dTJ7d5YaiIDO3YLf8ieA7Fej1ZJd71PUWVbA6LPFG9+llAXI3gqaWL WzPRAkkfN6SI+UASyLakuwxd4onvrpFbgT93lxNwxduWjZZUPy79jLlZ 1boI1w==
GROHGTV7JFASPH7SKNG9A2B60G1SNE06.lv. 1800 IN NSEC3 1 1 10 4DDE32DD446FBC9D GRSP81G5B8MV3OU3TP6T9SNVF4RBOT5E NS DS RRSIG
GROHGTV7JFASPH7SKNG9A2B60G1SNE06.lv. 1800 IN RRSIG NSEC3 8 2 1800 20260626080923 20260616075948 31113 lv. sMj0nvEPGopDkApTcXhy1k0P+HVvU8AcehYQubCr3XG4euzxxAMzWN5M 5ou28XfLcv2U+CgtA6NxUF3QDVvO1qWEJriDrA7NzTAjct/UYE1yzd5z di/3ZSfx+w54iUzcR6Nzlg2LZW7IczLoEbU0wh6B9HEcPAvp2gnLMoXu p0UUIfCPboqHtgMB/uaVzF+2gjPGFQ8cMuWb9f+oISPme3yaY41OdRFy ZamJQE9jSH575WVLqVNgcwOA9gfXJEPLwtuwT/C2Hk5FjflCgohhj5hr mSLmuh35J4/fs6+niz7p8FccXMnWUOgaGKbVaNaZaRZP+tZ5aTe6/tAi 7Pr9BA==
couldn't get address for 'ns1.mt.lv': failure
couldn't get address for 'ns2.mt.lv': failure

5

I'm still curious at the root cause here. FWIW, I wrote up the "clunkers' view of the DNS issues" here: ✨ Steering AI to use new manual.mikrotik.com - #16 by Amm0 for anyone curious.

On this one...

The mt.lv theory might have merit... I'd commented in new docs FEEDBACK thread should have a "7. Shortened URL using https://docs.mt.lv/... —> https://manual.mikrotik.com/docs" since the "manual.mikrotik.com" is kinda long. To which @normis has a curious response:

... which I thought was kinda odd response, since a DNS record and HTTP rewrite should not actually be hard for folks who make an OS and run DDNS/VPN/file-share services (BTH). IDK, but combine with the DNS issues, maybe @normis is was right.

6

The servers did not respond, simply.

I tried polling them manually and there was no response. Either they had some routing problem affecting the network segment where those servers are, or someone fat fingered a firewall configuration.

Or they have views configured and someone broke the configuration, or it was an anycast problem...

I saw once a very funny situation when someone put a firewall filter specifying a series of authorised countries in front of an authoritative DNS server.

7

We use mt.lv for other things, so it's taken. We need a different shortener.

8

Fair enough, some shorten domain be a nice-to-have... Point was reliable DNS is a must-have. IDK the root cause, maybe not even y'all fault. But... some status page (outside the community-built one, https://mikrotikstat.us) is hopeful in the "documentation overhaul".

Without some communications, it leads to the IT version of Don't F*ck With Cats on the culprit on something like a DNS outage.