Page MenuHomeMiraheze

Misleading messages from icinga rDNS checks regarding unregistered domains
Open, LowPublic

Description

The reverse DNS check, when faced with a domain that for example has no authoritative nameserver, like zhacg.wiki, returns a technically correct but still misleading message about what is going on.

Here is the response from .wiki's authoritative namserver regarding zhacg.wiki

kdig @a.nic.wiki zhacg.wiki
;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 31986
;; Flags: qr aa rd; QUERY: 1; ANSWER: 0; AUTHORITY: 1; ADDITIONAL: 0

;; QUESTION SECTION:
;; zhacg.wiki.         		IN	A

;; AUTHORITY SECTION:
wiki.               	900	IN	SOA	a.nic.wiki. admin.tldns.godaddy. 1706903095 1800 300 604800 1800

;; Received 93 B
;; Time 2024-02-02 20:54:47 CET
;; From 37.209.192.10@53(UDP) in 17.3 ms

We get a NXDOMAIN, because the domain is actually on clientHold status and about to expire.

Here is what Icinga tells us on #miraheze-sre though.

rDNS WARNING - reverse DNS entry for zhacg.wiki could not be found

which is technically true, but misleading. It should treat this as a CRITICAL, not as a WARNING.

Event Timeline

Fix for this would be having a separate exception handler for NXDOMAIN, instead of bundling it together with NoAnswer (https://github.com/miraheze/puppet/blob/fec5c1dfa8dd4592a727c41bc4e29155c229feca/modules/monitoring/files/check_reverse_dns.py#L125).

RhinosF1 triaged this task as Normal priority.Feb 2 2024, 20:01
RhinosF1 added a project: SRE Automation.
OrangeStar updated the task description. (Show Details)
OrangeStar renamed this task from Misleading messages from icinga rDNS checks regarding domains not pointed correctly to Misleading messages from icinga rDNS checks regarding unregistered domains.Feb 3 2024, 10:40
Reception123 lowered the priority of this task from Normal to Low.Feb 15 2024, 16:29
Reception123 subscribed.

Triaging as low as domains that are not pointed aren't usually even removed on sight