沈睡精靈 <iy0160.bbs@bbs.cs.nthu.edu.tw>
wrote in message
news:3eEh4F$5r1@bbs.cs.nthu.edu.tw...
> >
如果您想自己日後修改反解記錄﹐又不想再次勞煩上游﹐那可以請他授權下來給
您。方
> > 法有好幾種﹐其中用 CNAME
的方式是個不錯的主意。這樣﹐您可以將正解和反解
都設
> > 在同一個 RR 記錄檔上。步驟如下﹕
> > 1) 先請上游 (1.2.3.1) 在 zone 3.2.1.in-addr.arpa 的 RR
檔上設定一行﹕
> > 103 IN
CNAME 103.abc.idv.tw.
> > 2) 然後在 1.2.3.103 (或負責貴 domain 的主機)上的 zone
abc.idv.tw 之 RR
檔上
> > 加上﹕
> > 103 IN PTR
www.abc.idv.tw.
> > 103 IN PTR
ftp.abc.idv.tw.
> > 103 IN PTR
pop.abc.idv.tw.
> > 103 IN PTR
smtp.abc.idv.tw.
> > www IN A
1.2.3.103
> > ftp
IN A 1.2.3.103
> > pop IN
A 1.2.3.103
> > smtp IN A
1.2.3.103
> 但是小弟照您的方式去作....還是不行耶
> 像我nslookup 1.2.3.1時就出現error
> 但是nslookup 168.95.192.1卻又可以!
> 還有我在1.2.3.1這台機器中,nslookup 1.2.3.103也會出現error耶!
> 是那裡出問題了?
嗯﹐您的來信也收到了﹐或許請把查詢結果寄來給我看看吧。
另外﹐剛纔重新讀了閣下前一篇回應﹐可能您把 RR
的解釋理會錯了﹕
RR 是 Resource Record 而不是 Reverse Record 哦 ~~
所以﹐按前面例子﹐負責 zone abc.idv.tw 的只有一個記錄檔 (不管您起什麼名字)﹐
然後將上面各行寫在同一個記錄檔就行。
下面讓我們看看 DNS 關於 abc.idv.tw 之主機正解記錄(A)的查詢過程(當沒有
cache
的時候)﹕
1) 從 name.ca (type hint) 中得知 root (.) 的 NS 有哪些。
2) 查 . 其中一台的 NS 尋問 tw 的 NS 有哪些。
3) 向上一個查詢結果得到的其中一台 tw 之 NS 查詢負責 idv.tw
的 NS 有哪些。
4) 向上一個查詢結果得到的其中一台 idv.tw 之 NS 查詢負責
abc.idv.tw 的 NS 有
哪些。
5) 最後向負責 abc.idv.tw 之 NS 查詢該 zone
下面的記錄﹔如果有下游授權的
sub-zone﹐那就再往下找 NS ﹐直到查到最後的 A 記錄。
然後讓我們看看 CNAME 的作用﹐例如﹕
$ORIGIN abc.idv.tw
moon IN A 1.2.3.4
sun IN CNAME
moon.abc.idv.tw.
1) 查詢 sun 的時候得到的是一個 CNAME 記錄。
2) 凡是 CNAME 左邊(LHS)的記錄﹐將轉向查詢其右邊(RHS)的記錄﹐也就是查
sun 會
轉向查 moon。
3) 經查前一個 RHS 記錄得到的是 A 記錄﹐完成查詢。
再來﹐讓我們看看前例子中﹐查詢 1.2.3.103 之反解記錄(PTR)﹕
1) 查詢 arpa.
2) 查詢 in-addr.arpa.
3) 查詢 1.in-addr.arpa.
4) 查詢 2.1.in-addr.arpa.
5) 查詢 3.2.1.in-addr.arpa. 發現有一個 LHS 為 103 的 記錄是 CNAME﹐轉向查
RHS 記錄 103.abc.idv.tw.
6) 然後查詢 tw.
7) 查詢 idv.tw.
8) 查詢 abc.idv.tw. 發現一個 103 的 PTR 記錄﹐查詢完成。
最後﹐讓我們看看 cache 的作用﹕
如果 103.abc.idv.tw. 的 PTR 記錄已經在 cahce 中﹐ DNS
直接回答﹔可以省掉前面
8 個步驟。
如果 abc.idv.tw. 的 NS 記錄已經在 DNS 的 cache 中﹐那麼就直接向
NS 查詢 103
﹔可以省略前面的 7 個步驟。
如果 idv.tw. 的 NS NS 記錄已經在 cache 中﹐可以省略前面 6
個步驟。
如此類推。
如果您搬遷了 DNS 或修改了 RR 記錄﹐那麼其它 DNS 可能要等
cache 的 TTL 超過了
才能查到新記錄﹐或是清空 DNS 的 cache (如重新啟動)。
如果小弟敘述有錯誤﹐請大家不吝指正。謝謝﹗