網管人員對DNS的概念不清楚，經常導致DNS安全性的漏洞，若只有使用修補程式，無法解決全部的問題，必須從釐清觀念下手，才能徹底杜絕問題產生。
DNS（Domain Name System）是目前最常使用的網路服務之一，網際網路的興起帶動IP位址蓬勃發展，也讓名稱解析服務日趨重要，但是根據TWNIC 9月資料顯示，約有80%的DNS主機具有安全性漏洞，例如若不設定allow-transfer，其他DNS主機則可以自由謮取本機DNS的資料，當成 Master-Slave架構，轉移DNS名稱解析，類似網路釣魚手法，網路使用者在不知覺的情況下，導入另一個類似的網頁，造成資料遭竊取等問題。
DNS安全性漏洞除了透過修補程式補強外，大部分都是網管人員不正常操作導致，特別是採用Windows伺服器當成DNS服務時，只要依據精靈模式操作，就可以完成設定的情況下，很多人對DNS的概念不清楚，若將來需要更動服務時，錯誤的設定方式，經常讓DNS解析錯誤。
DNS要指向根節點（Root）查詢，非上層查詢
若DNS無法正常解析名稱，最常的處理方式是重新啟動DNS服務，但還必須了解為什麼解析錯誤，大多認為DNS查詢不到資料時，是向上層查詢，由上層負責解析資料，例如TWNIC負責各企業組織的網域、臺北市資訊中心負責臺北市中小學資訊網路，當使用者指定本機DNS為解析名稱伺服器時，若本機無法提供對應的名稱，則會向上層配送網域的組織查詢名稱資料，但是事實上是指向根節點查詢，才能正確解析名稱資料，因為DNS最重要的概念就是提供最佳尋找路徑，如果本機DNS是第1次查詢名稱，快取記載檔並沒有任何記錄時，會分析「．」的位址，從資料庫中找出最接近的位址分類，並依據查詢的內容，提供最佳的尋找路徑。
DNS只能從本機資料庫中分類位址，並指向另1臺DNS解析，當其他DNS也發生相同問題時，也採用相同的方式處理，因此，DNS只會告知向哪1 臺主機查詢，並不會指定哪1臺主機對自己查詢，當本機DNS無法解析名稱時，必須指向根節點查詢，由根節點一層層向下指定最佳尋找路徑，才能正確查詢到服務名稱，因為若指向上層查詢，而上層DNS也沒有記錄資料，則無法提供最佳的尋找路徑，就會導致DNS無法解析的問題。
反解的IP位址只是符號，正解與反解沒有直接關係
對DNS而言，反解的IP位址只是一連串的符號，例如子網域211.72.210.0/24的反解則為210.72.211.in- adrr.apra，雖然從字面上還是數字，但實際上，反解已經不具備IP位址的特性，單純只是符號，所以我們可以在反解資料中插入其他符號，或將內容前後調動，並不會有影響。
此外，DNS階層式架構中，最頂層是根節點，其下有.tw、.com、.net、 .cn、.arpa等多種子節點（目前有243個國碼型及13個全球型的頂級網域），而反解則由.arpa負責外，其他都負責正解部分，因此，IP位址的正解與反解由不同的組織負責，並沒有直接關係。
若DNS主機不設定反解資訊，單純從正解邏輯下，依然可以正確提供名稱解析服務，只是依據TWNIC的統計資料顯示，DNS查詢時，正解約占 40%、反解則占60%，許多服務像郵件伺服器、系統記錄服務、檔案伺服器等都會要求反解查詢，設定反解查詢除了增加連線速度外，郵件伺服器也可以反解信件來源，確保是否為垃圾郵件，提供阻礙垃圾訊息的第一道關卡，建議將正、反解設定為相同，以防止DNS名稱查詢失敗。
若要指向非管轄的DNS主機，要告知對方，以防無法解析名稱
當本機指定某臺DNS為名稱解析服務時，若該臺DNS並沒有在此網域運行，則會造成解析錯誤等訊息，特別在新版Bind 9.x中，以舊版Bind 8.x為例，當我們查詢www.xxx.com.tw的主機時，若該網域的DNS只有xxx.com.tw，NS Record無法查詢到www主機時，會自動向A Record查詢，只要A Record具備www主機的IP位址，依然會導向www主機，然而新版Bind 9.x中，則會一直查詢NS Record的資料，無法釋放資料，造成解析錯誤。國內大多數企業都將DNS指向Hinet，而Hinet則是採用舊版系統，比較沒有這種問題，若指向 TWNIC的DNS，則因為採用新版系統，可能造成DNS無法授權。
還有1種DNS指定錯誤稱為Lame Server，因為一般大多會建置2臺DNS，以提供負載平衡或備援使用，但是可能因為預算因素，只有建置1臺，另1臺則指向像Hinet等主機服務，當對方寄信件到公司郵件伺服器時，DNS會隨機指向自己或Hinet的主機，若信件從Hinet主機解析，則會被當成外部郵件，重新等到下次回寄到公司的郵件伺服器，此時，又會隨機選擇是公司或Hinet的DNS主機，若是重要的電子信件，就會延遲送達時間，建議公司最好建置2臺DNS主機，或與上層組織要求將該DNS設定成第2臺主機，以避免Lame Server問題產生。
操作資源記錄要注意小細節
最後就是DNS設定上的錯誤。DNS可分為權威與快取等2種主機類型，其中權威主機又可分為Master與Slave等2種，可以將Master 與Slave主機視為負載平衡或備援用途，只需要操作Master，就可以自動同步到Slave上，而Master與Slaver的同步依據就是序號（Serial）參數，每次更動Master DNS設定時，序號也必須跟隨改變（加1），否則Slave無法同步資料，建議直接採用年月日版本的方式，例如2005101001。
若只申請1個IP位址，而企業內部卻有許多網路服務主機時，DNS常會利用Cname別名的方式，導引到各種網路服務主機，但是若在NS及MX Record，採用Cname，則會造成無法辨認電子郵件伺服器的問題，我們可以直接改用A Record指定的方式解決，例如同時將211.72.211.80同時以in A的方式指向www.xxx.com.tw及ftp.xxx.com.tw主機，減少別名產生的問題。
最後為了安全性考量，建議指定Master與Slave主機的IP位址，避免將Master的資料同步到其他不合法的主機上，這也是造成網路釣魚的原因之一，損失使用者的權益。
DNS（Domain Name System）是目前最常使用的網路服務之一，網際網路的興起帶動IP位址蓬勃發展，也讓名稱解析服務日趨重要，但是根據TWNIC 9月資料顯示，約有80%的DNS主機具有安全性漏洞，例如若不設定allow-transfer，其他DNS主機則可以自由謮取本機DNS的資料，當成 Master-Slave架構，轉移DNS名稱解析，類似網路釣魚手法，網路使用者在不知覺的情況下，導入另一個類似的網頁，造成資料遭竊取等問題。
DNS安全性漏洞除了透過修補程式補強外，大部分都是網管人員不正常操作導致，特別是採用Windows伺服器當成DNS服務時，只要依據精靈模式操作，就可以完成設定的情況下，很多人對DNS的概念不清楚，若將來需要更動服務時，錯誤的設定方式，經常讓DNS解析錯誤。
DNS要指向根節點（Root）查詢，非上層查詢
若DNS無法正常解析名稱，最常的處理方式是重新啟動DNS服務，但還必須了解為什麼解析錯誤，大多認為DNS查詢不到資料時，是向上層查詢，由上層負責解析資料，例如TWNIC負責各企業組織的網域、臺北市資訊中心負責臺北市中小學資訊網路，當使用者指定本機DNS為解析名稱伺服器時，若本機無法提供對應的名稱，則會向上層配送網域的組織查詢名稱資料，但是事實上是指向根節點查詢，才能正確解析名稱資料，因為DNS最重要的概念就是提供最佳尋找路徑，如果本機DNS是第1次查詢名稱，快取記載檔並沒有任何記錄時，會分析「．」的位址，從資料庫中找出最接近的位址分類，並依據查詢的內容，提供最佳的尋找路徑。
DNS只能從本機資料庫中分類位址，並指向另1臺DNS解析，當其他DNS也發生相同問題時，也採用相同的方式處理，因此，DNS只會告知向哪1 臺主機查詢，並不會指定哪1臺主機對自己查詢，當本機DNS無法解析名稱時，必須指向根節點查詢，由根節點一層層向下指定最佳尋找路徑，才能正確查詢到服務名稱，因為若指向上層查詢，而上層DNS也沒有記錄資料，則無法提供最佳的尋找路徑，就會導致DNS無法解析的問題。
反解的IP位址只是符號，正解與反解沒有直接關係
對DNS而言，反解的IP位址只是一連串的符號，例如子網域211.72.210.0/24的反解則為210.72.211.in- adrr.apra，雖然從字面上還是數字，但實際上，反解已經不具備IP位址的特性，單純只是符號，所以我們可以在反解資料中插入其他符號，或將內容前後調動，並不會有影響。
此外，DNS階層式架構中，最頂層是根節點，其下有.tw、.com、.net、 .cn、.arpa等多種子節點（目前有243個國碼型及13個全球型的頂級網域），而反解則由.arpa負責外，其他都負責正解部分，因此，IP位址的正解與反解由不同的組織負責，並沒有直接關係。
若DNS主機不設定反解資訊，單純從正解邏輯下，依然可以正確提供名稱解析服務，只是依據TWNIC的統計資料顯示，DNS查詢時，正解約占 40%、反解則占60%，許多服務像郵件伺服器、系統記錄服務、檔案伺服器等都會要求反解查詢，設定反解查詢除了增加連線速度外，郵件伺服器也可以反解信件來源，確保是否為垃圾郵件，提供阻礙垃圾訊息的第一道關卡，建議將正、反解設定為相同，以防止DNS名稱查詢失敗。
若要指向非管轄的DNS主機，要告知對方，以防無法解析名稱
當本機指定某臺DNS為名稱解析服務時，若該臺DNS並沒有在此網域運行，則會造成解析錯誤等訊息，特別在新版Bind 9.x中，以舊版Bind 8.x為例，當我們查詢www.xxx.com.tw的主機時，若該網域的DNS只有xxx.com.tw，NS Record無法查詢到www主機時，會自動向A Record查詢，只要A Record具備www主機的IP位址，依然會導向www主機，然而新版Bind 9.x中，則會一直查詢NS Record的資料，無法釋放資料，造成解析錯誤。國內大多數企業都將DNS指向Hinet，而Hinet則是採用舊版系統，比較沒有這種問題，若指向 TWNIC的DNS，則因為採用新版系統，可能造成DNS無法授權。
還有1種DNS指定錯誤稱為Lame Server，因為一般大多會建置2臺DNS，以提供負載平衡或備援使用，但是可能因為預算因素，只有建置1臺，另1臺則指向像Hinet等主機服務，當對方寄信件到公司郵件伺服器時，DNS會隨機指向自己或Hinet的主機，若信件從Hinet主機解析，則會被當成外部郵件，重新等到下次回寄到公司的郵件伺服器，此時，又會隨機選擇是公司或Hinet的DNS主機，若是重要的電子信件，就會延遲送達時間，建議公司最好建置2臺DNS主機，或與上層組織要求將該DNS設定成第2臺主機，以避免Lame Server問題產生。
操作資源記錄要注意小細節
最後就是DNS設定上的錯誤。DNS可分為權威與快取等2種主機類型，其中權威主機又可分為Master與Slave等2種，可以將Master 與Slave主機視為負載平衡或備援用途，只需要操作Master，就可以自動同步到Slave上，而Master與Slaver的同步依據就是序號（Serial）參數，每次更動Master DNS設定時，序號也必須跟隨改變（加1），否則Slave無法同步資料，建議直接採用年月日版本的方式，例如2005101001。
若只申請1個IP位址，而企業內部卻有許多網路服務主機時，DNS常會利用Cname別名的方式，導引到各種網路服務主機，但是若在NS及MX Record，採用Cname，則會造成無法辨認電子郵件伺服器的問題，我們可以直接改用A Record指定的方式解決，例如同時將211.72.211.80同時以in A的方式指向www.xxx.com.tw及ftp.xxx.com.tw主機，減少別名產生的問題。
最後為了安全性考量，建議指定Master與Slave主機的IP位址，避免將Master的資料同步到其他不合法的主機上，這也是造成網路釣魚的原因之一，損失使用者的權益。
沒有留言:
不接受新意見。