I was on 7.13.X previously, never had this message in the log.
I don’t use cache on DNS queries (it is cached upstream) so my config is this:
/ip dns set allow-remote-requests=yes cache-max-ttl=0s servers=X.X.X.X
Since 7.14, I get a lot of spam in the logs on every DNS request:
cache full, not storing
buffer: memory
topics: dns, error
Please allow us to disable the cache in some other way or revert the log message!
What device are you using ?
If it is a device with 16Mb storage, 7.14 can be a ‘challenge’ depending on your config.
Side note:
If you do not want to use dns cache at all, you may also want to change this
/ip dns set allow-remote-requests=yes
Set to no.
From Help pages
allow-remote-requests (yes | no; Default: no)
Specifies whether to allow router usage as a DNS cache for remote clients. Otherwise, only the router itself will use DNS configuration.
It has nothing do to with device memory
It has nothing to do with allowing remote requests
Yes they introduced a bug where when making a DNS request that can’t be added to the DNS cache, it thinks the cache is full when the TTL is just actually 0 (the only way to disable the cache).
It has nothing to do with my 423.0 MiB available on device especially when the log outputs to memory as reported.
It has nothing to do with allowing external requests to the DNS server.
… the sad thing is, that this bug hasn’t been fixed either in 7.14.1 or in 7.15 beta6
EDIT: Nope, message re-appeared after one day, still have the bug
ORIGINAL MESSAGE:
I don’t know about you but I don’t have the messages anymore in 7.14.1
I wonder if their support is aware of this issue or should a request be open…?
In case of doubt, always create support request incl. supout.rif.
I am seeing this as well since upgrading from 7.13 this week. I have created a ticket in reference to the issue.
I found disabling “allow remote request” and re-enabling it seems to fix it. I am not certain if that’s temporary or not.
edit: scratch that, it started again..
I’ve also opened a support ticket and linked them to this thread. Will see how it goes.
Ya i have yet to get a response.
Hello,
I had the same issue and solved it by setting a firewall rule to block outside requests on port 53 UDP, The MK DNS server was acting as a public DNS server.
Your failure: As usual, in this cases, either you configured the firewall badly, or thinking you were the smartest you deleted the default rules that prevent this (and other things) from happening.
If my memory serves me right, the default settings for the MK firewall do not include a rule to block UDP traffic on port 53.
My sole oversight was not executing the correct takeover of the router. This was amid a sequence of transitions, starting with a change in the main provider. The former provider assigned IPs via DHCP, but then we switched to a provider that used PPPoE, and the existing rule was set for WAN1. Initially, this was fine, but after the transition to the new PPPoE provider, the rule ceased to apply, which went unnoticed until internet connection issues began to surface.
If my memory serves me well default firewall blocks ALL incoming traffic which did not earlier originate from the inside of your network.
Without exception (apart from ICMP).
But I could be wrong …
The default firewall rules dropping all on input at the end, so if not allowed before, nothing is allowed after.
If you write “If my memory serves me well __” it is because you have deleted the default rules, so you cannot recheck them, sinning of pride.
v6, but are like the same for v7
http://forum.mikrotik.com/t/buying-rb1100ahx4-dude-edition-questions-about-firewall/148996/4
/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment=“defconf: accept established,related,untracked”
add chain=input action=drop connection-state=invalid comment=“defconf: drop invalid”
add chain=input action=accept protocol=icmp comment=“defconf: accept ICMP”
add chain=input action=accept dst-address=127.0.0.1 comment=“defconf: accept to local loopback (for CAPsMAN)”
add chain=input action=drop in-interface-list=!LAN comment=“defconf: drop all not coming from LAN”
Since I am not a full-time MK/RouteOS admin (only from time to time), thank you for your clarification.
In the end in possible conclusion: this issue might not be a bug just a misconfiguration of the firewall where some “default” rules were deleted or any other rule in “sign of pride”
Anyone see any updates on this? We’re seeing a log full of these errors even though, as mentioned, there’s plenty of free memory.