Well ... running query against your local DNS resolver ("server: 127.0.0.1#1053") doesn't prove much.
But running query against mikrotik's own DNS servers fails as well:
$ dig mikrotik.com @159.148.172.248
; <<>> DiG 9.16.50-Debian <<>> mikrotik.com @159.148.172.248
;; global options: +cmd
;; connection timed out; no servers could be reached
The IP used as server is returned by one of global DNS resolvers (8.8.8.8) as official DNS server for domain mikrotik.com ... two are listed and both are unresponsive at the moment. If none of authoritative DNS servers for a certain domain is working, then that domain inevitably "disappears" from the internet. Depending on caching in upstream DNS resolvers for some this happens sooner and for others later.
For me, connectivity breaks somewhere beyond Arelion's POP (a.k.a. twelve99 ... nee telia/teliasonera) in Riga:
10 hbg-bb3-link.ip.twelve99.net (62.115.124.26) 24.992 ms * 24.770 ms
11 sto-bb1-link.ip.twelve99.net (62.115.134.95) 45.060 ms 44.656 ms 44.906 ms
12 riga-b5-link.ip.twelve99.net (62.115.140.1) 55.372 ms 55.516 ms 61.834 ms
13 siatet-ic-332270.ip.twelve99-cust.net (213.248.84.33) 56.330 ms 56.167 ms 56.247 ms
14 * * *
15 * * *
16 * * *
17 * * *
For web service (159.148.172.205) it's same path, but server does respond as hop #17 .
I did not dig much deeper into it except checking that nothing has changed at my side.
My bind named server is behind the 127.0.0.1 ip and get it's upstream from global DNS's.
Just strange that the situation was the same yesterday...if mikrotik.com nameservers really are "gone" then I would expect that other dns server also would "loose" mikrotik.com
And my ISP dns still solve mikrotik.com ok at this moment.
If I understood the Redhat note correctly then where it possible to config a caching server to circumvent problem with the misconfigurated remote server...but not advisable.
Anyway maybe someone from Mikrotik read this and look into the problem
Caching servers will cache (positive) replies up to specified TTL. And TTL starts counting down after record is retrieved from authoritative DNS server. Caching servers won't fetch record from upstream servers if they have record cached and its TTL is still valid. Which means that there's nothing opportunistic in caching DNS records, it's built-in the system.
DNS for mikrotik.com seems to have default setting for TTL of 21600 seconds (which is more or less 6 hours). Any other caching DNS server, fetching data from (already caching server) will get TTL value of whatever TTL will be on the upstream server at the time of fetching. Which means that in this case a deep DNS caching infrastructure won't help ... everybody below top-most caching server will have the same TTL.
However, DNS server @8.8.8.8 seems to return entries with maximum TTL all the time. This either means that server 8.8.8.8 has different connectivity to MT's own DNS servers (which still works) ... or that Google's DNS servers invent TTL for cached entries if needed (and can then serve stale records in case that authoritative servers are not available).
BTW, it seems that 8.8.8.8 is yet another of Google's geographically-spread services, so not everybody using 8.8.8.8 will be actually using same servers but rather locally hosted ones.
[edit] I was wrong about google's DNS inventing TTL. It seems that google hosts a few DNS servers topologically close to me and when I was executing same dig command a few times ... I was actually hitting different servers (which fetched the requested record from authoritative DNS server(s) and thus replied with same max TTL). After a while I reran the same query and now I'm getting TTL appropriately lower and different every time I'm executing the dig command. And shown TTL varies randomly up and down ... with systematic tendency towards lower values.
And then there is optimistic caching (as I mentioned prior) as used by AdGuard:
"cache_optimistic` (since v0.107.0) — Make AdGuard Home respond from the cache even when the entries are expired and also try to refresh them"
Not sure if anything else does similar, but with a TTL of just 6 hours (and having lost this 2 or 3 days ago) even that gave up . . . (The point being that some will still return results with expired IP's, at least for some period.)
It seems that ns1.mt.lv and ns2.mt.lv which are NSes for mimas.mt.lv and moon.mt.lv (NSes for mikrotik.com) are unreachable over IPv4 but reachable over IPv6. I bet they're hosted on RouterOS and no one set up any monitoring to fix it, because having your NSes down for over 10h as networking company is downright comical. I suppose all budget went into AI tokens to maintain containers, after all having Prowlarr hosted on your MikroTik hAP is more important than having properly working networking stack.
Not likely. The IP lookup for the nameservers will be a part of the SOA with the registrant (you can't serve DNS to a device trying to to find the server from the server "You can't get there from here" applies. Seems more like thier domain registrant screwed the pooch from here.
(Similar result for moon and mimas . . . most servers can't resolve those or the mt.lv SOA either.)
What? MikroTik is hosting its own NSes, so we're looking at simple glue record (aka ADDITIONAL section). Your browser asks for forum.mikrotik.com, your OS will ask:
Root servers (via root hints) for NS of com -> a.gtld-servers.net;192.5.6.30
NSes of com for NSes of mikrotik.com -> moon.mt.lv
Root servers (via root hints) for NSes of lv -> a.nic.lv;194.0.48.1
NSes of lv for NSes of mt.lv -> ns1.mt.lv;159.148.147.248
NSes of mt.lv for A and AAAA of NSes of mikrotik.com -> 159.148.147.194
NSes of mikrotik.com for A and AAAA of forum.mikrotik.com -> [global-balancer-d.mikrotik.com]
NSes of mikrotik.com for A and AAAA of global-balancer-d.mikrotik.com -> 159.148.147.244
While going through this, NS records of mt.lv will be requested from NSes of lv, and ADDITIONAL section will be provided with A and AAAA records of NSes handling mt.lv (ns1.mt.lv and ns2.mt.lv). We fail at the step where we query ns1.mt.lv for A and AAAA of moon.mt.lv.
mt.lv. 1800 IN NS ns2.mt.lv.
mt.lv. 1800 IN NS ns1.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==
ns1.mt.lv. 1800 IN A 159.148.147.248
ns2.mt.lv. 1800 IN A 159.148.172.248
ns1.mt.lv. 1800 IN AAAA 2a02:610:7501:3000::248
ns2.mt.lv. 1800 IN AAAA 2a02:610:7501:4000::248
;; Received 941 bytes from 77.72.229.249#53(nu.nic.lv) in 44 ms
How and what handles ns1.mt.lv and ns2.mt.lv is purely up to MikroTik though, since that's already part of their infrastructure (mt.lv is owned by MikroTik). I was half-joking about them hosting it on RouterOS because they previously made a big deal of dog-fooding their products, though clearly they have 0 notifications set up as it's now been a day since these NSes been unavailable over IPv4. It sure would be good time to drop some 0-day CVE on WinBox protocol :>
Yes, they host thier own nameservers . . . . But something upstream has to point to them, or they will never be found.
(I host my own, and have done numerous Corporate deployments . . Finding the authoritative NS for a domain, it's done via the NS record(s) (errantly said SOA prior, but that is also related) which is associated with the DNS root servers, which is what appears to have become wonky. You have to have the NS record to find Mikrotiks name servers - it's not magic or telepathy - the Mikrotik nameservers cannot serve rexords on how to find themselves.
(As an example, when I manage my domain with Network Solutions (the registrant), I have to enter the IP of my nameservers (and they aren't it . . .) to seed the root servers.
They host two levels of their own NSes - ns1/2.mt.lv and moon/mimas.mt.lv. The former handles mt.lv while latter handles mikrotik.com. It was ns1/ns2 (so entire mt.lv) that was unresponsive over IPv4 and you were being pointed to them from NSes of lv itself via glue record (see response attached in post above, nu.nic.lv gave you A for them.