Configurația dvs. DNS „funcționează” cumva, dar nu este complet corectă, prin urmare poate crea probleme în unele cazuri.
Iată de ce.
Dacă întrebați direct, primiți un răspuns:
$ 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.
Deci avem finala PTR înregistrează și ar trebui să fim fericiți.
Cu toate acestea, dacă diagnosticăm toată calea de la . (rădăcină) până când 176.244.240.92.in-addr.arpa. putem vedea o problemă.
DNSViz la https://dnsviz.net/d/202.244.240.92.in-addr.arpa/YYzr-A/dnssec/ îl arată, dacă te uiți la partea Erori:
202.244.240.92.in-addr.arpa/CNAME: Indicatorul de răspuns cu autoritate (AA) nu a fost setat în răspuns. (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)
Puteți vedea același lucru folosind dig +trace 202.244.240.92.in-addr.arpa. PTR +nottlunits +nodnssec care oferă mai jos (decuparea primilor pași la rădăcină și 2 domenii):
[..]
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.
;; S-au primit 245 de octeți de la 200.10.60.53#53(d.in-addr-servers.arpa) în 199 ms
244.240.92.in-addr.arpa. 172800 ÎN NS ns1.lightstorm.sk.
244.240.92.in-addr.arpa. 172800 ÎN NS ns2.lightstorm.sk.
;; S-au primit 133 de octeți de la 199.253.249.53#53(rirns.arin.net) în 142 ms
;; înregistrare opt așteptată ca răspuns
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 ÎN NS ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 3600 ÎN NS ns2.mojhosting.sk.
;; S-au primit 119 octeți de la 92.240.232.242#53(ns2.lightstorm.sk) în 173 ms
Dar ultimul răspuns are o problemă, steagul „AA” (Răspuns Autorizat) lipsește din el. Acest server de nume final (ns1.lightstorm.sk) oferă câteva date (the CNAME înregistrare), dar nu spune că este autoritar pe el, unde ar trebui.
Vedeți acest răspuns fără detaliile inutile:
$ dig @ns1.lightstorm.sk. 202.244.240.92.in-addr.arpa. PTR
[..]
;; Am răspuns:
;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 32312
;; steaguri: qr rd ra; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 2, SUPLIMENTARE: 0
;; SECȚIUNEA DE ÎNTREBĂRI:
;202.244.240.92.in-addr.arpa. ÎN PTR
;; SECȚIUNEA RĂSPUNSURI:
202.244.240.92.in-addr.arpa.1h IN CNAME 202.128/25.244.240.92.in-addr.arpa.
;; SECȚIUNEA AUTORITATE:
128/25.244.240.92.in-addr.arpa. 1h ÎN NS ns1.mojhosting.sk.
128/25.244.240.92.in-addr.arpa. 1h ÎN NS ns2.mojhosting.sk.
Rețineți partea „steaguri”, ar trebui să aibă un steag „AA”.
De asemenea, faptul că are „RA” (Recursion Available) pare să arate că acest server de nume este atât autoritar, cât și recursiv, ceea ce este de cele mai multe ori o idee proastă, ambele servicii ar trebui să fie separate.
Un server de nume recursiv va vedea asta și va refuza să meargă mai departe, de aici diversele erori pe care le primiți.
Proprietar al ns1.lightstorm.sk. + ns2 trebuie să-și repare configurația, problema este acolo și nu în altă parte.
Dacă doriți să comparați, aceasta este o configurație similară, dar funcționează pentru IP 162.202.233.81.
Rețineți că DNSViz nu afișează nicio eroare: https://dnsviz.net/d/81.233.202.162.in-addr.arpa/YY1_ag/dnssec/
și, de asemenea, dacă refaceți ultimul pas pentru a compara cu mai sus:
$ dig @ns2.swbell.net. 81.233.202.162.in-addr.arpa. PTR
[..]
;; Am răspuns:
;; ->>HEADER<<- opcode: QUERY, stare: NOERROR, id: 24342
;; steaguri: qr aa rd; ÎNTREBARE: 1, RĂSPUNS: 1, AUTORITATE: 2, SUPLIMENTARE: 1
;; AVERTISMENT: recursiunea este solicitată, dar nu este disponibilă
;; PSEUDOSECȚIE OPT:
; EDNS: versiunea: 0, steaguri:; udp: 4096
;; SECȚIUNEA DE ÎNTREBĂRI:
;81.233.202.162.in-addr.arpa. ÎN PTR
;; SECȚIUNEA RĂSPUNSURI:
81.233.202.162.in-addr.arpa. 2h IN CNAME 81.80/29.233.202.162.in-addr.arpa.
;; SECȚIUNEA AUTORITATE:
80/29.233.202.162.in-addr.arpa. 2h ÎN NS ns2.archaxis.net.
80/29.233.202.162.in-addr.arpa. 2h IN NS ns1.archaxis.net.
Observați cum este diferită partea „steaguri”.
FWIW acest tip de configurare în arborele invers este cel proiectat în RFC 2317 „Delegare IN-ADDR.ARPA fără clasă”, folosind CNAME pentru a putea subdelega părți ale arborelui.
