Hello!

I'm noticing a high CPU usage at different times of the day and after using the profile tool, it appeared DNS was the culprit! I checked DNS and noticed the cache is increasing rapidly and filled with weird entries.

I'm allowing remote requests and I already have a firewall rule to drop DNS requests from WAN.

I sent an email to support regarding this problem days ago, but they didn't reply!

I get the same unknown entries; except the entries are for internal nodes on intrAnet..
I already have the DNS firewall rules in place for WAN.. why do I get these UNKNOWN type entries in MT DNS cache??

mistry7 - I mentioned that I already have the rules to drop requests from WAN!

Export your DNS Config

Code: Select all

/ip dns
set allow-remote-requests=yes cache-size=20480KiB max-concurrent-queries=300 \
    max-concurrent-tcp-sessions=80 servers=8.8.8.8,8.8.4.4

to look for source of DNS traffic you can use torch.
also, if you really had made firewall rules to block dns requests from outside, don't forget that the order of rules is important in firewall (for example if there is rule that "allow all" ot smth like that before blocking - there is no sense in blocking rule).
so, if in torch the source is outside your network = your rule doesn't work. if inside - check source computer for viruses and other software

Shadeofspirit - the rules are on top of the filter list! and I also used this site http://openresolver.com to make sure it works.

And I'm running an open hotspot service, so it won't be an easy task to check for viruses!

I used torch tool and didn't notice anything suspicious!

I don't know what's causing the problem and I guess MT support don't know either because they haven't replied yet and it's been a week!

Same here. I don't have high DNS CPU usage but I DO have the unknown TYPE DNS entries in cache all internal...
Don't know what is causing them. Infected PC on the intrAnet...? How can I debug this, how can I track to the root?
And what does the 'N' stand for in the first column of the DNS cache table

Okay, so I enabled system logging for DNS and what I noticed
was that DNS queries made by PCs on the internal domain 'host.mtdomain'
are being sent out to the ISP's DNS servers for an Answer and getting
a reply back from the ISP's DNS servers with 'name error' maybe that is
where the 0.0.0.0 is getting added with unknown..?

So #1: How do I tell the MT router to NOT send DNS queries for internal domains to the ISP DNS servers?

So after capturing some DNS logging to file I was able to pinpoint what looks like a PC that is infected that is sending random DNS queries for non-existent internal hosts; example (jnyyhwarsradr.fic)
what to make of this?

