Incorect message "getaddrinfo ENOTFOUND" on 4xx sites about uptime-kuma HOT 5 OPEN

site that required [...] dns [...] headers

What is a DNS header?

getaddrinfo ENOTFOUND test.xyz

• What is the TTL of the domains you are using?
• Do you have DNS caching enabled in the settings?

Most commonly, this issue is caused by you using a DNS resolver which does not like the level of DNS requests it is getting.
=> your DNS Server is dropping SOME requests
=> have you enabled NSCD in the settings to lowered the amount of DNS requests to your TTL (instead of on every request)

Filesystem used to store the database on: longhorn, so probably ext4

Longhorn is not ext4.
I am assuming you are using ReadWriteMany as I cannot find any guarantees about ReadWriteOnce based longhorn in their wiki.
Please refer to the warning from our wiki:

from uptime-kuma.

What is a DNS header?

You stripped to much, to get right response with 2xx code I needed to configure DNS zone in core dns service in kubernetes as well as some auth headers for that site. First step should allow to resolve ip correctly and get 4xx response, second changes that into 2xx code.

Longhorn is not ext4.
I am assuming you are using ReadWriteMany as I cannot find any guarantees about ReadWriteOnce based longhorn in their wiki.

It's ReadWriteOnce, in attached pod stat returns overlayfs for data directory,

from uptime-kuma.

I think you overlooked the section on getaddrinfo ENOTFOUND test.xyz

from uptime-kuma.

Is this error for DNS only or also for 404?
I left some links before DNS zone was fixed and all of them still reports that, I'm sure tat it's not cache or anything. I think that 404 message is clear, but I cant see that one until monitor configuration is ok for 404 and roll back.

from uptime-kuma.

The Incorect message "getaddrinfo ENOTFOUND" [...] is a DNS error if that is what you are asking about.

About the other issue you are having:
The timeline for this one is super unclear to me.
(What did the server return, what did we log)

What is true is that we will not consider DOWN-DOWN transitions as important events => will not push them to the log.
The reason for this is that otherwise you might end up with a wall of notifications that your device is flip-flopping between two down states.
I assume users don't actually want such spam.

from uptime-kuma.