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:
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!

1) It has nothing do to with device memory

2) It has nothing to do with allowing remote requests

3) So you already know the answer.

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

@lekozs

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...?

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.

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:

Code: Select all

/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!

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.

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.

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.

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
viewtopic.php?f=13&t=175129&p=856824#p856824

extract code

/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"

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 ...

Since I am not a full-time MK/RouteOS admin (only from time to time), thank you for your clarification.

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.
As I said before this was not my building, my only error was I didn't do the proper take-over, as a "sign of pride" (I think this you meant, please correct me if I am mistaking) not at all, more sign of shame . . . . as I hope you can understand as a fellow tech DB. . . . .

v6, but are like the same for v7
viewtopic.php?f=13&t=175129&p=856824#p856824

extract code

/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"

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"