dns,packet --- got query from 10.0.0.169:50391:
Nov/09/2018 14:12:35 dns,packet id:8e71 rd:1 tc:0 aa:0 qr:0 ra:0 QUERY 'no error'
Nov/09/2018 14:12:35 dns,packet question: jnyyhwarsradr.fic:A:IN
Nov/09/2018 14:12:35 dns query from 10.0.0.169: #16483371 jnyyhwarsradr.fic. A
Nov/09/2018 14:12:35 dns,packet --- sending udp query to 59.86.160.27:53:
Nov/09/2018 14:12:35 dns,packet id:f1fc rd:1 tc:0 aa:0 qr:0 ra:0 QUERY 'no error'
Nov/09/2018 14:12:35 dns,packet question: jnyyhwarsradr.fic:A:IN
Nov/09/2018 14:12:35 dns,packet --- got query from 10.0.0.169:54500:
Nov/09/2018 14:12:35 dns,packet id:fe9b rd:1 tc:0 aa:0 qr:0 ra:0 QUERY 'no error'
Nov/09/2018 14:12:35 dns,packet question: ychjbquor.fic:A:IN
Nov/09/2018 14:12:35 dns query from 10.0.0.169: #16483372 ychjbquor.fic. A
Nov/09/2018 14:12:35 dns,packet --- sending udp query to 59.86.160.27:53:
Nov/09/2018 14:12:35 dns,packet id:146e rd:1 tc:0 aa:0 qr:0 ra:0 QUERY 'no error'
Nov/09/2018 14:12:35 dns,packet question: ychjbquor.fic:A:IN
Nov/09/2018 14:12:35 dns,packet --- got query from 10.0.0.169:64073:
Nov/09/2018 14:12:35 dns,packet id:63b1 rd:1 tc:0 aa:0 qr:0 ra:0 QUERY 'no error'
Nov/09/2018 14:12:35 dns,packet question: uengnhqnsa.fic:A:IN
Nov/09/2018 14:12:35 dns query from 10.0.0.169: #16483373 uengnhqnsa.fic. A
Nov/09/2018 14:12:35 dns,packet --- sending udp query to 59.86.160.27:53:
Nov/09/2018 14:12:35 dns,packet id:56ac rd:1 tc:0 aa:0 qr:0 ra:0 QUERY 'no error'
Nov/09/2018 14:12:35 dns,packet question: uengnhqnsa.fic:A:IN
Nov/09/2018 14:12:35 dns,packet --- got answer from 59.86.160.27:53:
Nov/09/2018 14:12:35 dns,packet id:f1fc rd:1 tc:0 aa:0 qr:1 ra:1 QUERY 'name error'
Nov/09/2018 14:12:35 dns,packet question: jnyyhwarsradr.fic:A:IN
Nov/09/2018 14:12:35 dns,packet authority:
Nov/09/2018 14:12:35 dns,packet <:SOA:3600=serial:2018110801 refresh:1800 retry:900 expire:604800 min:86400 >
Nov/09/2018 14:12:35 dns done query: #16483371 dns name does not exist
Nov/09/2018 14:12:35 dns,packet --- sending reply to 10.0.0.169:50391:
Nov/09/2018 14:12:35 dns,packet id:8e71 rd:1 tc:0 aa:0 qr:1 ra:1 QUERY 'name error'
Nov/09/2018 14:12:35 dns,packet question: jnyyhwarsradr.fic:A:IN
Nov/09/2018 14:12:35 dns,packet --- got answer from 59.86.160.27:53:
Nov/09/2018 14:12:35 dns,packet id:146e rd:1 tc:0 aa:0 qr:1 ra:1 QUERY 'name error'
Nov/09/2018 14:12:35 dns,packet question: ychjbquor.fic:A:IN
Nov/09/2018 14:12:35 dns,packet authority:
Nov/09/2018 14:12:35 dns,packet <:SOA:3600=serial:2018110801 refresh:1800 retry:900 expire:604800 min:86400 >
Nov/09/2018 14:12:35 dns done query: #16483372 dns name does not exist
Nov/09/2018 14:12:35 dns,packet --- sending reply to 10.0.0.169:54500:
Nov/09/2018 14:12:35 dns,packet id:fe9b rd:1 tc:0 aa:0 qr:1 ra:1 QUERY 'name error'
Nov/09/2018 14:12:35 dns,packet question: ychjbquor.fic:A:IN
Nov/09/2018 14:12:35 dns,packet --- got answer from 59.86.160.27:53:
Nov/09/2018 14:12:35 dns,packet id:56ac rd:1 tc:0 aa:0 qr:1 ra:1 QUERY 'name error'
Nov/09/2018 14:12:35 dns,packet question: uengnhqnsa.fic:A:IN
Nov/09/2018 14:12:35 dns,packet authority:
Nov/09/2018 14:12:35 dns,packet <:SOA:3600=serial:2018110801 refresh:1800 retry:900 expire:604800 min:86400 >
Nov/09/2018 14:12:35 dns done query: #16483373 dns name does not exist
Nov/09/2018 14:12:35 dns,packet --- sending reply to 10.0.0.169:64073:
Nov/09/2018 14:12:35 dns,packet id:63b1 rd:1 tc:0 aa:0 qr:1 ra:1 QUERY 'name error'
Nov/09/2018 14:12:35 dns,packet question: uengnhqnsa.fic:A:IN
Nov/09/2018

I had a remote site start to seriously misbehave recently. The MK would crash and the CPU run at 100% Tracked it to DNS. Seems it was getting hammered with Internet packets on DNS despite an extensive set of firewall rules.
There are no port forwards and only a single management EOIP connection to our core.
I ended up inserting an additional rule below which for some reason.... yet to be determined fixed it at once! I'll have to see if the existing rule set had an error? What is odd is that the site was working perfectly for several years until recently.

Diagnosis: Accept DNS requests was disabled which fixed the issue immediately. Currently checking its not something malicious on the LAN side.

CPU dropped to ~20% max after the filter addition.

ip/firewall/filter
add action=drop chain=input dst-port=53 in-interface=wan protocol=udp

What is important to note is that the default MK rule set does not have a rule to explicitly deny DNS from the WAN. So it appears whatever was causing this is bypassing the default INPUT DROP rule.

What is important to note is that the default MK rule set does not have a rule to explicitly deny DNS from the WAN.

The default (in recent ROS versions) firewall rules for chain=input are:

So you're right, nothing explicitly drops DNS requests. However, the last rule is "drop all else not coming in via LAN inteface list" which handles DNS requests from outside as well.
So if your firewall allowed those requests, then it's due to your changes in default FW rule set. And obviously it's not possible to tell what exactly was wrong with your FW rule set if you don't shown the setup. One thing which has to be kept in one's mind when thinking about firewall setup: the default action is to accept packet. So any packet which "survives" all filter rules (i.e. none of rules match) will be accepted. The safe thing is thus to set explicit "drop all" rule at the end of chains input and forward (more explicit than the one from MT's default setup) and add needed accept rules above it. (the opposite - drop what's not allowed - doesn't work well because it's almost impossible to add all forbidden things)

CPU dropped to ~20% max after the filter addition.

ip/firewall/filter
add action=drop chain=input dst-port=53 in-interface=wan protocol=udp

Same here. Thank you so much!

Br