I get the impression that the big launch of ROS 8.0 ASAP is more important than stabilizing the system 
That’s why we haven’t lived to see a long-term version so far.
In the previous release there was a big talk about dns issues, now I don’t see many of them.
I’m currently still using direct dns because if I try to revert back, lots of things go bonkers (Ms Teams, Amazon MyTV and sometimes also YouTube in a normal browser).
Any update on this ?
Pl07R3K - Not sure what was the purpose of this message. Building multiple rc releases before stable build is exactly “stabilising”. Main goal on eacn and every new stable is to make it better than previous one. Of course, there are no bugfree versions, but we do not plan to delay many fixes for many users while waiting for fixes for some specific issues. Releasing new stable versions and stabilising version for everyone, not for some particular feature users is our main goal.
bajodel - As far as we are aware all of the major DNS issues are resolved. Also there are some new updates on docummentation page explaining how static entries work now (https://help.mikrotik.com/docs/display/ROS/DNS).
Why oh why do you do these things? 
From the new DNS docs:
If DNS static entries list matches the requested domain name, then the router will assume that this router is responsible for any type of DNS request for the particular name. For example, if there is only an “A” record in the list, but the router receives an “AAAA” request, then it will reply with an “A” record from the static list and will query the upstream server for the “AAAA” record. If a record exists, then the reply will be forwarded, if not, then the router will reply with an “ok” DNS reply without any records in it. > If you want to override domain name records from the upstream server with unusable records, then you can, for example, add a static entry for the particular domain name and specify a dummy IPv6 address for it “::ffff”.
First one small detail, I think the first sentence is wrong, because if router assumed that it’s responsible for any type, it wouldn’t ask upstream for the ones it doesn’t have.
But the important part, clearly the goal now is to override records per-type, not all as before. Ok, fine, accepted. But isn’t it pretty clear that overriding some type by discarding upstream records will be quite logical requirement? Because it’s not the same as adding records of that type with some “invalid” value. In your example, if client asks for AAAA record, it will get ::ffff. Can you guarantee that all present and future clients will handle it as wrong address they will ignore? Of course you can’t, nobody can. So why not do it properly, especially when it shouldn’t be difficult at all? E.g. add new no-data=yes parameter for all record types that will filter out any upstream records of that type (it wouldn’t actually ask upstream about them at all, since this would be local empty record of that type).
Thank you strods, I’ll take a look into that but my problem is that I’m not using static entries! It’s simple dns resolution from upstream passed to clients.
As soon as I give upstream dns to clients (via DHCP) all is working fine. If the router is the LAN dns resolver (opendns as upstream) it starts to behave badly.
I’ve had no time to dig deeper into the problem, it takes time to make captures and figure out what those “black box” are trying to do (AmazonFireTV, SmartTV, etc..) with the dns.
My notebook is almost happy with the router as dns server, but sometimes I get some strange outcome on YouTube (could be something else).
I had such issues with v7.7 (and the last beta versions leading up to that) but it has been resolved for me. You are right: it is difficult to debug, even with a detailed DNS packet trace I could not really pinpoint the problem.
The “expected behavior” of a DNS server/resolver is different from what one would guess it would be, so every time someone makes changes “to make it more efficient”, “to make the code look nicer”, or “to add some niche functionality”, it breaks.
I hope that MikroTik has made some testing tool that tests all bugs identified previously, which they can run before releasing another version where the DNS resolver was again “improved”. Because I think these same problems will keep coming back again and again.
Becaues of this new dns resolver, my ccr2216 still stay on 7.4.1, uptime=180d+, hahaha
I wish to provide an option to disable this new resolver, I dont trust this, Or else i will assign dns server in dhcp service after update ros
Ability to specify domain name with some kind of a “none” action is on its way. We do not know how it will look yet, but you will be able to add dummy DNS record that will override DNS name lookup. Yes, nobody is forced to upgrade RouterOS on every stable release. Release notes are available and if you are not satisfied with some changes, you can always wait for a while and stick with an older version.
Please keep this topic related to v7.8rc. If you want to discuss DNS changes, then please create new topic.
Yes, running scheduler for clear arp for every 5 minutes still the solution.
I got Running CCR2004 and CRS305 + l3hw offload with ospfv3 ipv6 with broadcast type. not working with p2p type and not working with ipv4.
That option is already available! You do not need to use the RouterOS resolver except for the router’s own internal queries (like to update RouterOS or to load address lists from DNS names). You can setup an alternative resolver on a separate device or as a container running on the router itself, and use that.
On our AMPRnet/HAMNET network we just use bind9 as a server/resolver, without issues (and with DNSSEC). In a container you could use unbound, for example.
What’s new in 7.8rc2 (2023-Feb-14 11:50):
*) certificate - fixed export of a certificate when the last line of the certificate is exactly 64 bytes long;
*) conntrack - improved system stability when PPTP helper is used;
*) leds - always require to set interface name when setting “modem-signal” indication;
*) lte - fixed config-less modem support (introduced in 7.8rc1);
*) lte - fixed possible memory leak when using passthrough mode on Chateau 5G;
*) ovpn-server - fixed HW encryption capability detection on ARM64 devices (introduced in 7.8rc1);
*) sfp - fixed certain optical module initialization (introduced in 7.8beta2);
Thank you
thanks.
You seriously need to upgrade the ZeroTier package!!! There have been so many bug fixes and new features since September 2021.. This release is a year and a half old!!
At this point, adding ZeroTier seems only like a marketing gimmick which a lot of people, including myself, fell for…
Thank you.
on 7.8rc2 CRLs are still ignored and users with revoked certificates are able to connect using IKEv2
SUP-108118
Do you see your case in status closed SUP-108118 or change log in 7.8rc2 that it should be fixed? If yes, make a new support case, if no, no ned for ask for it.
I am having troubles with OSPF IPv6. If I just announce regular routes via a passive interface only a few are being seen by the other routers. Currently I need to stick with redistribute connected.
Also packet sniffer slows down my IPv6 speed dramatically (off ~150 Mbit, on ~ some kbits) but only on my CCR2004.
“Also packet sniffer slows down my IPv6 speed dramatically (off ~150 Mbit, on ~ some kbits) but only on my CCR2004.”
I have a similar issue, also on a CCR2004 just for IPv6 traffic. I can generate more than 3GB/s but I can not forward more than 100kB/s.
Jotne - Please do not create a new ticket even if there was an attempt to fix your issue, but it did fail. Keep all of the conversations about a single issue within a single support ticket. Report support issues on separate tickets (single ticket, single issue) but do not start multiple tickets for the same problem. If you received an automated reply from us, then the ticket is in our queue.