分类：
2006-10-02 12:32:46
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
前面所介紹的伺服器服務大多是用在內部網路環境中的﹐不過﹐以現代的情況和未來的趨勢來看﹐每個網路或多或少都需要 Internet 連線以及向 Internet 提供服務。從這一章開始﹐我們將為大家陸續介紹一些在 Internet 環境中常用到的伺服器之架設技巧。就算您目前還沒真的需要架設 Internet 相關的伺服器﹐但許多企業的 Intranet 環境中﹐也需要相類似的伺服器來為企業內部網路提供服務。
在眾多 Internet 伺服器當中﹐有一種服務是所有服務的基礎﹐就是 DNS 服務。DNS 可以說是一個不容易弄清楚的概念﹐尤其是其運作原理。如果您看過“”中的“”(我強烈建議您看看這篇文章﹗)﹐相信應該有一定概念了﹐否則﹐您在如下的閱讀中可能難以理解﹐也浪費您的時間。 無論如何﹐在您進一步閱讀下面文章之前﹐請您先確定能正確回答如下的問題﹕
如果您未能從上面的聯結網頁找到答案﹐那我再推薦您多看一篇文章﹕
忠告﹕請不必急著知道怎樣設定 DNS﹐花點時間將 DNS 的原理弄明白非常重要﹐尤其是授權模式和查詢模式的正確理解。在日後的 DNS 架設和管理中﹐是否能正確理解這些 DNS 原理﹐往往是成敗的關鍵所在﹗ 如果您在 NT 或 Win2K 下面設定過 DNS 伺服器﹐相信您會覺得在 Linux 下面難多了。除了概念上要比較清楚外﹐另外對檔案的關聯也要有清晰的追蹤能力﹐這對於進行 debug 尤為重要。因為在 Windows 系統上面﹐您的所有設定都透過圖形界面進行﹐方便是方便﹐但也因為這個圖形界面﹐限制了您的設定靈活性﹐同時也阻隔了您對 DNS 系統的深入了解。當您完成了這章的學習﹐而且成功在 Linux 架設出複雜的 DNS 環境之後﹐歡迎您再回到 Win2K 上嘗試做同樣的事情。或許﹐您就會認同我這裡的觀點了... 好了﹐閒話休提﹑言歸正傳﹐聽百遍不如做一遍﹐那就讓我們開始動手吧﹗ ^_^
在 Linux 上面﹐提供 DNS 服務的套件是叫 bind﹐ 但執行服務程式名稱則是 named 。請您確定系統上裝有 bind﹑bind-utils﹑以及 caching-nameserver 這幾個套件﹐同時用 ntsysv 確定 named 被選擇為開機服務。 首先﹐讓我們設定一個最重要的 dns 設定檔﹐它就是 /etc/named.conf 。我將我自己的設定檔案列出來﹐然後逐部份進行解釋﹕
先讓我們了解這個檔案上面用來做註解的符號是“ // ”﹐而不是一般 shell script 的“#”﹔另外﹐“ /* ”與“ */ ”之間則註解一整段文字。同時﹐每一個完整的設定都以“ ﹔”結尾﹐請不要少了它﹗(初學者經常會犯這個錯誤) 上面的部份是在這個檔案開頭的 options 設定﹐首先用 directory 指定了 named 的資源記錄( RR - Resource Record )檔案目錄所在位置為﹕“/var/named”﹔也就是說﹐它會到這個目錄下面尋找 DNS 記錄檔案。所以﹐我們在這個檔案後面部份所指定的檔案﹐就無需使用絕對路徑了﹐但它們一定要放在這個目錄下面。 接下來﹐有一段文字﹐如果您仔細閱讀一下﹐它大致是說﹕如果您要設定的 DNS 伺服器和 client 之間是隔著火牆的話﹐要將“// query-source address * port 53;”前面的註解符號“ // ”拿掉(當然﹐您也必須要設定好您的火牆啦)。不過﹐這只對早期的版本有影響﹐而在 bind 8.1 之後則無需擔心這個設定。 接下來再讓我們看下一段句子﹕
透過這幾行﹐我們為 named 定義了 DNS 系統中的根區域“ . ”(root zone) 的設定﹐同時它是一個 internet ( IN ) 的區域類別( class )。這裡還指定了root zone 的伺服器種類( type ) 為“hint”(也只有這個 zone 會使用這樣的種類)。最後﹐用 file 指定這個區域記錄檔為﹕“named.ca”﹐也就是“/var/named/named.ca”檔案。雖然 named.ca 這個檔案中的‘ca’是 cache 的意思﹔但如果您了解 DNS 的運作﹐就應該知道這個暫存檔的作用﹐同時﹐為什麼我們會把 root zone 放在這裡。(嗯﹖想想看﹖尤其是查詢非本機區域的時候﹖) 在 root zone 後面﹐您應該還會看到如下這兩段﹕
這裡是定義出關於本機名稱的 DNS 解釋﹕第一個 zone 是 localhost 的正解 zone﹐其伺服器種類是 master﹐記錄檔名稱是 localhost.zone (在 /var/named 目錄下面)﹐但這個 zone 不允許客戶主機(或伺服器)自行更新 DNS 的記錄(當然﹐client 主機必須能支援 DNS submit 功能才行)。 而第二個 zone 則是本機區域的反解 zone ﹐不過﹐這部份的解釋我想留到後面的真實例子中再作說明﹐請您留意就是了。 上面的句子﹐當您安裝好 caching-nameserver 套件之後就被建立起來的﹐相信您不用勞什麼心力。在檔案最後﹐您或許還看到下面這段設定﹕
這是 bind 9.x 版本的新功能﹐用來進行區域轉移或 DNS 更新所用的加密處理。這個我們暫時不必理會﹐除非您有興趣進行這個研究。 現在﹐我們暫時不要修改 named.conf 設定檔﹐請退出它﹐然後轉到 /var/named 目錄﹐看看裡面有些什麼東東﹖最起碼﹐您會看到如下三個檔案﹕
localhost.zone named.local 不知道您是否有靈感了﹖沒錯﹕剛纔在 named.conf 裡面﹐每一個 zone 所指定的 file 都出現在這裡﹗先讓我們看看 root zone 的檔案內容吧﹕
在 /var/named 中的 RR 記錄檔裡面的註解符號﹐和 /etc/named.conf 的註解符號不一樣哦﹕在 named.conf 中是用雙斜線“ // ”﹔而在這裡則使用 “ ﹔”符號。無論如何﹐您都不能用 “ # ”來做註解符號就是了。(好混亂哦~~~ 這就是電腦﹗^_^ ) 在上面這個 named.ca 檔案裡面﹐您如果將所有的註解行拿掉﹐您會發現一共有 13 行是以‘ . ’開頭的﹐那就是所謂的 root zone 了﹗然後﹐第二欄都是‘ 3600000 ’﹐這是 TTL (Time To Live) 設定﹐也就是在 cache 中保留的時間﹐以秒為單位(所以這裡是 100 小時)。其後的‘ NS ’是“Name Server”的意思﹐是 DNS 記錄名稱之一﹐也就是負責這個記錄的 name server 是哪一台主機(這裡一共由 13 台主機共同負責 root zone 的 NS 服務)。 雖然我們這裡用 NS 指定了 name server 的主機名稱﹐但對電腦系統來說﹐這些名稱必須能解釋為 IP 位址才有用(呵~~ 這個正是 DNS 系統的功能)﹐所以﹐這裡分別用 13 個‘ A ’記錄﹐也就是 Address 的意思﹐解釋 [A-M].ROOT-SERVER.NET. 這些主機各自的 IP 位址所在。 如果您了解 DNS 的查詢模式﹐您會知道 DNS 伺服器在查詢非自己管轄的 zone 的時候﹐首先會向 root 查詢下一級的 zone 在哪裡﹐然後逐級查詢下去。但問題是﹕當 named 剛啟動的時候﹐在 cache 裡面一片空白﹐它怎麼知道 root zone 的 servers 在哪裡呢﹖這不是一個矛盾嗎﹖所以﹐就必須靠這個檔案告訴 named 關於 root zone 的 servers 有哪些﹖以及在哪裡﹖ --- 明白了嗎﹖ 因為這個檔是以靜態的方式維護的﹐很難保證這個檔的內容永遠都正確﹐如果 root zone 的記錄發生改變了怎麼辦(雖然這機會不大)﹖或許﹐您已經在檔案的開頭註解那裡得知﹐您可以在任何時候透過 ftp 或 gopher 取得這個檔案的最新版本。如果您還沒讀過那些註解﹐那就請帶著字典讀一下吧。如果您真的有需要更新這個 named.ca 檔﹐那可以按如下步驟進行﹕
除了剛才的 named.ca 之外﹐第二個 zone 的記錄檔是 localhost.zone ﹐從 named.conf 中您應該知道它是 zone "localhost" 的記錄檔﹐它的內容如下﹕
內容很簡單﹐但您是否真的了解每一行的設定意思呢﹖如果不清楚或不確定﹐那就讓我們一起探討探討吧。 首先﹐第一行是一個 TTL 設定﹐目前是定義出這個記錄檔裡面的各項記錄的預設 TTL 值為 86400 秒(剛好是一天)。您的記錄檔或許沒有這行﹐事實上沒什麼關係﹐您可以自己補上﹐否則﹐在啟動 named 的時候會碰到一些警告﹐無傷大雅的﹔但如果您的確在意那些警告﹐那就加上這行。您要知道﹐在記錄檔中宣告的所有資源記錄(RR - Resource Record)﹐都一定有一個 TTL 設定﹐如果沒有﹐則使用這裡預設的值。 第二行是一個 ORIGIN 設定﹐說明下面的記錄源出何處(這裡是源出 localhost. 的記錄)。請您加倍留意最後的一個小數點“ .”﹐少了它或多了它﹐記錄名稱完全不一樣﹗在 DNS 記錄中﹐我們稱這樣以小數點結尾的名稱為“ 全域名稱 ”即 FQDN ( Fully Qualified Domain Name ) 。如果缺少了這個點會怎樣呢﹖就會將所屬的 ORIGIN ( @ ) 附加在記錄名稱後面﹔而這 ORIGIN 就是上一個 $ORIGIN 宣告之後的名稱﹐如果在前面找不到 $ORIGIN 宣告﹐那就以 /etc/named.conf 中定義的 zone 名稱為基準。以目前的例子來說﹐如果沒有這個小數點的話﹐“localhost”會變成“localhost.localhost”﹔但如果有小數點的話“localhost.”就只能是“localhost.”。所以﹐這個小點“.”非常重要﹐在以後設定中一定要非常留神﹗﹗(這也初學者最常犯的錯誤之一) 然後﹐第三行﹐是一個 SOA 記錄的設定﹐在這裡我們看到一個特殊字符“ @ ”﹐它就是 ORIGIN 的意思﹐也就是剛纔所定義的 $ORIGIN localhost. 內容﹐您可以寫成 localhost. 也可以用 @ 來代替。假如這個檔前面沒有定義 $ORIGIN 的話﹐那這個 @ 的值就以 named.conf 裡的 zone 為準。既然這樣﹐當然是使用“@”啦﹐尤其對於像我這樣的懶惰鬼來說﹐巴不得少打一串字﹐同時還能避免因打字不準所造成的失誤﹐何樂不為﹖ 在 @ 之後﹐是 TTL 的設定﹐這裡是 1D﹐也就是一天的意思﹐如果您喜歡﹐可以用 86400 (秒) 來設定﹐如果這裡的 TTL 沒有設定﹐則參考前面的 $TTL 值﹐如果前面沒有定義 $TTL﹐那就參考其後介紹的 minium ttl 設定。
在 TTL 之後是一個 IN﹐定義出目前的記錄類型是屬於 internet class 的 (奇怪﹐目前的 DNS 還有其它 class 嗎﹖)。 在 IN 之後就是這行 RR 的記錄類別名稱﹐這裡是 SOA ﹐也就是“Start Of Authority”的意思﹐表示目前區域的授權記錄開始。每一個記錄檔只能有一個 SOA ﹐不得重複﹐而且必須是所負責的 zone 中第一個“記錄”。 緊接 SOA 後面﹐指定了這個區域的授權主機和管理者的信箱﹐這裡分別是“ @ ”和“ root ”﹐也就是 localhost. 主機和 root 信箱。這裡要注意的是﹕SOA 的主機名稱必須能夠在 DNS 系統中找到一個 A 記錄 (以後會提到)﹔另外﹐我們平時使用的信箱通常是“user@host”這樣的格式﹐但因為“@”在 DNS 記錄中是個保留字符(剛才已經提過)﹐所以在 SOA 中就用“.”來代替了“ @ ”。目前這個信箱是 root (並沒有主機位址)﹐也就是本機﹐您可以寫成 “root.localhost.”但不能寫成“root@localhost.”。 接下來的 SOA 設定﹐是被括在“( )”之間的 5 組數字﹐主要作為和 slave 伺服器同步 DNS 資料所使用的數據﹕
以上的數字都是以秒為單位﹐但您也可以用 H(小時)﹑D(天)﹑W(星期)來做單位﹐如﹕3H 和 259200 是一樣的。但要值得一提的是﹕我在 RH6.2 版本中曾測試過使用 netconf 這工具來設定 DNS ﹐發現只能使用“秒”來設定。否則 netconf 會自動的把英文字母刪除掉﹐那就不是我所預期的設定值了。無論您用什麼單位來設定﹐都要遵守下面的規則﹕ expire >= 10 * retry
設定 DNS 的 RR 記錄檔﹐其格式要求非常嚴格﹐我們絲毫不能掉以輕心。比方說﹕如果句子不是以空白鍵﹑Tab 鍵﹑ 或註解符號 ( ; )開頭﹐也不在 SOA 的 “ ( ) ”之內﹐ 則表示要定義一個“新記錄項 (Entry) ”﹔如果句子是以空白鍵或 tab 鍵開始的話﹐其設定被視為上一個“記錄項”的內容。所以﹐如果您要為“同一個記錄項”定義多個記錄設定﹐而不想重複打字﹐您倒可以偷懶﹕在接著它的後面幾行用空白或 Tab 來縮排就可以了。所以﹐最後這兩行還是關於 localhost. 的設定﹐因為上一個“資料項”為 “ @ ”﹐也就是 localhost. 。當然﹐您如不喜歡﹐這兩行句子也可以這樣寫﹕
這兩行的意思是說﹕負責 localhost. 這個記錄的 name server ( NS ) 是 localhost. 這台機器﹔而 localhost. 的 IP Address ( A ) 是 127.0.0.1 。DNS 裡面的 A 記錄應該是最常見的記錄類型之一﹐如果在 IPv6 版本中﹐位址記錄名稱則改為 AAAA 。
最後﹐讓我們檢查剩下的 named.local 檔案吧。如果您還沒忘記 /etc/named.conf 的內容的話﹐應知道這個檔案是 zone "0.0.127.in-addr.arpa" 的‘反解’記錄檔﹐它的內容也很簡單﹕
前面的部份應該不用多解釋了(如果您還不清楚﹐那就必須重讀前面的文章)。最後一行我們看到一個“ PTR ”記錄﹐它是“Pointer”的意思。 PTR 通常用於反記錄當中﹐將 IP 指向主機名稱(剛好和 A 記錄相反)。您或許還不是很清楚這個句子為什麼是這樣設定的吧﹖或許您會這樣問﹕您不是說 PTR 是從 IP 反查詢主機名稱的嗎﹖為什麼這裡是 1 而不是 127.0.0.1 ? 哦﹐如果您有這樣的問題﹐那證明您對 DNS 的查詢模式還不是了解得很透徹﹐不過也不用緊張﹐在後面的實作例子中﹐您將獲得更進一步的感性認識。這裡﹐我暫時簡單解釋上面這行就是了﹕ 我們知道 127.0.0.1 所對應的主機名稱就是 localhost ﹐因為這裡是反向查詢﹐所以 IP 順序是掉過來寫的﹐於是這個反查詢 IP 就是﹕“ 1.0.0.127.in-addr.arpa. ”﹐由於我們這裡的 ORIGIN ( @ ) 是“ 0.0.127.in-addr.arpa." ”﹐因為在記錄檔中﹐如果名稱不帶小數點﹐則被補上 $ORIGIN 或 zone 的名稱﹐所以這個 “ 1 ”就成了 1.0.0.127.in-addr.arpa. ”。同樣道理﹐後面的“ localhost. ”如果漏了最後的小點的話﹐則會成為“ localhost.0.0.127.in-addr.arpa. ”﹐這顯然是不對的。假如您喜歡﹐可以將這行句子修改成為下面的樣子﹕
嗯~~ DNS 的設定看起來真的蠻傷腦筋的﹐或許您到這裡已經被搞得亂七八糟了。假如真的如此﹐我建議您先休息一下﹐然後回來重讀上面的內容﹐直到您能理解之後﹐才繼續下面的。否則﹐越往後﹐您的問題越像滾雪球那樣越來越大﹐這更浪費時間啦~~~ Okay? Take it easy ... ^_^ 前面所看到的設定﹐事實上已經足夠讓您的 DNS 主機跑起來了﹗因為它能夠透過 root 查詢其他 DNS 的緣故﹐您無須在再加設任何設定﹐您就可以利用這台主機為大家提供 Internet 的 DNS 查詢服務。只是﹐這樣的 DNS 主機﹐我們稱之為 cache only name server 而已。如果您了解 DNS 的查詢流程﹐您應該知道 DNS 的 cache 作用和它的效益。所以﹐就算您不打算設定自己的 domain name 服務 ﹐我也建議您至少可以將 cache only NS 跑起來。
當您對 /etc/named.conf 檔案和 /var/named 目錄的設定有初步了解之後﹐下面﹐讓我們用一個實際例子來看看如何設定自己的 domain name 服務吧。我個人的習慣是先將網域和主機的資料整理出來﹐並列成一個表格﹕
當所有的主機名稱和 IP 整理出來之後﹐再看看我們這裡需要設定哪些 domain ﹖ 從上面的資料中﹐我們不難發現有兩個正解 zone 和兩個反解 zone 需要設定﹐分別是﹕
因為這些 IP 和 domain 都在內部網路使用﹐所以我們省卻了註冊這關﹐同時也不必擔心授權的問題。但這些資訊也只能在內部網路使用﹐無論如何是不能設定在對外的 DNS 上面的 (為什麼﹖除了安全的考量之外﹐private IP 的使用本來就有這樣的規定﹐就算您真的對外散佈這些 DNS 資訊﹐在 IP 的路由上還是有問題﹐所以﹐內部的資訊﹐只能內部使用)。 一般來說﹐我會先設定“反查詢區域(revers zone)”﹐當然﹐這是個人習慣而已。所以﹐我首先在 /etc/named.conf 上面補上兩個反解 zone 的設定﹕
注意哦﹕如果您要設定外部 DNS 的反解﹐那就先獲得 ISP 的授權才能自己設定﹔否則反解部份就不用自己擔心了﹐但一定要請 ISP 幫忙。
其它 ISP 的用戶﹐請自行接洽 ISP 的客服部門。無論如何﹐如果沒有取得授權﹐那就不要自己設﹗ 這裡﹐我們再一次碰到反解區域的識別標誌﹕“ .in-addr.arpa ”﹐同時﹐我們解釋一下上次關於本機反解還沒說明的地方﹕如果您了解 DNS 的授權和查詢過程(這章一開始的時候﹐我就已要求您一定要學習的)﹐您會知道反解查詢是先從 root 開始(正解也是一樣)﹐然後到 arpa ﹑到 in-addr ﹑到第一組 IP ﹑到第二組 IP ﹑...... 這樣查詢下來的。所以﹐在設定反區域的時候﹐您一定要將您的 net ID 部份反過來寫﹐例如﹕我的網路為 192.168.100.0/24﹐它的反查詢區域名則是﹕“100.168.192.in-addr.arpa”﹔假如我將 netmask 改為 16 bit ﹐即變成 192.168.0.0/16﹐它的反解區域名就會變成﹕“168.192.in-addr.arpa”。如果您還搞不懂如何區分 Net ID 和 Host ID﹐請立即去看一看“”中的“”。 同時﹐我將這些 zone 都設定為“主 DNS 伺服器”(即﹕master﹐也有人稱之為 primary dns )。 在每個 zone 的最後部份﹐我分別指定了它們各自的記錄檔名稱。它們都存放在 /var/named 這個目錄下面(也就是前面 options 指定的 directory 啦)。檔案的名稱隨您喜歡﹐不致做成混亂則可。 完成上面的設定之後﹐我們就可以到 /var/named 目錄去建立相應的記錄檔案了。說實在﹐在 named.conf 裡面如何定義檔案名稱沒一定的標準﹐只要您能正確指定哪個記錄檔給哪個 zone 使用﹐而且檔案名稱能夠一致就行。首先﹐根據第一個 zone 的 file 設定﹐我要建立一個 /var/named/192.168.100.rev 檔案﹐其內容如下﹕
而另外一個反解設定檔是 /var/named/10.0.1.rev ﹐我們依樣畫葫蘆就行了﹕
就這樣﹐反解 DNS 就設定完成了﹗是否很簡單呢﹖如果您回答“ Yes ”的話﹐那就讓我們繼續正解區域的設定吧。同樣的﹐先在 /etc/named.conf 裡面加上兩個 zone﹕
完成後﹐再建立 /var/named/siyongc.domain 這個檔案﹕
這裡﹐我們在正解記錄檔裡面看到幾個新的記錄類別﹐或許需要進一步講解一下的﹕ 因為我這個區域的記錄分別由兩台主機負責﹐所以我這裡指定了兩個 NS 記錄。這裡﹐如果您確定上一個 ORIGIN 是正確的話﹐那也可以偷懶﹕正如我上面解釋過﹐如果名稱後面不是以“.”結尾的話﹐它所屬的 ORIGIN ( @ ) 就會自動的加在該記錄名稱後面﹔所以﹐您可以只寫“ rh71 ”而不帶小數點結尾﹐就會變成“rh71.siyongc.domain.”了﹐這個名稱實際就是我所要的。不過﹐我建議您在設定 NS 的時候還是儘量使用 FQDN 為好。 接下來的 ‘ MX ’ 記錄恐怕要花些時間解析﹕
在郵件系統中﹐只要郵件伺服器雙方都知道對方的 IP 就可以進行郵件交換了。我們用 /etc/hosts 也可以做到名稱查詢的目的﹐但正如我們可以想像的﹕ineternet 有那麼多郵件伺服器﹐我們不可能一一為它們建立好 IP 對應。就算﹐我們可以這樣做﹐如果對方要更換郵件伺服器呢﹖要維護這樣一個對應殊非易事。既然﹐我們可以用 DNS 來查詢主機和 IP﹐為什麼不使用這麼便利的系統呢﹖這也是 DNS 系統的應用原因啊~~~ 但問題是﹐各區域的郵件伺服器名稱都不一樣﹐我們不可能知道對方的郵件伺服器主機名稱是什麼﹖就算知道﹐如果對方以後更換名稱呢﹖ 您看﹐即使我們使用了 DNS 系統來進行郵件路由﹐也不是這麼簡單的事情。但是﹐使用 MX 記錄就大大發揮了 DNS 系統的功能了﹕我們只要為每一個區域建立起 MX 記錄﹐利用 DNS 查詢得到的郵件伺服器名稱(郵件路由查詢中﹐DNS 只是其中一種方法)﹐這樣﹐當郵件伺服器要和對方的區域進行郵件傳遞的時候﹐就可以通過 MX 記錄得到對方的郵件伺服器名稱﹐而不需預先知道要和哪台郵件主機溝通。在日後﹐就算對方更換名稱﹐將 DNS 記錄改改就可以﹐完全無需知會其它郵件主機﹔而外面的郵件伺服器也根本無需認知到這個改變。 這樣的設計﹐無疑是非常靈活便利的﹗另外﹐使用 MX 還有一個功能﹕您可以用多個 MX 同時指定好幾台郵件伺服器名稱﹐從而提供備援或平行處理服務。在我這個例子中﹐我就分別為‘siyongc.domain’這個區域指定了兩個 MX 記錄﹕‘rh71.siyongc.domain.’和‘lp64.dmz.domain.’。但您有沒有發現它們前面都有一個數字呢﹖這數字有什麼作用啊﹖ 問得好﹗當外面的郵件伺服器通過 DNS 查詢到我們的郵件伺服器﹐如果發現超過一台主機負責郵件交換的話﹐數值越低的就越先被查詢。但有時候該主機沒有回應呢﹖那麼就由下一個數值的主機負責了。這樣有一個好處就是﹕就算第一台郵件伺服器出現故障﹐也不至於導致郵件交換功能癱瘓掉。我們通常會將各自的 MX 主機儘量分佈在不同的位置上(例如別的城市或國家的分公司主機)﹐假如萬一發生專線﹑甚至 ISP 的問題﹐我們還能將郵件轉往下一台 MX 主機。然而﹐在設計上﹐由於帳號和 client 端的設定因素﹐我們的郵件並非真的完全轉到下一個 MX 主機接收﹐而是先將郵件暫時佇列( queue ) 在那台機器上﹐當原來的 MX 主機恢復連線之後﹐郵件會自動的從佇列主機那邊送回來﹐這樣就能避免郵件丟失或被退信。 補充說明一下﹕上面這段說明單純只就 DNS 的設定而言的﹐事實上﹐還需要在 MX 指定的 ip 上面進行相關設定才有用。我們將會在“架設 MAIL”的文章為大家作進一步的說明。但您要知道﹕DNS 的功能只負責名稱解釋﹐至於解釋出來的結果是如何運用的﹐則與 DNS 無關。只是﹐在 mail system 設定中﹐需要 DNS 配合的地方有很多﹐尤其是 MX 相關的記錄。假如您心急想知道目前所談的功能﹐或許可以參考如下討論﹕
現在很多大型郵件系統﹐都可以同時使用多台郵件主機來提供郵件交換服務﹐這時候您可以將 MX 的 preference 設為相同﹐然後利用 NIS 和 NFS 服務﹐將郵件同步到相同的帳號去。您已經在前面的章節裡面學會了 NIS 和 NFS﹐等日後學習郵件主機架設的時候﹐不妨玩玩看﹗ 或許﹐您還發現我這裡為所有主機指定了 MX 記錄﹐有些直接指向自己(如 rh71﹑mdk 等)﹐而有些則指向別的機器(如 lp64﹑acer 等)。在 Linux 機器上面﹐各主機本身就具備郵件交換功能(除非您將之移除了)﹐而 Windows 則除非額外加裝﹐否則本身是沒有郵件交換功能的。這裡的設定是﹐從外面通過 DNS 查詢而寄往那些主機的郵件﹐都會轉到 MX 上面指定的郵件伺服器。這在實際的網路環境中很常見﹐尤其您接觸過“ mail hub ”這個概念。無論如何﹐我建議您應該幫負責 domain 的郵件伺服器本身設定一個偏好值最低的 MX 記錄指向自己(但這不是硬性必須如此的)。
在過去﹐有些人並不知道如何正確的運用 MX 記錄﹐但相對的﹐他們會為 domain 名稱本身設定一個 A 記錄 (@ IN A 192.168.100.23 )。這樣的做法雖然不是正統的﹐但也行之有年了。而且﹐在許多網站的 URL 上﹐這樣的設定﹐也能讓您少輸入“ www. ”這四個鍵~~~ ^_^ 另外﹐在這個檔裡面﹐您或許還發現‘ TXT ’這樣的記錄類別﹐它是‘Text Information’的意思﹐它實際上不牽涉任何設定﹐只記錄一些環境說明而已﹔這和‘ HINFO(Host Information) ’差不多﹐但 HINFO 一定要有兩項記錄(分別用引號分開)﹐其中第一項是關於 CPU 的訊息﹐第二項則是作業系統。然而﹐TXT 和 HINFO 這些資訊僅能在一個信任的環境中提供﹐如果您架設的 DNS 是對外提供服務的﹐那麼﹐就不要設定這些資訊了。要不然﹐入侵者可非常感謝您哦﹐因為您幫他們省卻了很多主機系統的探測手續~~~ 所以﹐這裡僅做範例﹐供您參考而已。 而最後您所看到的‘CNAME’記錄又是怎樣的呢﹖CNAME 也是一個常見的記錄類別﹐它是一個別名記錄( Canonical Name )。當 DNS 系統在查詢 CNAME 左面的名稱的時候﹐都會轉向 CNAME 右面的名稱再進行查詢﹐一直追蹤到最後的 PTR 或 A 名稱﹐成功查詢後才會做出回應﹐否則失敗。例如﹐在正解查詢中﹐一個 IP 通常(當然也有例外)﹐只會對應一個 A 記錄﹐但我們可以使用 CNAME 在 A 名稱之上賦予該 IP 更多的名稱。也就是說﹕所有關於‘’﹑‘ftp.siyongc.domain’﹑‘mail.siyongc.domain’這些名稱的查詢﹐實際上都會再查詢一次‘rh71.siyongc.domain.’這個記錄﹐直到找到它的 IP 位址為止。有些朋友或許會設定多層的 CNAME 查詢﹐例如﹕
B CNAME A 這樣的話﹐會一層一層的逐級 CNAME 下去... 但是﹐這很浪費 DNS 資源﹗因為每一個 CNAME 都一定會產生另外一個查詢動作﹐如果層級越多﹐那就產生越多的重複查詢。所以﹐精明的 DNS 管理員﹐都會儘量的減少查詢次數的發生﹐他會將 CNAME 變成這樣子﹕
B CNAME A 這樣就用心多了﹗ 基本上﹐我們在正解設定上所使用到的記錄大概就前面所看到的。哦﹐對了~~ 還有另外一個 /var/named/dmz.domain 檔案也不要忘記了﹕
您看﹗就這樣﹐我們的 DNS 就已經設定好了﹐包括反解和正解哦~~~ ^_^ ”那裡就設定過了﹐也就是修改 /etc/resolv.conf 這個檔案﹐將您剛設定好的 DNS 主機 IP 放在檔案的前排位置﹐如﹕
假如您的 client 和 server 在同一台機器上﹐那可以將第一個 name server 設定為 0.0.0.0 或 127.0.0.1 。 要是您使用 Windows ﹐但不是透過 DHCP 來指定 DNS 的話﹐那您或許需要手工設定了﹕控制台 --> 網路 --> TCP/IP (-> 網路卡) --> 內容 --> DNS 組態 ﹕
 請注意﹕如果您修改了這裡的設定﹐就算您的 Windows 是透過 DHCP 取得 IP 設定的話﹐也會以這裡的設定為準。如果您想使用 DHCP 的設定﹐那就選擇“關閉 DNS”吧。 要測試我們的設定是否生效﹐我們可以使用的方法有很多﹐其中最簡單的莫過於 ping 命令了。直接 ping 一下您所預期的 dns 名稱就知道結果了。 不過﹐ping 畢竟很有限﹐例如﹕您不能查詢 MX 和 NS 等記錄。實作上﹐我們最最常使用的 DNS 查詢工具是 nslookup 命令。關於 nslookup ﹐在“學習網路”的“”文章中有很詳細的例子﹐這裡不再重複。如果我們在測試中失敗﹐例如 nslookup 回應說﹕
