Issues with resolving of our reverse DNS zone
Your DNS configuration "works" somehow but it is not correct fully, hence can create problems for some cases.
Here is why.
If you query directly you do get a reply:
$ dig -x 92.240.244.176 +noall +ans +nottlunits
176.244.240.92.in-addr.arpa. 3590 IN CNAME 176.128/25.244.240.92.in-addr.arpa.
176.128/25.244.240.92.in-addr.arpa. 43191 IN PTR bill3.hostio.sk.
So we got the final PTR record and we should be happy.
However, if we diagnose all the path from . (root) until 176.244.240.92.in-addr.arpa. we can see a problem.
DNSViz at https://dnsviz.net/d/202.244.240.92.in-addr.arpa/YYzr-A/dnssec/ shows it, if you look at the Errors part:
202.244.240.92.in-addr.arpa/CNAME: The Authoritative Answer (AA) flag was not set in the response. (92.240.232.232, 92.240.232.242, 2a00:10d8:11::1:0:1, 2a00:10d8:11::2:0:1, UDP_-_EDNS0_4096_D_KN)
You can see the same by using dig +trace 202.244.240.92.in-addr.arpa. PTR +nottlunits +nodnssec which gives the below (trimming the first steps at root and 2 domains):
[..]
92.in-addr.arpa. 86400 IN NS ns3.afrinic.net.
92.in-addr.arpa. 86400 IN NS pri.authdns.ripe.net.
92.in-addr.arpa. 86400 IN NS ns3.lacnic.net.
92.in-addr.arpa. 86400 IN NS ns4.apnic.net.
92.in-addr.arpa. 86400 IN NS rirns.arin.net.
;; Received 245 bytes from 200.10.60.53#53(d.in-addr-servers.arpa) in 199 ms
244.240.92.in-addr.arpa. 172800 IN NS ns1.lightstorm.sk.
244.240.92.in-addr.arpa. 172800 IN NS ns2.lightstorm.sk.
;; Received 133 bytes from 199.253.249.53#53(rirns.arin.net) in 142 ms
;; expected opt record in response
202.244.240.92.in-addr.arpa. 3600 IN CNAME 202.128/25.244.240.92.in-addr.arpa.
128/25.244.240.92.in-addr.arpa. 3600 IN NS ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 3600 IN NS ns2.mojhosting.sk.
;; Received 119 bytes from 92.240.232.242#53(ns2.lightstorm.sk) in 173 ms
But the last answer has a problem, the flag "AA" (Authoritative Answer) is missing from it. This final nameserver (ns1.lightstorm.sk) is giving some data (the CNAME record) but does not say it is authoritative on it, where it should.
See this answer without the unneeded details:
$ dig @ns1.lightstorm.sk. 202.244.240.92.in-addr.arpa. PTR
[..]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32312
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;202.244.240.92.in-addr.arpa. IN PTR
;; ANSWER SECTION:
202.244.240.92.in-addr.arpa. 1h IN CNAME 202.128/25.244.240.92.in-addr.arpa.
;; AUTHORITY SECTION:
128/25.244.240.92.in-addr.arpa. 1h IN NS ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 1h IN NS ns2.mojhosting.sk.
Note the "flags" part, it should have an "AA" flag. Also the fact that it has "RA" (Recursion Available) seems to show that this nameserver is both authoritative and recursive which is most of the time a bad idea, both services should be separate.
A recursive nameserver will see that, and refuse to go further, hence the various errors you get.
Owner of ns1.lightstorm.sk. + ns2 needs to fix its configuration, the problem is there and not elsewhere.
If you want to compare, this is a similar setup, but working for IP 162.202.233.81.
Note how DNSViz does not show any error: https://dnsviz.net/d/81.233.202.162.in-addr.arpa/YY1_ag/dnssec/
and also if you redo the last step to compare with above:
$ dig @ns2.swbell.net. 81.233.202.162.in-addr.arpa. PTR
[..]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24342
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;81.233.202.162.in-addr.arpa. IN PTR
;; ANSWER SECTION:
81.233.202.162.in-addr.arpa. 2h IN CNAME 81.80/29.233.202.162.in-addr.arpa.
;; AUTHORITY SECTION:
80/29.233.202.162.in-addr.arpa. 2h IN NS ns2.archaxis.net.
80/29.233.202.162.in-addr.arpa. 2h IN NS ns1.archaxis.net.
Note how the "flags" part is different.
FWIW this kind of setup in the reverse tree is the one designed in RFC 2317 "Classless IN-ADDR.ARPA delegation", using CNAME to be able to subdelegate parts of the tree.