網路Zytrax.com，我在那裡了解到無類別反向映射委託，表示dig -x <ip address>如果使用這種委託方法（使用 CNAMES），則不應在此情況下工作。
例如：
這不應該工作：
dig -x 192.168.23.66
這應該有效：
dig 66.64/27.168.192.IN-ADDR.ARPA
當我稍微修改它時它確實可以工作（指定它被委託到的伺服器以及我想要 PTR 記錄的伺服器）：
dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA
它似乎按照教程中的描述工作：
我設定了類似的委派，其行為如上所述：當我使用dig -x委派範圍中的 IP 位址時，委派名稱伺服器告訴我誰對66.64/27.168.192.IN-ADDR.ARPA.無類別網路委派到的伺服器擁有權限，僅適用於第三個命令 ( dig @<name of ns where it was delegted to> PTR 66.64/27.168.192.IN-ADDR.ARPA) 。
可以並且安全嗎？
由於它不適用於 dig -x （或 nslookup），我想知道是否還有更多的東西不起作用。解析器能否順利解析此類 IP 位址？例如，如果使用這種委派方法，電子郵件伺服器可以毫無問題地執行反向查找嗎？有什麼理由不使用它？
我的例子（稍作修改）：
dig @ns1.example.com -x 192.168.134.1
;; ANSWER SECTION:
1.134.168.192.in-addr.arpa. 60 IN CNAME 1.0-127.134.168.192.in-addr.arpa.
;; AUTHORITY SECTION:
0-127.192.113.134.in-addr.arpa. 10 IN NS ns2.example.com.
dig @ns2.example.com PTR 1.0-127.192.168.134.in-addr.arpa.
;; ANSWER SECTION:
1.0-127.192.168.192.in-addr.arpa. 10 IN PTR 1st_super.example.com.
為什麼它不起作用
我委託的區域名稱是錯誤的，並且在第二個查詢中使用了錯誤的名稱，我得到了答案（這兩個錯誤部分地相互抵消了）。
錯誤（不顛倒）：
0-127.192.168.134.in-addr.arpa.
本來應該：
0-127.134.168.192.in-addr.arpa.
修復了此錯誤並且委託伺服器成為委託區域的從屬伺服器後，就可以dig -x <ipaddress>正常工作了。
答案1
長話短說
如果您建立一個RFC2317-styleless in-addr.arpa 委託，無法直接透過 IP 位址的反向映射查詢子委託的權威名稱伺服器，這是完全正常的。
真正重要的是解析器伺服器可以查找反向名稱（例如dig -x 192.0.2.1 @8.8.8.8，對於與您的環境/用例相關的任何 IP 位址和解析器伺服器組合）。
RFC2317解釋
RFC2317 提供一種解決方法的總體問題是，從 IPv4 位址到 DNS 中的反向名稱（例如192.0.2.1-> 1.2.0.192.in-addr.arpa）的基於約定的映射如何早於無類別委派，並有效地將可能的委派點鎖定到/0, /8, 16, /24, /32。 （您只能在每個標籤上進行委託，並且映射被定義為簡單地使 IPv4 位址的每個八位元組成為一個標籤，以相反的順序。）
必須以不同的方式定義映射，映射到一些更細粒度的命名方案實際上允許諸如/27委託之類的事情。
RFC2317 並沒有改變根本情況，它實際上並沒有以任何方式改變協定。
它所做的只是提出一種方案，人類操作員可以使用它來解決無類別委託不可能的限制。
該方案可以概括為：
- 您可以
CNAME為實際反向區域中的某些名稱集定義別名（新增記錄）（根據命名約定），將這些名稱對應到新的命名空間
（新的命名空間確實可以有任何名稱，但 RFC2317 建議使用描述性名稱並將新命名空間作為現有區域的子層級（位於in-addr.arpa） - 您委託與此對應的區域新的命名空間有必要的
結果是，要求查找的解析器伺服器1.2.0.192.in-addr.arpa只會正常執行該操作並遇到該CNAME記錄，而不是PTR它真正要查找的記錄。
然後，它只需跟隨CNAME進入新的命名空間，而無需了解 RFC2317 的任何知識，甚至不需要任何現有的 RFC2317 知識，並且如果按照 RFC2317 的建議進行設置，它將找到PTR可以在該新名稱中使用的a 。
例如，如果您有一個包含以下內容的2.0.192.in-addr.arpa.區域：ns1.other.example.
1.2.0.192.in-addr.arpa. IN CNAME 1.0/27.2.0.192.in-addr.arpa.
0/27.2.0.192.in-addr.arpa. IN NS ns7.example.com.
實際反向名稱 ( ) 的查找過程1.2.0.192.in-addr.arpa.將產生CNAME，並且解析器將CNAME正常處理，無論它指向何處，都跟隨它。
在此範例中，它導致1.0/27.2.0.192.in-addr.arpa.，並且該區域也有一個委派0/27.2.0.192.in-addr.arpa.到ns7.example.com.，因此解析器可以繼續查找過程新名字一切都會成功的。
另一方面，如果您向它發送查詢，1.2.0.192.in-addr.arpa.它將ns7.example.com.對此一無所知。
ns7.example.com. 才不是具有該位址的反向區域，它只有一個鬆散相關的區域，實際反向區域由這些別名引用。
若要檢查 RFC2317 樣式的委託是否有效，首先，您可以檢查實際解析器是否成功尋找名稱。
但是，深入研究細節，您將檢查真正反向區域的名稱伺服器回應的內容（CNAME在本例中應該是 a ），檢查規範名稱（CNAME「目標」）被委託的位置，然後檢查該名稱伺服器是否回應正如CNAME記錄所指定的規範名稱。