I have a DNS resolver question: is it to be expected that Mikrotik DNS cache can contain 2 different entries for a) the same name and b) same type?
I guess the answer is: yes, perfectly valid. But I am asking because in this case it happened, that DNS cache was somehow bypassed ("resolvectl query foo.example.com --cache=no") took very long and were - verified - sent to upstream DoH resolver. Instead of serving from cache.

The above DNS content is invalid. You cannot have two CNAME records for the same DNS name!
But just like many DNS servers will not enforce that or will only issue a warning (and similar for web-based DNS editors), most DNS resolvers will not check for upstream errors and will just cache whatever garbage they are presented.

But yes, the cache can contain multiple entries for the same type as that (except for CNAME) is usually allowed.

*) dhcpv6-client/server - added support for DHCPv6 reconfigure messages;

Regarding the "allow-reconfigure" property added to "/ipv6 dhcp-client" that is set to "no" by default:

I feel tempted to set it to "yes". Are there any good reasons not to do so?

If the DHCPv6 Server from my ISP sends a reconfigure message, I suppose it must have a valid (and important) reason to do so (perhaps it could be that some internal maintenance happened and the previous lease I had is not valid anymore?). I have no security concerns, since I have a PPPoE Client connection and the IPv6 firewall only allows UDP packets with destination port 546 coming from link-local addresses (so, that pretty much guarantees that the DHCPv6 messages are coming from my ISP).

on the CCR2116-12G-4S+ router, the Webfig skin designer is not working with v7.17. File is present on the correct place (skins/skinname.json) but is not selectable via System/User/Groups menu.

If you move the file to /flash/skins/ directory and reboot, it works. It seems to be just a broken path issue (not solved in 17.1 and 17.2...)

on the CCR2116-12G-4S+ router, the Webfig skin designer is not working with v7.17. File is present on the correct place (skins/skinname.json) but is not selectable via System/User/Groups menu.

If you move the file to /flash/skins/ directory and reboot, it works. It seems to be just a broken path issue (not solved in 17.1 and 17.2...)

.
Seems to remain unfixed on v7.18 (all betas and now RC1) as well. Just ignored (to this date).

Does anyone know, how to deal with error "could not save configuration changes, not enough storage space available"? Occured while trying to update f/w from 7.17 to 7.17.2 ?
Device works, but is not responding to any config changes, even reset configuration or reboot terminal commands.

I had this issue also on a Hex - hard reboot does nothing as any config changes are lost so you cant even uninstall a package etc. I did a backup to flash card (although it also allowed me to put this in root so methinks its just misreporting)
hard reset device and then restored.

upon restore I watched the free space - was on about 900KiB - this went down every now and then but recovered, didnt take 30 minutes and device was in same state - seems like if it gets itself down to 0 it doesnt free anything to recover. followed process again, and this time uninstalled wireless package straight away (I use this device to manage capsman for a network) - after that ended up with 2500KiB free space and although its still wildly fluctuating down to 1500 or so sometimes it seems stable.

I also run the dude on this device using the flash card but the dude package is 1300 by itself so can junk that if I really have to, just wish I knew where the space is being used up and then freed up continually

Bug report (second time): The serial-based console on the CCR2216 will find itself stuck in used/non-free mode after a while, even when there are no active connections. The only way to restore it is to disable it then enable it via the web interface (since the console is unavailable via serial). This problem was introduced with 7.17.





The pics above show 1) when the problem occurs 2) immediately after the console is disabled/enabled 3) slightly later when things get back to normal. With the 2nd pic, we're not sure why the console shows both "used" and "free" at the same time, but somehow it does.

For the record, we have a node that connects to the router via serial to collect some key KPIs every 5 minutes, we get notifications from that node if the switch is unreachable, and that's how we know. It does take several days for the problem to show up, it's not instantaneous and appears to happen randomly. Last time the problem happened, we disconnected the serial interface and tried to reconnect via another computer, to weed out the possibility that the computer connecting to the router was the problem--the problem was still there.

Are the following openssh vulnerabilities a problem for RouterOS v7.17.2?
CVE-2025-26465: MitM attack against OpenSSH's VerifyHostKeyDNS-enabled client
CVE-2025-26466: DoS attack against OpenSSH's client and server

Thanks

It's been said that ssh in ROS is not based on OpenSSH. So in theory those vulnerabilities are not present in ROS. In practice they might or might not be ...

It's been said that ssh in ROS is not based on OpenSSH. So in theory those vulnerabilities are not present in ROS. In practice they might or might not be ...

.
and just in case, better not let SSH ports open to the world anyway :) If the service is not acessible to the bad guys, there's no vulnerability!

@mikrotik, is there any plans for a 7.17.3 release, or no? I've got hundreds of MikroTiks to update and I'd hate to upgrade everything to 7.17.2 only to find out that 7.17.3 is released a week later... not looking for any specific timeframes or anything, just wondering if another point release is at least planned or not?

I always wait until the next version (i.e 7.18) goes stable before I would update to 7.17.2, that way I know ive got the lastest bugfix version.

after update RB952Ui-5ac2nD 7.15 > 7.17.2 ports are not working, wifi too
i cant access to router, even with netinstall (because ports are not working)

Most likely the RB952Ui-5ac2nD died due to lack of storage during the upgrade. But netinstall should work.
I had to netinstall a CCR1009 and ran into an issue because apparently the bootloader had been set to "flash-boot" and would not netinstall. I think it is due to a change in 7.16 firmware.
In that case I could netinstall it by entering Ctrl-E on the serial port to defeat that. Would not know how to do that on a lite device.

@mikrotik, is there any plans for a 7.17.3 release, or no? I've got hundreds of MikroTiks to update and I'd hate to upgrade everything to 7.17.2 only to find out that 7.17.3 is released a week later... not looking for any specific timeframes or anything, just wondering if another point release is at least planned or not?

I always wait until the next version (i.e 7.18) goes stable before I would update to 7.17.2, that way I know ive got the lastest bugfix version.

That is why I think we need a channel named like "previous-stable"

Most likely the RB952Ui-5ac2nD died due to lack of storage during the upgrade. But netinstall should work.
I had to netinstall a CCR1009 and ran into an issue because apparently the bootloader had been set to "flash-boot" and would not netinstall. I think it is due to a change in 7.16 firmware.
In that case I could netinstall it by entering Ctrl-E on the serial port to defeat that. Would not know how to do that on a lite device.

I cant reach by netinstall because of not linking on ports

I cant reach by netinstall because of not linking on ports

Failed upgrade of ROS doesn't affect ability to run netinstall by itself. Failed routerboard upgrade could ... but for this reason there's backup routerboot which can be invoked by pressing button during powering up the device. Backup routerboot is also able to initiate netinstall process ... The "non working ports" problem could well be result of a boot loop or something like that ... which (again) isn't affected by failed ROS upgrade.

As well: netinstall is pretty fragile process and even on perfectly working device it might take a few tries before it starts to work (communication between device and management PC).

It seems that in 7.16 there have been changes in the firmware to allow devices to return to factory state when a reset-configuration is done (either using command or the button) and it apparently sometimes gets invoked incorrectly, blocking a netinstall.

I always wait until the next version (i.e 7.18) goes stable before I would update to 7.17.2, that way I know ive got the lastest bugfix version.

That is why I think we need a channel named like "previous-stable"

Or you could even call it "Long term"