louislam / uptime-kuma

A fancy self-hosted monitoring tool

Home Page:https://uptime.kuma.pet

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[tteck, LXC] dns caching disabled

CrazyWolf13 opened this issue Β· comments

πŸ“‘ I have found these related issues/pull requests

None

πŸ›‘οΈ Security Policy

Description

I'm getting a very very high amount of dns traffic because of uptime kuma, as it queries dns every 60 seconds for hundreds of domains, could you fix that by adding some sort of cache?

πŸ‘Ÿ Reproduction steps

Add a good amount of https domains, leave scrape time at default

πŸ‘€ Expected behavior

Very little dns traffic, possibly once an hour, this would remove 60x dns traffix

πŸ˜“ Actual Behavior

Every 60 seconds my dns server get's flooded with requests

🐻 Uptime-Kuma Version

1.23.11

πŸ’» Operating System and Arch

I run Arch btw.

🌐 Browser

Google Chrome 124.0.6367.61

πŸ–₯️ Deployment Environment

tteck's helper scripts via LXC on proxmox: https://tteck.github.io/Proxmox/

πŸ“ Relevant log output

No response

You can activate nscd (Name service caching daemon) in the general settings.
By default, we respect the timeouts you configured in your DNS-Configuration:

image

@CommanderStorm That's amazing, did not know something like that exists!

Update: I cannot view that im my settings !?
image

Overlooked that you have installed a script by a third party.
=> please consider either contacting them refering to this issue or use the docker container we provide at https://github.com/louislam/uptime-kuma/wiki/%F0%9F%94%A7-How-to-Install#-docker

The reason is that your installation option does

  • not install and
  • not configure nscd

We for now only enable this feature (and some others like "real browser") in containers to make the support effort somewhat manageable.

/**
* Start all system services (e.g. nscd)
* For now, only used in Docker
* @returns {void}
*/
async startNSCDServices() {
if (process.env.UPTIME_KUMA_IS_CONTAINER) {
try {
log.info("services", "Starting nscd");
await childProcessAsync.exec("sudo service nscd start");
} catch (e) {
log.info("services", "Failed to start nscd");
}
}
}

You can find the configuration file here:
https://github.com/louislam/uptime-kuma/blob/1.23.X/docker/etc/nscd.conf

Okay I see, thanks for pointing that out, i'll let tteck know.

You can activate nscd (Name service caching daemon) in the general settings. By default, we respect the timeouts you configured in your DNS-Configuration:

image

I installed the service, injected your config and removed the part that checks for the variable in the shown code snippet, however at restart the js file was immediately rebuild, any hints on getting this to work?


As the owner is not really that happy minded to implement it, I tought I can use the dns cache for http(s) domains, however after activating still each and every request went to my pihole instance.

image

js file was immediately rebuild

It is actually just downloaded to prevent OOM errors. See the third party script you use:

npm run download-dist &>/dev/null

Either you:

  • pretend to be in docker via the UPTIME_KUMA_IS_CONTAINER environment variable and deal with missing dependencies
  • use the installation opion (docker) from our wiki which includes all dependencys

Is docker variable and installing the service, starting and adding your config did not solve, but I switched to docker, makes
things easier anyway.
Thx for the help.

@CommanderStorm Sorry to reopen this topic, but even after enabling the shown option oabove, and then after a while also enabling the other settings below the dns server setting also set to on i still get sooooo many dns requests, in 3 days I got like 75k just of uptime-kuma, is there any reason this cache is not working at all and the legacy cache also not?

25k/day for 100 monitors
=> 1 request/5m for 100 monitors
A TTL=5m is imo reasonable and no DNS resolver should not have a problem with this request load1.

Let me rephrase a previous comment (By default, we respect the timeouts you configured in your DNS-Configuration) via a quote from the nscd docs:

for some name services (including specifically DNS) the TTL returned from the name service is used

=> Really difficult to gauge if this is excessive without additional data:

  • What is the TTL of the DNS server resonses? (test just some, assume the rest are the same)
  • How many monitors (total)?
  • How many monitors with unique dns-hostnames (can be a guesstemate)?

For the legacy caching please see #3762
=> legacy caching is only active for some monitoring types and only for ipv4

Footnotes

  1. A resolver can handle hundreds to thousand concurrent connections and each resolution only takes few tenths of ms ↩

I have not specifically configured nscp, is that neccessary?

Okay yeah I also don't currently see it as a huge problem, it's just making reading dns logs and such things harded and it keeps my resolving quite high.

I have got 37 monitors where roundabout 30 are different domains other ip/ping/dns

TTL for my dns server is around 5-20ms depending on the domain.

The thing is just currently there is no difference if dns cache is on or off, and in my eyes there should definitely be a notable difference.

I just enabled legacy caching as well to see if it makes a difference.

it's just making reading dns logs and such things harded

Use automated tooling such as anomaly detection or log based metrics via grafana loki and the likes.

keeps my resolving quite high

Unclear what you mean

TTL for my dns server is around 5-20ms

So basically TTL=0s => you have turned off DNS caching via this configuration
I did not know that DNS servers can be configured this low. Are you maybe confusing RTT or latency with TTL?

it's just making reading dns logs and such things harded

Use automated tooling such as anomaly detection or log based metrics via grafana loki and the likes.

keeps my resolving quite high

Unclear what you mean

TTL for my dns server is around 5-20ms

So basically TTL=0s => you have turned off DNS caching via this configuration I did not know that DNS servers can be configured this low. Are you maybe confusing RTT or latency with TTL?

It's not the thing that there are too many dns requests, but the fact that there is still the same amout than before enabling the cache, has to has to be some sort of issue....

Yes you are right I confused it with time.

Not sure how I should be able to get the ttl. but I ran the following cmd found on the web from the uptime-kuma docker container which has my dns server as dns server.

user@-Tower:~$ dig +nocmd +noall +answer +ttlid A test.example.dev
test.example.dev.     0       IN      A       10.90.60.13

So your TTL is 0 => caching is disabled

So your TTL is 0 => caching is disabled

Well then how do I activate it?

The setting in the ui is turned on.

You can enable catching by allowing a higher TTL in your DNA settings.