@Amm0 Read the file in chunks, put each chunk into an array. Then filter the array to obtain higer processing speed. Mikrotik can make that work in the background so that the load is not too high.
You have to wait then before the complete list is read in. Now it cuts each line into two parts and domain name hast be clean on bot ends.
PTR is seen as a record that can be retrieved on the fly. Then for static entries it would no harm to be able to define that also instead of the automatic version used currently.
the regex to be used in adlist would only be called when receiving the file from the web. after evaluation, static DNS names result and a lookup would not cause more regexp evaluation effort
the adlist puts the domain names only in the (RAM) cache, while running a script that adds static records will put them in flash storage, expanding the size of the in-flash configuration database (which will not reduce when you decide to stop using this method and delete all the records)
With a proper, more generic, implementation (that is why I think it should be called “hosts” rather than “adlist”) it can even be used to add static records to DNS from a hosts file, resolving them not to 0.0.0.0 but to actual addresses, allowing to sync to large local hosts lists without affecting the flash.
Not really. While true DNS does return a PTR to a "in-addr.arpa" query automatically. You cannot add a PTR explicitly. These are needed to resolve mDNS/DNS-SD per RFC-6753. e.g. you need PTR to convert service like "_http._tcp" into "mycomputer._http._tcp" to be able to statically configure mDNS lookups.
Didn't mean to go off-topic... just annoying when a standard RR type for DNS like PTR cannot be configured. Yet seeing entire new feature like adlist added to DNS instead of fixing little bugs like PTR.
You’d likely not need a CUPS printer server with DNS PTR records. Any modern printer uses mDNS for discovery, so if DNS-SD records were added to Mikrotik DNS, most printers work across VLANs/etc. (*where Mikrotik is the resolver, and if it supported PTR records)
And after writing it many times we all understood it… but you are not the only one using RouterOS so a moment of patience and let’s see what will happen.
I don’t think that anybody said that this functionality should never ever be implemented.
However it is pretty distracting if such a non-core functionality actually makes certain device types almost unusable (we have suggested numerous times to move this kind of functionality into optional package … it can be done as wireless packages prove it). And disturbing fact is that MT seems to be in denial about the installation size problem, not publishing any concrete plans on how and when the problem is going to be solved. I’m thus pretty upset to see my hAP ac2 becoming obsolete and the cause for it seems to be inclusion of non-core functionality that I definitely don’t need. I mean: any RaspberryPI is better suited to act as SMB/DLNA/whatever server than hAP ac2 and I can hardly understand people requesting this functionality (and then many of them complain about issues/bugs it comes with … instead of running RPI with standard modern samba on it where they would have zero problems … and I’d have zero problems using my hAP ac2 as a router/AP (which it’s supposed to be). And don’t get me started on container stuff … MT’s implementation is non-standard enough and HW platform is exotic enough to pose numerous challenges to anybody that wants to run containers (not to mention insufficient resources). Again it’d be easier to use a simple x86-based nettop, running some standard container platform (e.g. proper docker) … and not much more expensive either (buying a beefy MT device doesn’t come exactly cheap either).
And it’s a pretty good question about priorities (is new non-core functionality supposed to be developed before all core functionality from v6 is (re)implemented in v7) … albeit I can understand that this might not be easily solvable (I would expect to see different development teams working on different aspects of ROS and progress pace of different groups may be very different).
I also don’t deny that Samba or DLNA are useful. Both are great. I use a standalone Samba server and DLNA as well, but not on my router. I also don’t question that someone other than me might use it. What I criticize is that it comes at the expense of limited storage space. Why can’t it be an additional package? We’ve known for almost 10 years that SMB 1 is insecure—still, ROS 7 was launched with legacy protocol samba service, and in 2024, MT realized: “it would be cool if ROS didn’t just support legacy SMB protocol versions” (quote from old SMB docs: “RouterOS only supports SMB v1.0 and v2.002”; quote from new ROSE SMB docs: “SMB1 is not supported due to security vulnerabilities.”). And just like that, the main package was inflated by almost 400kb.
And disturbing fact is that MT seems to be in denial about the installation size problem, not publishing any concrete plans on how and when the problem is going to be solved.
pe1chl obviously gave up on pointing out the storage space issue. That’s why someone else has to keep repeating it. People with their bricked AC2 also contribute involuntarily.
My home/office CCR2116 stalled overnight. Log says kernel panic. I had to power-cycle it to get it to come back. It had been running for two or three days (since b6 came out) just fine. Aside from OSPF & BGP to external network, it’s got a few containers (piHole, homeassistant, open speed test, a custom SMB server based on alpine, and uptime kuma). The only thing that has changed from before the betas is that I actually got home assistant configured and it’s talking to everything on the network.