MikroTik

DNS Cache stores a lot of junk names with type unknown and ip address of 0.0.0.0. As you can see in attached image there are more than 40000 of them, they occupy all dns cache and decrease system performance.

Or, uh not that?

Alli - I believe you should find out which device in your network is causing that. Entries like this usually appear, when DNS request cannot be resolved. Maybe there is some rogue software trying to scan stuff? If you start logging DNS, it might help you.

Alli - I believe you should find out which device in your network is causing that. Entries like this usually appear, when DNS request cannot be resolved. Maybe there is some rogue software trying to scan stuff? If you start logging DNS, it might help you.

There are more than 200 client in our network which I don't have access to many of them. Also it can happen in any Hotspot network and can be considered as a DNS attack. So it's Mikrotik job to handle it. I don't even know if these type of queries are valid or not?

Anyway I believe mikrotik should not at least cache entries which can't resolve. And for more protection there must be count rules in firewall to add rouge clients to blacklist.

You should set your "cache max ttl" drastically lower (e.g. 00:05:00) and you may also be able to increas the cache size, depending on how much available memory you have in your router.
The DNS resolver in RouterOS is quite primitive. In a decent resolver you can set a separate cache max ttl for successful and unsuccessful lookups, so you can set a really low ttl for the latter.
When you need to operate in a hostile environment it is probably better not to use the MikroTik resolver at all (directly assign public DNS servers to your clients via DHCP and remove the "allow remote request" setting in RouterOS). Or add some general purpose system (e.g. a Raspberry Pi) running a decent resolver. Then you can also offer DNSSEC.

There are more than 200 client in our network which I don't have access to many of them.

You dont need access to the clients. You can either sniff packets or log DNS service. First task is always "find out why is it happening". Then it is much easier to figure out solution. It could even come from internet, if your firewall rules are misconfigured. Unless you find out source of these requests, it is hard to suggest good solution.

can be considered as a DNS attack

Fully agree.

So it's Mikrotik job to handle it.

Disagree. Administrator is always responsible for setting his device. Maybe you meant hiring certified consultant?

I don't even know if these type of queries are valid or not?

And that is the problem. As said earlier, you need to find out. We cant do it remotely. To me, it seems like someone is querying 00000000 - FFFFFFFF. those are perfectly valid and possible hostnames which may exist on some network.

I believe mikrotik should not at least cache entries which can't resolve.

Does that mean, you would like your mikrotik to open connection to another DNS and do the resolve again and again, even if it know that it cant be resolved? Such approach opens plenty of other attack options. Caching is normal. It is up to you to set up cache. For example you can lower maximum cache TTL, so entries will not stay that long.

there must be count rules in firewall to add rouge clients to blacklist.

There are such rules. You are probably talking about something like dst-limit with mode "src-address" and action=add-src-to-address-list


Or you can simply ignore setting and do what Pe1chl suggested - disable remote requests on your mikrotik and use either public service or dedicated device.

Does that mean, you would like your mikrotik to open connection to another DNS and do the resolve again and again, even if it know that it cant be resolved? Such approach opens plenty of other attack options. Caching is normal. It is up to you to set up cache. For example you can lower maximum cache TTL, so entries will not stay that long.

So the DNS client can have an option to let administrator decide whether to cache Unresolved Names or not and I would definitely enable it. A good client wouldn't query unknown names again and again. Then we can handle the bad client in the firewall.

Good client wouldn't send nonsense queries either. And if you could handle the bad client in firewall then, why not now?

A good client wouldn't query unknown names again and again. Then we can handle the bad client in the firewall.

Actually a lot of repetitive queries for names that do not exist are made; probably even more than for repeated queries of valid names.
That is the reason that failed lookups are cached as well, so a quick failure response can be returned.
I would recommend you to so a "packet sniffer" trace for port 53 on your network, output to a file and display it using wireshark.
You will be amazed at how much senseless traffic you see.

Good client wouldn't send nonsense queries either. And if you could handle the bad client in firewall then, why not now?

Because before handling it, DNS cache would be filled with junks, and also there is no way to flush cache selectively. Anyway I don't see any reason to cache unresolved names.

A good client wouldn't query unknown names again and again. Then we can handle the bad client in the firewall.

Actually a lot of repetitive queries for names that do not exist are made; probably even more than for repeated queries of valid names.
That is the reason that failed lookups are cached as well, so a quick failure response can be returned.
I would recommend you to so a "packet sniffer" trace for port 53 on your network, output to a file and display it using wireshark.
You will be amazed at how much senseless traffic you see.

In my dns cache I have this entry dnvclmuzcznwqxz, I really don't think anyone else query it!

There are often a lot of queries for reverse of IP addresses in RFC1918 networks. Those are repeated all the time.
Names like your example are queried by some browsers (e.g. Google Chrome) to detect if the DNS is rigged (some providers reply with the address of an advertising site for every nonexisting name) and also to detect hotspot portals.

It seems that 0.0.0.0 and strange entries have something to do with chrome dns queries. I read somewhere to use opendns as upper DNS Server will solve the problem but i have not tested it because I need adguard DNS Servers.