有一天，我面臨一項任務，即授予我的一位客戶編輯分配給他的 /28 子網路的 PTR 記錄的權限。 我沒有從外部自動編輯 BIND 設定的功能。 因此，我決定採取不同的路線 - 將 /24 子網路的 PTR 區域的一部分委託給客戶端。
看起來──還有什麼比這更簡單的呢？ 我們只需根據需要註冊子網路並將其定向到所需的 NS，就像子網域所做的那樣。 但不是。 事情沒那麼簡單（雖然實際上它通常很原始，但直覺沒有幫助），這就是我寫這篇文章的原因。
任何想要自己弄清楚的人都可以閱讀
誰想要現成的解決方案，歡迎來到 cat。
為了不耽誤那些喜歡複製貼上方法的人，我將先發布實務部分，然後再發布理論部分。
1.練習。 授權區/28
假設我們有一個子網 7.8.9.0/24。 我們需要委託子網 7.8.9.240/28 到 DNS 用戶端 7.8.7.8 (ns1.客戶端.網域).
在提供者的 DNS 上，您需要找到一個描述該子網路反向區域的檔案。 隨它去 9.8.7.in-addr.harp.
我們對 240 到 255 之間的條目（如果有）進行評論。 在文件的末尾我們寫入以下內容：
255-240 IN NS 7.8.7.8
$GENERATE 240-255 $ CNAME $.255-240不要忘記增加串行區域並執行
rndc reload這樣就完成了提供者部分。 讓我們繼續討論客戶端 dns。
首先，我們建立一個文件 /etc/bind/master/255-240.9.8.7.in-addr.arpa 以下內容：
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
@ IN NS ns1.client.domain.
@ IN NS ns2.client.domain.
241 IN PTR test.client.domain.
242 IN PTR test2.client.domain.
245 IN PTR test5.client.domain.
而在 命名.conf 新增文件的描述：
zone "255-240.9.8.7.in-addr.arpa." IN {
type master;
file "master/255-240.9.8.7.in-addr.arpa";
};B 重新啟動綁定程序。
/etc/init.d/named restart全部。 現在你可以檢查一下。
#> host 7.8.9.245
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.請注意，不僅給出了 PTR 記錄，還給出了 CNAME。 事情應該是這樣的。 如果您想知道為什麼，那麼歡迎閱讀下一章。
2.理論。 怎麼運作的。
配置和調試黑盒子很困難。 如果您了解內部發生的情況，那就容易多了。
當我們在域中委託子域時 域，然後我們寫下這樣的東西：
client.domain. NS ns1.client.domain.
ns1.client.domain. A 7.8.7.8我們告訴每個詢問的人我們不對這個網站負責，並說明誰負責。 以及所有請求 客戶域 重定向到 7.8.7.8。 檢查時，我們看到如下圖（客戶端有的就省略了，沒關係）：
# host test.client.domain
test.client.domain has address 7.8.9.241那些。 我們得知有一張A記錄，其ip為7.8.9.241。 沒有不必要的資訊。
如何使用子網路完成相同的事情？
因為我們的 DNS 伺服器在 RIPE 中註冊，那麼當從我們的網路請求 PTR IP 位址時，第一個請求仍然是我們。 邏輯與域相同。 但是如何將子網路輸入到區域檔案呢？
讓我們試試這樣輸入：
255-240 IN NS 7.8.7.8而且……奇蹟並沒有發生。 我們沒有收到任何重定向請求。 問題是，bind 甚至不知道反向區域文件中的這些條目是 IP 位址，更不了解範圍條目。 對他來說，這只是某種象徵性的子域。 那些。 對於綁定來說，「」之間沒有區別255-240“和”我們的超級客戶」。 為了使請求到達需要到達的地方，請求中的位址應該如下所示： 241.255-240.9.8.7.in-addr.arpa。 或者像這樣如果我們使用字元子域： 241.oursuperclient.9.8.7.in-addr.arpa。 這與通常的不同： 241.9.8.7.in-addr.harp.
手動提出這樣的請求會很困難。 即使它有效，目前仍不清楚如何將其應用到現實生活中。 畢竟，根據要求 7.8.9.241 提供者的 DNS 仍然對我們負責，而不是客戶端的。
這就是他們發揮作用的地方 CNAME.
在提供者方面，您需要以將請求轉送至客戶端 DNS 的格式為子網路的所有 IP 位址建立別名。
255-240 IN NS ns1.client.domain.
241 IN CNAME 241.255-240
242 IN CNAME 242.255-240
и т.д.
這是給勤奮的人的=)。
而對於懶人來說，以下的設計更適合：
255-240 IN NS ns1.client.domain.
$GENERATE 240-255 $ CNAME $.255-240現在請求訊息 7.8.9.241 的 241.9.8.7.in-addr.harp 提供者的 DNS 伺服器上的將轉換為 241.255-240.9.8.7.in-addr.arpa 並轉到 dns 客戶端。
客戶端需要處理此類請求。 因此，我們創建一個區域 255-240.9.8.7.in-addr.arpa。 原則上，我們可以在其中放置整個 /24 子網路的任何 ip 的反向條目，但他們只會詢問提供者轉發給我們的條目，因此我們無法玩弄 =)。
為了說明這一點，我將再次舉出一個客戶端反向區域文件內容的範例：
$ORIGIN 255-240.9.8.7.in-addr.arpa.
$TTL 1W
@ 1D IN SOA ns1.client.domain. root.client.domain. (
2008152607 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum
@ IN NS ns1.client.domain.
@ IN NS ns2.client.domain.
241 IN PTR test.client.domain.
242 IN PTR test2.client.domain.
245 IN PTR test5.client.domain.
這是因為我們在提供者方面使用 CNAME，並且在回應透過 IP 位址取得資料的請求時，我們收到兩筆記錄，而不是一筆。
#> host 7.8.9.245
245.9.8.7.in-addr.arpa is an alias for 245.255-240.9.8.7.in-addr.arpa.
245.255-240.9.8.7.in-addr.arpa domain name pointer test5.client.domain.
並且不要忘記正確設定 ACL。 因為為自己佔據 PTR 區域而不回應外部的任何人是沒有意義的 =)。
來源： www.habr.com