DNS Test broken after update from 1.6.0p17.cre to 2.0.0p3.cee

Troubleshooting
1

I’m testing a nameserver if it answers authoritative for certain TLD’s.

After the upgrade the check fails:

with version 1.6.0p17.cre:

./check_dns -H aco -s signer-0.shared-0.bdorf.yars.io  -A
DNS OK: 0.028 seconds response time. aco returns |time=0.028253s;;;0.000000

with version 2.0.0p3.cee:

./check_dns -H aco -s signer-0.shared-0.bdorf.yars.io -L -A
Domain aco was not found by the server

What can be done about this? Do I need to learn python in order to write a plugin that makes this simple check?

2

btw I forgot to add the DNS response when asked with dig:

OMD[shared_2]:~$ dig aco @signer-0.shared-0.bdorf.yars.io

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.5 <<>> aco @signer-0.shared-0.bdorf.yars.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25576
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;aco.				IN	A

;; AUTHORITY SECTION:
aco.			1800	IN	SOA	a.dns.nic.aco. hostmaster.lemarit.com. 1620833559 10800 3600 2764800 1800

;; Query time: 1 msec
;; SERVER: 10.20.4.13#53(10.20.4.13)
;; WHEN: Wed May 12 15:33:32 UTC 2021
;; MSG SIZE  rcvd: 100
3

why is there the “-L” flag set? This makes only sense if the list of expected addresses is also supplied.

What happens if you use the host fqdn for this query against your DNS?
If the normal dig produces the wanted result you can also use the “check_dig” directly to get the same i think.

The used version of the monitoring plugins is also a newer one and there are some changes inside the plugins.

4

The -L flag was automatically set after the update, don’t know why.

The result stays the same with or without the -L flag.

The special point on this test is that the DNS Server is a hidden primary for a TLD. There are no FQDNs to query on that host.

Seems the persons who made updates to this test missed that also valid responses beyond A and NS records.

I’d like them to fix this.

5

To clarify the scenario a bit more:

We are talking to a name server that is responsible for a TLD. It normally only has (aside from DNSSEC stuff) NS records and maybe some A/AAAA records as glue to it’ NS entries (where subordinate to domains within that TLD).

I just like to know if the server still answers authoritativly for the given TLD.

6

I’d really love to test the check_dig plugin … but how do I find it in the UI? There is no DIG or whatever in the Service Monitoring Rules?

Thnx in advance.

Bildschirmfoto von 2021-05-17 13-05-50

7

I meanwhile found out how to use the check_dig command.

See here: Monitoring of HTTPS, TCP, SSH, FTP and further services

thanks to @andreas-doehler for the hint.

8

Then you need to make a request at the dev’s of the monitoring plugins.
In the man page for the check_dns it sounds more like that it is intended to only query A and NS records.

Yeah the naming is a little bit different with 2.0 then before.

9

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.