這通常是反解記錄沒設定好的緣故﹐請確定 DNS 主機本身的反解有設定起來﹐而且可以被 DNS 追查得到。如果反解沒有授權下來﹐那就請上游 ISP 幫忙設定。不過﹐我發現這個錯誤信息似乎在新版的 nslookup 中不會出現﹐anyway ﹐請您自己留意吧。 有時候 nslookup 會停在某處一動也不動﹐其實它不是當掉了﹐而是在查詢沒結果之後等 time out 而已。您可以按 Ctrl + C 終止查詢﹐再打 exit 跳出來。不過﹐如果您在按了 Ctrl + C 之後接著再輸入一個無結果的查詢﹐那就好可能將 nslookup 當掉。這樣您可能要登錄進另外一個 terminal ﹐然後用 kill 將 PID 殺掉。同上﹐新版的 nslookup 沒有這個困繞﹐但如果按 Ctrl + C 的話﹐則會直接跳離 nslookup 程式。 然而﹐nslookup 似乎在以後的版本中不再維護了﹐取而代之的﹐就是 dig 命令﹐所以﹐當您在 Redhat 7.1 上輸入 nslookup﹐您會看到如下這樣的信息﹕
這段文字不用解釋了吧﹖真的不知道說什麼就查字典吧~~ ^_^ 這裡﹐我們不妨學習一下如何用 dig 來查詢和測試 DNS 服務。 基本上﹐dig 命令的語法如下﹕
dig [@server] domain [ 看起來蠻複雜的﹐恐怕要 man dig 才知道怎麼使用。不過﹐我們平時只用它來查詢 dns 資料的話﹐要使用到的選項也不會太多啦﹐如果您會得在 nslookup 中設定 type=XXX 的話﹐那您也可以用 dig 來查詢不同的記錄類別資料。例如﹕
上面是的命令是使用預設的 name server 來查詢 siyongc.domain 的 mx 記錄。當然﹐您也可以用 @ 來指定用某一台 name server 來查詢其它的資訊。例如﹐我要用 hinet 的 dns 來查詢負責 com.tw 的 NS 有哪些﹕
除了用 nslookup 和 dig 之外﹐如果您只想簡單的查詢 dns 資訊的話﹐那您可以用 host 命令。例如﹕
上面的命令就是用本機 name server 來查詢 siyongc.domain 的 any 資訊。至於 host 命令的格式如下﹕
host [-aCdlnrTwv] [-c class] [-N ndots] [-R number] [-t type] [-W wait]
name [server]老話啦﹐看 man host 以了解那些參數和選項的用法吧。 您可以發現﹕透過 nslookup ﹑ dig ﹑與 host 命令﹐事實上可以查詢到許多 dns 上面的設定資訊。所以﹐如果您的 DNS 是對外提供服務的話﹐請儘量儘量控制 DNS 資訊量﹐如果您覺得沒必要對外提供的﹐那就拿掉它。無論如何﹐關於內部網路的 DNS 資訊﹐是絕對不能對外散佈的。如果查詢的結果未如您所預期的﹐您就要進行 debug 工作了。 當然﹐還有很多很多~~~ 而最後一個網站是負責台灣的 domain 註冊的機構﹐您可以到那裡註冊所有以 tw 結尾的 domain﹐除了 twnic 之外﹐很多 ISP (例如 seednet )也有提供 tw domain 的註冊服務。 各網站的註冊手續和表格或許不儘相同﹐但基本上您需要提供的資訊還是大同小異的﹐我這裡就不介紹如何進行了﹐只要您身邊有字典都沒問題啦~~~ ^_^ 在您所提供的資訊中﹐其中有一項比較傷腦筋的﹐就是 ns 主機要指向哪裡﹖(註冊時需要最少兩台) 以正規的手續來說﹐如果您要用一個 IP 來作為您的 name server﹐您必須先要將這個 IP 在 whois 資料庫中註冊為 NS 記錄才能使用﹐假如該 IP 或是該 NS 已經註冊過了﹐您就不能按您的意思來註冊了﹐但您可以使用它(當然您要確定您能管理那台註冊主機﹐或是獲得對方的管理員同意)。但我這裡告訴您一個秘訣﹕第一次註冊 domain 的時候﹐隨便設定都可以﹗(哦﹐這是我在 dotster 上面的經驗啦﹐其它網站是否如此我就不清楚了~~) 然後您在完成註冊後﹐用您的帳號進去修改 name server 的 IP 就可以了(當然﹐您要設定的 IP 必須還沒被註冊過﹐或已經從 whois 資料庫中註銷)。 然而﹐如果您日後要變更您的 NS 和 IP 的話﹐是很麻煩的一件事情﹗而根據我以往的經驗﹐您最好用 email 和網站的支援人員取得聯絡﹐才能順利完成修改。嗯﹐這種工作實際上一點也不好玩啦﹐而且各網站有各自的方法和表格。比方說﹐如果您透過 networksolution 註冊的話﹐日後您要修改 name server﹐必須填寫 host forms﹐然後會根據您提供的確認方式確認之後才能完成﹐他們的確認方式有三種﹕
不過﹐在實作流程上非常複雜﹐比方說﹐如果原本採用 MAIL FROM 方式﹐但後來您的 email 信箱卻變更了﹐那就很麻煩了﹐因為對方不能根據您的新 email 信箱來作為確認依據的。我曾經為所服務的公司修改過 NS 記錄﹐到最後﹐只能以 fax 的方式來解決。 而像 dotster 網站﹐則只能透過帳號進行線上修改。這原本很方便﹐但最不好的地方是﹕他們不提供確認信息﹗往往﹐您以為已經修改完畢﹐但等了一個星期還沒生效﹐去信問他們﹐才知道原來要修改的那個 IP 並沒有註冊為 ns 主機﹐或已經註冊在別的名稱下面了。我曾經數次寫信給 doster 的 support 信箱﹐要求他們在線上修改後要向用戶提供確認資訊(不管成功與否)﹐但不知道他們現在是否有改善了呢﹖(如果還沒改變的話﹐請大家多作投訴﹐直到他們提供確認服務為止。)
但我也曾經試過到 networksolution 上面註冊一個 new host﹐然後到 dotster 那邊修改﹐也能順利完成﹗但這個後門﹐不知道現在是否還行得通呢﹖ 說實在﹐就算您註冊了 domain﹐如果您沒有固定 IP 的話﹐最好不要自己管 DNS ﹐請別的有固定 IP 的朋友幫忙﹐或是付費請人代管就是了。而上面提到的 domain 網站﹐大都提供這樣的服務。 另外﹐還有一個概念或許是許多 DNS 新手容易搞混亂的﹕我們這裡所說的 domain 註冊﹐在整個 DNS 系統中﹐僅屬於“正解”方面的註冊和授權而已﹔這和“反解”的授權毫不相關。而反解的授權﹐因為是跟據 IP 授權的﹐所以必須透過您的 IP 發放機構進行。換句話說﹕反解的授權﹐只能透過 ISP 進行。請您一定要區分這兩種授權模式。 如果您不知道如何申請和安裝這類動態 DNS 的話﹐您可以參考如下網頁﹕
Tips﹕如果您使用撥接式 ADSL (PPPoE) 並在 adsldns.org 上面完成註冊之後﹐您只需在 /etc/ppp 目錄下面修改一個 ip-up.local 檔(如果沒有請自行建立)﹐增加如下內容﹕
(注意﹕請將 XXXXX 修改為您的正確資料。同時﹐首兩行結尾的 \ 符號不要漏了﹐其左右沒空白﹔要不然﹐拿掉 \ 符號並將前面三行寫成一行。) 然後﹐只要您完成 ADSL 撥接之後﹐就能‘自動’的幫您修改 IP 記錄了﹗ 關於動態 DNS 的應用﹐除了上述的環境之外﹐在 DHCP 分配的網路中設定 DNS 也可以應用得上。但前提條件是﹕您的 named 必須是 bind 9.x 或以後﹐以及 dhcpd 必須是 3.x 或以後的版本。然而﹐RedHat7.1 上面預裝的 dhcpd 是 2.0p15-4 這個版本﹐您必須自行升級才能使用這個非常棒的功能。 下面﹐我將 dhcp 服務轉移到 mandrake 8.1 (其預裝的 dhcpd 版本是 3.0-0.rc12.1)﹐然後保留 named 在 rh71 上面﹐再透過 ddns 技術更新和維護 dhcp 所發放的 DNS 資料。我初步整理出來的步驟如下﹕
這樣會在當前目錄下產生兩個以 Kdhcp_mdk 開頭的檔案﹐有興趣您可以看看其中的內容。然後您將 Kdhdp_mdk*.private 中的最後一行 Key: 後面那串字串複製下來 (如﹕4sxutdFuNMqF1B0Q2GV1uQ==)﹐待會要用到。
然後重新啟動 dhcpd 的服務﹐並確定其功能正常。關於更多的設定﹐請 man dhcpd.conf ﹐搜尋 ddns 子串就可以找到。
再不然﹐用 tcpdump 抓封包看囉~~~ 老實說﹐我原本寫這篇文章的時候並沒有打算將 dhcp + dns 的動態更新寫進來的﹐因為還沒實作過。幸得在新聞組上得到 小州兄 的指點﹐才裝了個 Mandrak8.1 ﹐並按 man page 的步驟設定起來的。我覺得在本機上更新﹐也就是 dhcpd 和 named 都在同一台機器上﹐會比較容易成功。如果跨網路進行的話﹐那您得要首先解決網路想過的問題﹐例如路由和防火牆這些設定。 Anyway﹐我不敢保證您能按照上面的步驟實作出來﹐總要自己多嘗試嘗試吧。如果您想更進一步了解 DNS 的動態更新﹐您可以研究一下 nsupdate 這個命令。它可以讓您以交談模式來更新 named 的記錄設定。
除此之外﹐如果您還有興趣研究動態 DNS 技術的話﹐不妨到網路上找找 IXFR 的技術﹐也可以參考如下這些 RFC﹕1034﹐1995﹐1996﹐2136﹐2535﹐2694。
到這裡﹐您所需要具備的 DNS 技巧相信已經足夠應付普通網路的需要了。但如果您的網路非常龐大﹐而且 DNS 系統比較複雜﹐或是您有興趣知道 Internet 上是如何進行 DNS 授權的話﹐那您或許需要了解一下 DNS 的子網域 (sub zone) 授權設定。 這個問題不如用實際的例子來說明好了。正如您從本章所看到的範例﹐目前我在 rh71 上面已經設定有兩個 domain 的 zone ﹕siyongc.domain 和 dmz.domain 。假設我現在要在 siyongc.domain 分出一個 sub-zone﹐稱為 home.siyongc.domain ﹐同時將這個 sub-zone 授權給一台叫 diamond 的主機來管理﹔目前 diamond 上面有兩張網路卡﹕192.168.100.26 和 192.168.2.1 ﹐而 home 這個 sub-zone 需要管理的 DNS 除了 diamond 本身外﹐還有 pc100 到 pc200 ( IP 範圍從 192.168.2.100 到 192.168.2.200 之間) 等主機﹐他們都是由 DHCP 發放的。當然了﹐底層的網路連接﹐例如 hub﹑路由﹑防火牆﹑等等﹐都已經設定好了。那麼﹐我們要如何進行呢﹖ 首先﹐我需要修改 rh71 上的 /var/named/siyongc.domain 擋案﹐將 home 授權給 diamond.home.siyongc.domain 這台 NS 來管理﹐您只需在記錄檔後面增加這些句子就可以了﹕
上面我用一個 $ORIGIN 來宣告一個屬於 siyongc.domain 範圍內的 sub-zone 叫 home (如果改用帶小數點的 FQDN 的話﹐則寫成 home.siyongc.domain. )﹐以及負責這個 sub-zone 的 NS 主機﹐還有 NS 主機的 IP 位址所在。這裡的 NS 記錄就是用來授權用的了﹗目前我只授權給單一一台 NS 而已﹐如果您喜歡﹐那您可以授權多台 NS 主機。事實上﹐當您在網路上註冊 domain 的時候﹐他們也是在上游(如 com. 或 com.tw. ) 那邊幫您設定 NS 記錄和 NS 主機的 A 記錄而已~~~
接下來的設定﹐需要轉到 diamond 上面進行。首先﹐修改 /etc/named.conf 檔案﹐增加如下數行﹕
這裡﹐您或許發現我用 forwarder 將上游的查詢轉向正確的位置(當然﹐您直接在 options 裡面指定 forwarders 也可以)﹐您應該知道這樣做的好處了吧﹖除了無需繞到 root zone 往下查詢下來之外﹐更重要的原因是﹕這個 sub-zone 主機和上游主機不是同一台 NS ﹐除非這兩台主機同時是 internet 的合法 IP 且經過註冊(換句話說﹕父網的 NS 主機可以從 root zone 查詢下來)﹐否則的話﹐它就查詢不到其它 sub-zone 的記錄了﹗除了用 forwarder ﹐另外還有一個方法是﹕就是架設 slave 主機以獲得上游的 zone 資料。不管用哪一種方法﹐如果您不能查詢到上游 NS 的話﹐您就沒辦法查詢其他 sub-zones 了。 除此之外﹐我們還必須建立 /var/named/home.siyongc.domain 這個檔案﹐內容如下﹕
在這裡﹐我首先將 MX 的 TTL 降為 10 分鐘﹐因為我目前還不很確定這個 sub-zone 的郵件是否由 diamond 來管。如果不增加 600 這個欄位的話﹐那麼 TTL 會以前面的 $TTL 值為準﹐也就是一天。然則﹐一旦有別的 DNS 查詢過這個 MX 記錄﹐那麼這個記錄會在對方的 cache 中存在一天時間。假如我日後修改 MX 記錄的話﹐那我很可能要等一天之後﹐才能讓別的 DNS 查詢到新的設定值。
然而﹐在這個檔案中﹐您首次接觸到 $GENERATE 這個選項。如果您有寫過 shell script﹐或是具有“變數 (variable) ”概念的話﹐這行一點都不難理解﹕
不難理解吧﹖換而言之﹐如果您不使用 $GENERATE 的話﹐那就為 pc100 到 pc200 這 100 台主機設定 100 行 A 記錄就是了。那麼﹐請問﹕您願意用那個方法呢﹖ ^_^
好了﹐剛纔介紹的 sub-zone 授權﹐是屬於正解部份的﹐那麼反解又如何呢﹖通常來說﹐如果您獲得的 IP 是一整段 class (或 A 或 B 或 C ) 的話﹐在反解設定上也不會太難就是了。我相信聰明的您一定已經知道如何設定吧﹖(前面不是設定過了嗎﹖) 如果您真真正正了解 IP 和 Net mask 的關係﹐那我這裡要出一道難題了﹕我在我的網路設定中﹐10.0.1.0 這個網路實際上借用了 3 個 bit 來切割成 8 個子網路。而我將這台 rh71 上其中一個界面分配到 sub-net ID 為‘100’的這個子網中﹐也就是說﹐實際的 Net ID 應該是‘10.0.1.128’﹔而另外一個界面則分配在 10.0.1.0/27 這個子網路中。 在前面﹐我們已經設定過 0.1.10.in-addr.arpa 的反解了﹐但那次只是單純的為整個 C Class 做反解﹐事實上並沒考慮到 sub-net 的問題。現在我打算將這個網路的反解再進行子網路的授權設定。我暫時保留 10.1.0 這個‘父網’的反解﹐然後將 128 這個子網的反解授權給 10.0.1.130 ( lp64 ) 上面進行(至於其他網暫時不設定了﹐反正只要會了設定其中的一個﹐就能舉一反三)。
或許﹐在一開始弄 DNS 的時候就把子網帶進來﹐會顯得過於艱難。我這裡建議您大可先將關於子網的部份略過﹐等您對 named 有一定的經驗了﹐隨時歡迎回來再看﹐也很歡迎您 和網中人討論心得﹗ 無論如何﹐我先得在 rh7.1 上面確定 /etc/named.conf 這個檔案有關於‘父網’的設定﹕﹕
事實上﹐上面的內容和我們以前的設定沒什麼不一樣﹐您只需確定它有這個設定就行了。然而﹐原本的 /var/named/10.0.1.rev 卻必須修改一下﹐使之變成如下內容﹕
在這個特殊的“切割子網”例子中﹐其中最關鍵的設定是 CNAME 的設定﹐如果您沒忘記我前面是如何解釋 CNAME 的話﹐您會知道凡是查詢 CNAME 左邊的記錄﹐就轉到 CNAME 右邊再查一次。這裡﹐我們用 $GENERATE 的方式將 128-159 這段記錄用 CNAME 轉向 sub-128 這個子網查詢。
因為 128 至 159 這段 IP 實際上是在子網 10.0.1.128 裡面的範圍(這段現已授權出去﹐但您不能在 ineternet 上面查詢 203.30.35.128.134 這樣的五組數字的 IP 格式)﹐當人們要查詢所有以 10.0.1 開頭的 IP 的時候﹐都會先向 1.0.10.in-addr.arpa. 的 NS 查詢﹐也就是目前這台機器﹔然後再透過 CNAME 將查詢轉向其子網路 sub-128.1.0.10.in-addr.arpa. 進行查詢﹐直至找到 128 至 159 之間的 PTR 記錄為止。
在上例中的最後一行﹐我將 sub-128 這個自己定義的子網記錄項﹐以 NS 授權給 “lp64.dmz.domain.”來負責。而至於 lp64.dmz.domain 的 IP 在哪裡呢﹖那就透過正解查詢來獲得了﹐我們無需擔心這個﹐除非解那邊沒設定起來。 接下來﹐讓我們轉到 sub-128.1.0.10.in-addr.arpa. 的 NS ﹐也就是 lp64 這台機器上面。首先﹐需要修改 /etc/named.conf 檔案﹐讓 named 知道 sub-128 目前由它來負責﹕
這裡的 forwarder 之作用與前面介紹的 sub-zone 授權時的設定一樣﹕如果您不能查詢到父網的 NS 的話﹐您就沒辦法查詢其他子網路。 當我們完成 named.conf 的設定之後﹐還必須在 /var/named 目錄下面建立相應的檔案﹐也就是 10.0.1.128.rev 這個檔﹕
在當前的 Internet 環境來說﹐能順利申請到完整的一組 class IP 的情況實在非常少見了。這時候您很可能要需要上游 ISP 幫您做反解﹐要驚動他們是在所難免的。如果他們肯受權下來﹐那麼您自己的設計彈性就比較高﹐日後要修改也容易得多。但如果上游沒有受權的話﹐您可千萬不要越俎代庖﹐設了也等於白設﹕因為您的 NS 並沒有經過授權﹐別人是不能從 root zone 反查詢得到的。而且﹐更嚴重的是﹕如果您自己將整個 C Class 的反解私自設定起來的話﹐由於沒辦法知道除了您這個 subent 之外的其他 subnet 的資訊﹐也就沒辦法設定。這樣結果將會是﹕如果您不設﹐或許可以透過 ISP 查詢到它們﹔如果設了反而查不到﹗ 但是﹐如果在上游沒有授權的情況之下﹐您日後的每次修改﹐都必須要通知上游﹐才能保持資料的準確性﹐卻是十分的不方便。下面的這個方法是是一個折衷的辦法﹐您只需到上游註冊一次(如果上游不同意﹐請努力說服他們)﹐日後的變動則完全看您自己的意思了﹕ 假設您是一個 ADSL 的用戶﹐獲得 5 個可用 IP﹐分別從 211.2.3.113 到 211.2.3.118﹔同時﹐您為您目前的 domain 註冊為 my.domain。這樣﹐您首先要到上游完成反解的註冊﹐這樣設就可以了﹕
然後您也無需另外設定反解﹐全部都在 my.domain 的記錄檔上面設就可以了﹕
照這樣看來應該沒什麼問題了。假如您對子網劃分有不理解的地方﹐歡迎參考一篇我與網友的 (注意﹕內容是引用舊版的文章﹐所以設定上和目前的方法有所不同﹐但原理還是一樣的)。 許多人都覺得﹕我沒有設定反解﹑ISP 那邊也不願意幫忙設定﹐我的 DNS 還不是照常工作﹗那麼究竟什麼時候才會用到反解呢﹖如果不設定反解有什麼後果呢﹖嗯~~ 如果有這個疑問的話﹐我建議您先讀讀如下的文章﹐相信您就知道反解的重要性在哪裡了﹕
另外﹐如果 DNS 授權有誤﹐則很容易做成 lame server 的問題。發生這問題的原因是﹕從 DNS 系統上查詢某一個名稱的時候﹐獲得一個 NS 資訊﹐然後向那個 NS 進行查詢的時候卻得不到結果。您可以參考下面這篇文章認識問題產生的理論﹐然後進行修正﹕
不過﹐如果 lame server 是由於別人亂設而引起的話﹐那您只能設法與對方的管理原取得聯繫﹐然後請對方修改了。 DNS 系統在網路溝通上面提供了非常便利的途徑﹐一個設定完整的 DNS 系統﹐無論在管理或除錯方面都是非常有效的。然而﹐在許多網路入侵案例中﹐往往因為 DNS 提供的信息過多﹐而讓入侵者省卻了許多步驟和時間﹐這也增加了對入侵行為的偵察和預警的難度。 所以﹐假如您同時需要為內部和外部網路提供 DNS 服務﹑而又有條件的話﹐最好設定多台 DNS 伺服器﹐分別對內和對外提供服務。在所有這些對外服務的機器上﹐我們只設定最少的必須記錄就可以了﹐千萬不要把 HINFO 等一些關於主機和網路環境的記錄寫進去。同時﹐任何不必要對外提供的 IP 和主機記錄﹐一概刪除就是了。而其它的為信任網路提供服務的主機﹐則無論如何也不要讓過多的 DNS 信息流出 internet。您甚至可以通過火牆過濾來保護內部的 DNS 服務查詢。 為了獲得更好的安全效果﹐您可以在 /etc/named.conf 檔案中設定一些限制﹐讓 DNS 僅對那些信任的網路或主機提供服務﹐或是擋掉來自不信任主機的查詢。下面﹐我提供一個安全設定的範例給大家參考一下﹕
在設定 DNS 的安全原則的時候﹐有些問題您必須注意﹕
對於剛開始接觸 DNS 的朋友來說﹐常常會“硬性的”將反解和正解聯繫起來。其實在實際的設定中是非常多樣化的﹐反解和正解在許多情形下未必是一致對應的。比如我有一組 192.168.100.* 的 C Class IP ﹐我並非只能分配給 siyongc.domain 這一個 zone 。如果我喜歡﹐可以將裡面的 IP 分配給好幾個 zone 來使用。同理﹐我的 siyongc.domain 下面﹐也未必只能用 192.168.0.* 裡面的 IP﹐事實上我還可以使用其它的 IP 。很簡單一個例子是﹕我的 rh71 這台主機﹐就有三張路卡﹐它們分別屬於不同的 IP 網路﹐但它們可以使用同一個主機名稱﹐也就是說﹐您可以為同一個 RR 記錄名稱設定多個 A 記錄。 如果您機器有多個名稱的話﹐那麼﹐在反解那裡也容許一個 IP 有多個 PTR 記錄的。不過﹐如果您用 nslookup 的正常模式查詢的話﹐會以 round robind 的形式一次顯示一個記錄﹐您要經過 set type=ptr 之後才可以看到全部記錄。 每次當您修改了 master 機器上的的內容﹐請一定要更新 Serial 號碼﹗同時﹐在 slave 上面設定的時候﹐也不要漏了 masters 的 s 字母﹔同樣﹐設定 forwarder 的時候﹐最後也有一個 s 字母~~ 如果您要修改 NS 或 MX 這些敏感性記錄(例如移機或更換 IP )﹐事先請將 TTL 降低﹐然後等上一個 TTL 過期之後再修改﹐並且利用外面的 DNS 來查詢修改結果。等穩定之後才將 TTL 提高到原來水平。如果記錄資料都很穩定﹐不妨將 TTL 提高一點﹐這對於繁忙的系統有所幫助﹐但對於修改則非常不便。所以﹐如何拿捏 TTL 的水平﹐也是非常考究的。老實說﹐我自己對 DNS 的設定也是一知半解而已。如果您想看一看正規的設定範例﹐可以到 看看﹔ DNS 的技術原理則可以參考﹕。另外﹐ 這篇相當容易上手﹐也建議看看。最後﹐這個 網站﹐也有許多 DNS 的問題與解答﹐有問題可以到那裡找找﹐或許答案早在那裡了﹗還有﹐到 這個網站﹐您可以了解到最新最全面的關於 BIND 這個軟體的資訊。 如果您非常正經的想學習一下 DNS ﹐有一本 O'reilly 出版的書是非看不可的﹐那本書叫 『 DNS & Bind 』。您最好找最新版的回來看﹐聽說已經有第 4 版了。 假如您發現我在這裡有什麼失當之處﹐﹐以免誤導觀眾了。謝謝!
© 2001 Netman 網中人Last Updated: Sep 17, 2003 |
