Ваша конфигурация DNS как-то «работает», но она не совсем верна, поэтому в некоторых случаях может создавать проблемы.
Вот почему.
Если вы запросите напрямую, вы получите ответ:
$ dig -x 92.240.244.176 +noall +ans +nottlunits
176.244.240.92.in-addr.arpa. 3590 В CNAME 176.128/25.244.240.92.in-addr.arpa.
176.128/25.244.240.92.in-addr.arpa. 43191 В PTR bill3.hostio.sk.
Итак, мы получили финал PTR запись и мы должны быть счастливы.
Однако, если мы продиагностируем весь путь от . (корень) до 176.244.240.92.in-addr.arpa. мы видим проблему.
DNSViz в https://dnsviz.net/d/202.244.240.92.in-addr.arpa/YYzr-A/dnssec/ показывает это, если вы посмотрите на часть ошибок:
202.244.240.92.in-addr.arpa/CNAME: в ответе не установлен флаг авторитетного ответа (AA). (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)
Вы можете увидеть то же самое, используя копать +трассировка 202.244.240.92.in-addr.arpa. PTR +nottluits +nodnssec что дает ниже (обрезка первых шагов в корне и 2 домена):
[..]
92.in-addr.arpa. 86400 В NS ns3.afrinic.net.
92.in-addr.arpa. 86400 В NS pri.authdns.ripe.net.
92.in-addr.arpa. 86400 IN NS ns3.lacnic.net.
92.in-addr.arpa. 86400 В NS ns4.apnic.net.
92.in-addr.arpa. 86400 В НС rirns.arin.net.
;; Получено 245 байт от 200.10.60.53#53(d.in-addr-servers.arpa) за 199 мс.
244.240.92.in-addr.arpa. 172800 В NS ns1.lightstorm.sk.
244.240.92.in-addr.arpa. 172800 В НС ns2.lightstorm.sk.
;; Получено 133 байта от 199.253.249.53#53(rirns.arin.net) за 142 мс
;; ожидаемая запись opt в ответ
202.244.240.92.in-addr.arpa. 3600 В CNAME 202.128/25.244.240.92.in-addr.arpa.
128/25.244.240.92.in-addr.arpa. 3600 В НС ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 3600 В НС ns2.mojhosting.sk.
;; Получено 119 байт от 92.240.232.242#53(ns2.lightstorm.sk) за 173 мс
Но у последнего ответа есть проблема, в нем отсутствует флаг «АА» (авторитетный ответ). Этот окончательный сервер имен (ns1.lightstorm.sk) дает некоторые данные ( CNAME запись), но не говорит, что он авторитетен там, где должен.
См. этот ответ без ненужных деталей:
$ dig @ns1.lightstorm.sk. 202.244.240.92.in-addr.arpa. PTR
[..]
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 32312
;; флаги: qr rd ra; ЗАПРОС: 1, ОТВЕТ: 1, АВТОРИЗАЦИЯ: 2, ДОПОЛНИТЕЛЬНО: 0
;; РАЗДЕЛ ВОПРОСОВ:
;202.244.240.92.in-addr.arpa. В ПТР
;; РАЗДЕЛ ОТВЕТОВ:
202.244.240.92.in-addr.arpa.1h IN CNAME 202.128/25.244.240.92.in-addr.arpa.
;; ОТДЕЛ ПОЛНОМОЧИЙ:
128/25.244.240.92.in-addr.arpa. 1ч В НС ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 1ч В NS ns2.mojhosting.sk.
Обратите внимание на часть «flags», она должна иметь флаг «AA».
Также тот факт, что у него есть «RA» (доступная рекурсия), кажется, показывает, что этот сервер имен является как авторитетным, так и рекурсивным, что в большинстве случаев является плохой идеей, обе службы должны быть отдельными.
Рекурсивный сервер имен увидит это и откажется идти дальше, отсюда и различные ошибки, которые вы получаете.
Владелец ns1.lightstorm.sk. + нс2 нужно исправить его конфигурацию, проблема именно в нем, а не где-то еще.
Если вы хотите сравнить, это аналогичная установка, но работающая для IP. 162.202.233.81.
Обратите внимание, что DNSViz не показывает никаких ошибок: https://dnsviz.net/d/81.233.202.162.in-addr.arpa/YY1_ag/dnssec/
а также если вы повторите последний шаг, чтобы сравнить с выше:
$ копать @ns2.swbell.net. 81.233.202.162.in-addr.arpa. PTR
[..]
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 24342
;; флаги: qr aa rd; ЗАПРОС: 1, ОТВЕТ: 1, ВЛАСТЬ: 2, ДОПОЛНИТЕЛЬНО: 1
;; ВНИМАНИЕ: рекурсия запрошена, но недоступна
;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; UDP: 4096
;; РАЗДЕЛ ВОПРОСОВ:
;81.233.202.162.in-addr.arpa. В ПТР
;; РАЗДЕЛ ОТВЕТОВ:
81.233.202.162.in-addr.arpa. 2h IN CNAME 81.80/29.233.202.162.in-addr.arpa.
;; ОТДЕЛ ПОЛНОМОЧИЙ:
80/29.233.202.162.in-addr.arpa. 2 часа В NS ns2.archaxis.net.
80/29.233.202.162.in-addr.arpa. 2 часа В NS ns1.archaxis.net.
Обратите внимание, что часть «флаги» отличается.
FWIW, этот тип настройки в обратном дереве разработан в RFC 2317 «Бесклассовое делегирование IN-ADDR.ARPA» с использованием CNAME чтобы иметь возможность делегировать части дерева.
