TWNIC 98年度 DNS 安全教育訓練 TWNIC 技術組編撰 2008.03.23.

Presentation on theme: "TWNIC 98年度 DNS 安全教育訓練 TWNIC 技術組編撰 2008.03.23."— Presentation transcript:

1 TWNIC 98年度 DNS 安全教育訓練 TWNIC 技術組編撰

2 TWNIC DNS 安全教育訓練 DNS基礎概念 DNS安全相關設定 DNS 相關應用
1.域名介紹:網域名稱的概念及其應用方式的介紹 2.DNS基本概念及運作:DNS發展的歷史和整個DNS架構，運作原理以及網域正反解所代表的意義等等介紹 3.域名的申請與DNS指定:以TWNIC所提供的註冊系統為例來了解Domain Name的申請以及設定方式 4.DNS設定介紹:介紹BIND以及Windows的DNS Server設定， RR的說明， 正反解zone的設定 5.DNS各種問題之探討與觀念介紹: 一般常見之設定錯誤及觀念錯誤及其可能造成的影響說明

3 DNS基礎概念

4 網域名稱是什麼? 網域名稱是企業或個人在網路上的身份， 如同 IP 一樣，都具有唯一的特性 網域名稱比 IP 好記
好記的網域名稱成為大家申請的對象 字數少/特殊意義單字/諧音字 當你連上一個網址如在URL打上﹕ 但如果您知道這個 .twnic.net.tw)，比記憶 IP位址(如﹕ )，往往容易得多，而且當更換IP時(如更換ISP時)，也不用一一通知所有使用者說我的網頁換IP了，只要在DNS設定改一下，使用者用原來的網址(www .twnic.net.tw)一樣可以連得上. (DOMAIN NAMES - CONCEPTS AND FACILITIES) (DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION) 在上述 RFC 中定義 domain name 的 label 由 a-z(大小寫)， 0-9 及 “-” 所構成(“-”不得在第一及最後一個字出現)，lable (兩個 . 中間) 長度最長為 63 個 bytes，labels 間以“.”連結，每個 domain name 最長為 255 bytes，最多由 127 個 label 組成.

5 域名之分類 分類: 在區分不同的屬性 目前 tw 之第二層域名 TWNIC 於2005/11/1 開放泛英(xxx.tw) 申請
Top Level Domain (TLD) 頂級域名 gTLDs: com/net/org/gov/edu/… 共18類 ccTLDs: tw/cn/jp/us 共 248 個 Second Level Domain (第二層域名) com.tw/org.tw/ 等 目前 tw 之第二層域名 com.tw/net.tw/org.tw/edu.tw/gov.tw/mil.tw idv.tw/game.tw/club.tw/ebiz.tw TWNIC 於2005/11/1 開放泛英(xxx.tw) 申請 gTLD COM，NET，ORG，MIL，GOV，EDU，INT，ARPA aero， biz， coop， info， museum， name， pro… ccTLD TW，CN，JP…(ISO ) 在ccTLD依各國管理政策有下列三種情況: 單位名稱，如: ibm.uk 屬性名稱，如: com.tw， net.tw， ne.jp 地理名稱，如: tokyo.jp ICANN在最近新增了七個gTLD: aero， .biz， .coop， .info， .museum， .name， .pro

6 Internet 的歷史(1) 1960 年代 1970 年代 57 ARPA 觀念之提出及 IP 觀念之產生
61 分封交換關念之提出 Time Sharing 多工觀念之提出 69 ARPANet誕生,連接數個研究單位 1970 年代 70 hosts 之使用, 71-72 代表 73 FTP 出現/互連網觀念被提出 研究出乙太網路(Ethernet) 74 TCP 通訊協定出現 Telnet 出現 76 第一封經由網路傳送的 出現 78 發明數據機(modem) 79 MUD 出現 Newsgroup 出現(usenet)

7 Internet 的歷史(2) 1980 年代 80 400台主機連接超過10000 名使用者 DOS 出現並與 IBM 結合
81 Gateway(EGP) 觀念出現 IBM PC 問世 82 TCP/IP 標準確認 Internet 名詞出現 83 名稱伺服器出現 網域名稱制度提出 84 DNS 標準確立 Cisco/AOL 成立 85 Symbolics.com 為第一個網域名稱註冊者 86 NNTP(usenet) 標準確立 SGML 出現(HTML 前身) PC Virus 出現 88 第一個 Internet Worm 出現,感染 5% 主機 CERT 成立 Eudora 出現,刺激了 的發展

8 Internet 的歷史(3) 1990 Internet 至 1995 大柢上奠基現今發展的基礎
90 TANET 成立 撥接服務出現 WWW 觀念提出 91 Internet 開放商用化 92 中山大學成立台灣第一個BBS站 WWW 服務問世 93 第一個瀏覽器 Mosaic 問世, WWW 急遽發展 網域名稱伴隨 WWW 需求快速發展 94 Hinet 商用Internet服務 網路銀行/拍賣出現 Netscape 出現,結合 功能, Eudora 漸式微 95 Window 95 發表 Amazon/Yahoo/Ebay 成立 IP Phone(VoIP) 出現 Netscape vs. IE 之爭 Internet 至 1995 大柢上奠基現今發展的基礎

9 DNS 背景介紹 DNS 的歷史 IP Network 的興起,網網互連 愈來愈多的主機,hosts 檔的出現 主機名稱的衝突 資訊的一致性 資料的管理 1984年 Paul Mockapetris 建立了第一個DNS 的規範(RFC1034， RFC1035) 85 年隨即出現了第一個網域名稱 在 Unix-Base 的環境，hosts 位於 /etc 下，而 Window 的環境下則置於 /Win/system32/drivers/etc下，其格式為: ;IP Hostname Alias pc071.twnic.net.tw pc071 而一般作業系統設定之解析( Resolver) 流程順序都會設成先讀這個檔，若查得到則使用該 Hostname 之IP，若查不到則詢問 DNS，故 Hosts 檔目前仍經常使用，尤其在其Alias 及功能，可以簡化不少鍵盤輸入的長度，如　telnet pc071，即會連線到 ，而可不必輸入過長之 pc071.twnic.net.tw Hosts 之另一個較少人知功能在於在機器的反解，因為有許多服務會檢查反解是否設立，而設於 DNS 對於一般人而言較有困難，偷懶的方法即在於 hosts 中指定，但同樣的，僅限於本機有效. 使用 Hosts 雖有不少好處，但有時難免會用 DNS 的資料會有不同的結果，維護 hosts 檔資料的正確性有時還是有必要的，這是不少人常忽略的地方. RFC882/1034/1035 DOMAIN NAMES - CONCEPTS and FACILITIES 等多篇 RFC，主要在介紹網域名稱的概念及其階層屬性之概念，並訂定出許多 DNS 不同的記錄特性

10 域名與Internet相關服務之關係 名稱解析服務為 Internet 服務最基礎的一環 名稱解析提供機器名稱與 IP 位址雙向對映的機制
TWNIC 被列為國內20最重要的資安單位 名稱解析提供機器名稱與 IP 位址雙向對映的機制 WWW <-> MAIL msa.hinet.net <-> 網域名稱比 IP 容易記， 且具代表意義 使用網域名稱讓系統更具移值性，當 IP 變動，只需更改 DNS 設定即可，程式網頁等不需更改 使用者經常使用正解來查詢IP 電腦經常使用反解來查主機名稱 電腦會作反解的行為主要有下列兩個目的： 1.讓使用者或管理者容易了解連線情形，如在畫面或Log中顯示網域名稱會比顯 示IP讓人更容易了解連線對象是那個單位 2.安全考量，如某些server會以連線對象的IP查網域名稱，再查網域名稱對應的IP是否一致 DNS提供主機名稱及IP的精確對應，但DNS並不是一個目錄服務，無法提供檢索功能

11 DNS 運作模式 名稱查詢之服務 分散式 穩定 樹狀結構 效率 自己的資料由自己維護，而其他人的資料則分散在全球
全球最大的分散式資料庫系統 以樹狀結構的方式找到目的位址(每個結點需要授權) 目前 Root Server 分布情形 穩定 負載平衡:可由 Master 主機自由的複製到 Slave 主機 備援:一個網域名稱可有多台主機共同服務(輸流查詢) 樹狀結構 經由全球唯一的 Root Server 達到正確搜尋的目的 Root Server 共十三部，每一部可能都有許多 Mirror (如 f.root-servers.net 有二三十部) 效率 使用 UDP 封包 查詢速度基本上都在 100 msec 內 經由 Cache 來加快 DNS 的查詢 目前全球有超過一億部的 DNS 系統，以上述的特性運作，可正確且快速的解析到網域名稱與IP的對應，這些對應都由 Root (“.”) 開始，故其地位相當重要 若一個網域名稱有三部 DNS 主機，其間的資料同部以 Zone Transfer 達成，即 DNS 間即可進行同步做業，而不需其他額外成本(Master vs Slave)，而三部 DNS 主機再接受查詢時，是以隨機方式進行，即是每次查的主機皆不同，進而達到負載平衡之效果. 此外， DNS 查詢使用 UDP 封包，其效率與速度皆極快，並能降低 DNS 的負載，根據我們的測試，在 LAN 內 (100 BaseT)，使用一般 PC 即可達到每秒近 6000 次的查詢，使用好一點的機器則可以有更高的效率. 不過，UDP 封包有 512 bytes 的限制，故 DNS 查詢所帶的資料不可超過 512 bytes， 所以一個 UDP 封包 大柢上只能容納 13 部 Root Server，若含有 IPv6 的主機的話，基本上這個數字會再降低(IPv6 的 Address 有 16 個 bytes)

12 DNS 名稱表示法 Fully Qualified Domain Name (FQDN) WWW.EP.NET. 每一個名稱間以 . 隔開
一個名稱對應到多個 IP 稱為 Round Robin 一個名稱對應到不同的服務如 MX 每個 FQDN 如同 IP 一般皆具有唯一性 其限制 最多 127 層 每個分支最長63 字元 (a-z， 0-9， -) 總長 255 字元 注意結尾的點 Ex: 對應到 (IPv4,A) 或 2001:c50:ffff:1:2e0:18ff:fe95:b229 (IPv6,AAAA)

13 DNS 樹狀結構 Root tw cn com net biz arpa … com net gov … in-addr ip6 e164
IPv6 反解 twnic 211 IPv4 反解 72 www whois cdns Zone1 DNS 的階層式架構並不僅此於其隸屬關係，亦是一個查詢時的流程，當我們要查詢 時，當您的 Client DNS 收到這個查詢請求時，並不知道要去何處詢問，所以會從根 (Root .)開始詢問，一路的找下來，並找到其結果為 ，所以，這個根就很重要了，根沒有了，全世界整個 DNS就會出現很大的問題.目前根伺服器在全世界共有13部，它們扮演著極其重要的角色.依此推論，如果 tw 這個位置的 DNS 出了問題，代表著所有台灣網域名稱的服務也會跟著出問題，故所處位置愈上層，其重要性也愈高，其穩定度也就更受關切.故，行政院資安會報將 TWNIC 列為二十個重要的系統，並屬於 A+ 級，要求二十個重要單位要在今年內取行資安認證，而 TWNIC 於今年三月份亦巳通過 BS7799 之認證，故在一般的公司， DNS 的安全亦不可不慎. 前段所述為一網域名稱求 IP 的流程 (正解)，這張表上同時亦列出 IP 的階層關係，因為域名之特性是有後往前推(後序)，故 IP 在網路上定成名稱時，其結構即為 x in-addr.arpa.，查詢此一名稱即代表要查其域名(反解).其中 arpa. 是用於數字上，in-addr 表示 internet address (一般人往往不知為何要設 in-addr.arpa.)，ip6 用於 IPv6 位址. 上圖 tw cn 該排，通常我們會稱為 TLD ( Top Level Domain) ， 其中國碼的部份為 ccTLD，非國碼的部份為 gTLD，而其下的則稱為 SLD ( Second Level Domain，ex: com.tw)，目前除了13部的 Root 伺服器外，共有 243 個 ccTLD 及 13 個 gTLD， 而台灣目前的 SLD 計有Com.tw/net.tw/org.tw/edu.tw/ mil.tw/gov.tw/game.tw/ ebiz.tw/club.tw/idv.tw (稱為屬性型，因其帶有特性)等，及 中文.tw (稱為泛用型) 等不同之 SLD. 210 211 為網域名稱或機器名稱 host1 host1 為上一層與下一層的委任關係 註 DNS 的搜尋由上往下

14 運作原理 圖示 root .tw net.tw Recursive Non-Recusive twnic.net.tw
是否屬於自己的 DN ? 是則回應結果 是否有 Cache 資料 ? 是則回應結果 皆非則向 root “.”　詢問---> 得到的 DNS 資料及主機資料都會 Cache 以備下一次資料被查詢時使用 詢問 .tw 再哪 ? 回應.tw 位址s .tw 詢問 net.tw 再哪 ? 回應 net.tw 位址 詢問 twnic.net.tw 再哪 ? 查詢 net.tw 回應結果 回答 DNS 位置 Recursive Non-Recusive Recursive 遞迴查詢: 使用者只送出一個查詢， 由DNS Server 完成其他所需的查詢後回應 Non-Recusive 反覆查詢(非遞迴查詢) 每一個查詢直接給予指示性的回應， 由使用者端再進行後續的查詢 通常Client到Server之間是 Recursive 查詢 Server到Server之間是Interactive 查詢 詢問 到底再哪 ? twnic.net.tw 回答

15 運作原理(1) 當被詢問到有關本域名之內的主機名稱的時候，DNS伺服器會直接做出回答(此一答案稱為權威回答(Authoritative Answer)，此一主機稱為權威主機) 如果所查詢的主機名稱屬於其它域名的話，會檢查快取(Cache)，看看有沒有相關資料 如果沒有發現，則會轉向root伺服器查詢，然後root伺服器會將該域名之授權(authoritative)伺服器(可能會超過一台)的地址告知 即是若您的 DNS 管理這個網域名稱時，有人向你查詢這個名稱的資料，可以直接做出回答，因您的 DNS Server 即是負責此一網域名稱之主機，所以稱為權威主機，而回應的結果稱為權威回答 在每一個名稱伺服器中都有一個快取暫存區(Cache)，這個快取暫存區的主要目的是將該名稱伺服器所查詢出來的名稱及相對的IP位址記錄在快取暫存區中，這樣當下一次還有另外一個用戶端到次伺服器上去查詢相同的名稱時，伺服器就不用在到別台主機上去尋找，而直接可以從暫存區中找到該筆名稱記錄資料，傳回給用戶端，加速用戶端對名稱查詢的速度，而您的 FQDN 資料要被人快取多久，則是由您的記錄上的 TTL 欄位決定(後面章節將介紹到 TTL) 如果名稱伺服器在資料記錄查不到且快取暫存區中也沒有時，伺服器首先會才會向 Root Server 查詢，所以 Root Server 在 Internet 上扮演極為重要的角色，目前 Root Server 由 ICANN 管理.

16 運作原理(2) 本地伺服器然後會向其中的一台伺服器查詢，並將這些伺服器名單存到記憶體中，以備將來之需(省卻再向root查詢的步驟)
遠方伺服器回應查詢 將查詢結果回應給客戶，並同時將結果儲存一個備份在自己的快取記憶裡面 如果Cache資料的時間尚未過期之前再接到相同的查詢，則以存放於快取記憶裡面的資料來做回應 DNS用戶端向指定的DNS伺服器查詢網際網路上某台主機名稱 當DNS伺服器在該資料記錄找不到用戶所指定的名稱時，會轉向該伺服器的快取暫存區找尋是否有該資料 當快取暫存區也找不到時，會向最接近的名稱伺服器去要求幫忙找尋該名稱的IP位址 在另一台伺服器上也有相同的動作的查詢，當查詢到後會回覆原本要求查詢的伺服器 該DNS伺服器在接收到另一台DNS伺服器查詢的結果後，先將所查詢到的主機名稱及對應IP位址記錄到快取暫存區中 最後在將所查詢到的結果回覆給用戶端

17 DNS 的平台 UNIX Windows 常見為ISC BIND 共約發行四五十個版本 ( 4.X~9.X)
最新版本 ， 8.4.7， (2006/06/27) 建議使用 以上版本 穩定，可靠，最多人使用 Windows 可見於 Windows Server 級的版本 簡單設定是其優點 GUI 設定 根據 BIND 4.x 修改而來,並持續更新 Bind 可於 Widnows 上運作 V8.x及V9.x皆整套程式重新改寫 /etc/named.boot (v4) -> /etc/named.conf ( v8) zone transfer ( named vs named-xfer ) no more fork for each AFXR jobs ( for v 8.1.X and later ) BIND 4.x/8.x 版本的重大差異 新的功能 negative caching bind_notify， IPv6 support， RFC 1535 compliant， … BIND 8.x/9.x 版本的重大差異 DNSsec IPv6 support(A6) Domain alias(DNAME) 多國語文(8 bits) 目前使用最普遍的為 9.x (主要因為 OS distribution 所附的版本現巳多 9.X) 但 ISP (HINET，SEEDNET) 仍有使用 8.x 之狀況

18 名稱伺服器類型 權威主機(Authoritative) Cache-Only 主機 (168.95.1.1) 可管理或回答其網域名稱之答案
Master 主機指 DNS 所管轄的資料是從檔案 ( Zone File) 中而來 (twnic.net.tw) Slave 主機指 DNS 所管轄的資料是以轄區傳送(Zone Transfer) 從 Master 而來 (ns.twnic.tw) Cache-Only 主機 ( ) 即沒有管理任何的網域名稱，接受查詢與回應並將其快取以備使用 轄區傳送 在舊版的Bind(4.x)稱為primary與secondary，在新版的Bind(8.x以後)稱為 master與slave master DNS伺服器是架設在某一個網域下被主要授權並控制所有名稱 記錄的主控制伺服器，管轄著所有該網域的記錄資料，這些記錄資料只 有master可以修改. 但如果在一個比較大型的網路中，DNS伺服器就會變得很繁忙了，所以您可以設定多個DNS來分擔master的工作，但您或許不願意到每一個DNS伺服器去更新資料吧﹖而且就算您願意這樣做，也容易出現錯誤或資料不同步的情形.這樣您可以設定其它的伺服器為slave DNS來複製master上面的記錄資料，這樣，其它的電腦可以被指定到不同的DNS做查詢，既可以分擔master的工作，而且資料也可以自動進行同步工作.您可以設定DNS資料同步的時間間隔，在dns檔案中的Refresh設定就是了.同時您還會看到Serial，當slave的上面的serial數字少於它，資料就會被複製，否則會被忽略.所以更新的 Zone File 的資料時，一定要記得更新 serial 數字 +1. Zone File slave Internet 轄區傳送 master slave

19 正解/反解之意義與原理 正解 (forward domain): 由機器名稱對應至 IP
反解 (reverse domain): 由 IP 對應至網域名稱 反解的 DNS Query 遠比正解高出許多 向 ISP 提出 IP 建立反解的需求 正反解一致有其必要性 雖然多數的系統不強求正反解一致性,但少數的公司或學校對此仍有要求 由來源 IP 查反解名稱，依結果再查正解，並檢驗其結果 有部分的Mail Server也會使用正反解確認的機制來減少SPAM的問題 正解 com.tw，org.tw，net.tw，idv.tw ， game.tw ， club.tw ， ebiz.tw ， tw ---twnic及registrars edu.tw---教育部 gov.tw---研考會 com，org，net---verisign的registrars 反解 核發IP的ISP

20 DNS設定介紹 用 BIND 還是用 Windows DNS ? BIND 版本差異 BIND 工具程式 設定檔 named.conf
根伺服器介紹與設定 zone file基本設定 資源紀錄（SOA，NS，A，CNAME，MX，PTR…） 正解/反解設定 主要（master）/次要（slave）伺服器的關係容錯及負載平衡功能 (Round Robin) named之參數說明及啟動與停止 WINDOWS DNS 設定介紹 使用 nslookup/dig 自我檢測 本章節由淺入深教您如何將您的DNS設定完成，當您都了解了DNS的原理後，不論是設定UNIX BIND或Windows DNS，都會是相當容易的一件事 從安裝、設定以及資源紀錄的解釋到Zone File帶您一步一步的了解DNS的設定流程，最後教您如何驗證DNS的正確性

21 用 BIND 還是用 Windows DNS ? Windows BIND 操作 效率 穩定性 安全性 佔有率 其他 在台灣兩者相當
GUI的設定方式入門容易 可用 Windows 其他服務結合 ( WINS/AD) 設定以文字編輯進行 入門時,文字工作較易出錯 Unix 環境為一般人所不熟悉 效率 查詢數字無非官方統計資料 每秒可處理上萬次查詢 Multi-thread/SSL 穩定性 視 OS 表現 基本上可符合一般企業需求 穩定性佳 版本更新速度較快 安全性 隨系統版本更新而更新版本 可從設定面加強安全性 較能預防DNS Spoofing 佔有率 在台灣兩者相當 在全世界佔大宗 其他 Root Server 皆以 BIND 為主 Windows之Microsoft DNS Server由舊版之BIND4改版而成，因此有些較新之功能如NAPTR等皆無法支援

22 設定檔: named.conf 路徑 BIND (named) 環境之主要設定檔 作用
/etc/named.conf 或 /usr/local/etc/named.conf BIND (named) 環境之主要設定檔 作用 定義 named 的功能項目 ( options ) 定義 root server 位置 ( zone ) 定義所管轄之網域名稱 ( zone ) 定義反解 ( zone ) 其他，如系統記錄/存取控制列表等… 舊版(BIND4)與新版(BIND8/9)的檔案名稱與格式不同，但BIND8有提供轉換的程式將BIND4的named.boot轉換成named.conf

23 named.conf: options #/etc/named.conf
options { directory "/var/named"; pid-file “/var/named/named.pid”; allow-transfer { /32; /24;}; }; Directory zone file 檔案存放位置 (預設為 /etc) pid-file DNS 啟動時記錄行程代號(PID)之檔案 allow-transfer 轄區傳送之設定，定義那些 IP 可與此部 DNS 做 AXFR (未定義則全開，形同 DNS 資料外流) 常犯錯誤 options 忘了加 “s”，前後以 {} 括住 有關檔案或路徑名稱皆要加 “”　號 每一個描述 (statement) 的結尾需有 “;” 號 有關 IP 等設定項目亦需加 ; 號 pid-file 所指路徑的權限問題要注意 Options 請注意有加 s Named 相關檔案置於 /var/named 目錄下 允許來自 及 ~255的 AXFR 要求 注意: 每個描述要加 ; 號區隔 上例之 /32 或 /24 為 CIDR 表示法， /32 代表 netmask 有 32 bit 為 1，即 ，固代表為一 IP ， /24 為 ， 表示為一個 network， 該 IP (/32) 或該 Network(/24) 皆可以向本機要求 Zone Transfer.

24 在named.conf設定根伺服器 所有的 DNS 伺服器皆需要知道根伺服器位罝 根伺服器為所有 DNS 查詢之起源
zone “.” { type hint; file “named.cache”; }; 所有的 DNS 伺服器皆需要知道根伺服器位罝 根伺服器為所有 DNS 查詢之起源 根伺服器列表可由ftp://ftp.internic.net/domain/named.cache 取得 hint 字面為暗示之意，即向 DNS 表示如果你沒有資料，可以到根伺服器詢問 一部 DNS 僅能有一 hint type 幾年前的中美海灠斷線造成往 . 的線路不通 定義 root dns Server 的檔案， 可由 ftp://ftp.internic.net 取得或執行 . ns > /var/named/named.cache

25 在named.conf設定正解網域 此一域名需上層授權(com.tw) 後別人方可查得到 若您有多個網域名稱即添加類似設定即可
zone “xxx.com.tw” { type master; file “xxx.com.tw.hosts”; allow-transfer { ; ;}; }; 此一域名需上層授權(com.tw) 後別人方可查得到 若您有多個網域名稱即添加類似設定即可 此例為 master 主機設定，slave 主機設定於後述 file 未定路徑即表參照 directory 參數 注意 ; 號問題 此處的 allow-transfer 僅對此網域有效，而options 中的 allow-transfer 則對此部 DNS 有效 Zone 項下可用的選項功能有: allow-notify 表示當此 Zone 被更新時要通知何部 DNS 主機 allow-query 允許那個 IP 來查，預設 any allow-transfer 預設 any allow-update 預設 none check-names 語法較負雜，本處不介紹，參考第二天課程 max-transfer-time-in 要求 Zone Transfer 時，需在多少時間內完成 max-transfer-idle-in Zone Transfer Idle 的時間(秒數) max-transfer-time-out 同上述，秒數值 max-transfer-idle-out Notify Zone File 更新時要不要主動通知 zone-statistics 這個 Zone 的統計要不要做 (default no) statistics-file 統計檔名為何 其他尚有十幾個參數，尤於甚少用到，故本處不再描述

26 在named.conf設定反解網域 DNS 搜尋由後往前(後序)，故原 127.0.0.x 及 211.72.210.x 之 IP 要反寫
zone “ in-addr.apra” { type master; file “named.local”; }; zone “ in-addr.arpa” { file “ rev”; DNS 搜尋由後往前(後序)，故原 x 及 x 之 IP 要反寫 in-addr 為 Internet Address 之意，用於 IPv4 之反解，IPv6 則使用 ip6 apra 為反解起源之 TLD,其他諸如與”數字”有關之解析多以 arpa 為 TLD 乃是系統用的 localhost 所以DNS Server 中必須要加入這個反解 IPv6之反解舊的RFC使用ip6.int，新的RFC已經改為ip6.arpa作為反解的起源，建議使用者設定時兩種都設，因為有些舊版的DNS仍然會到ip6.int去尋找 反解名稱為 IP 反對來寫，您可根據前述之 DNS Tree 結構來看查詢，故要反過來寫，查詢才找得到

27 named.conf 完整內容範例 #/etc/named.conf
options { directory "/var/named"; pid-file “/var/named/named.pid”; # only for slave or none, default is any allow-transfer { /32; /24;}; }; zone “.” { type hint; file “named.cache”; zone “xxx.com.tw” { type master; file “xxx.com.tw.hosts”; allow-transfer { ; ;}; zone “ in-addr，apra” { file “named.local”; zone “ in-addr.arpa” { file “ rev”; 大致分為 Options Root zone Localhost zone 正解 zone 反解 zone

28 named.conf 回顧 options/root server /正解/反解 為基本設定 注意 Zone Transfer 問題
若欲為 Cache-Only 主機則可拿掉 正解/反解設定即可 (即保留 options/root/localhost) 語法及 ; {} “” 等問題需注意 (初學常犯) 可使用工具程式 named-checkconf，named-checkzone 幫您做語法檢查 用法: named-checkconf [ -v ] [ -t directory ] filename named-checkzone [ -d ] [ -j ] [ -q ] [ -v ] [ -c class] zonename filename

29 正解: 什麼是資源記錄 資源記錄(RR， Resource Record) TTL 是此一筆資料被別的 DNS Cache 的時間值
名稱(FQDN) 快取時間 (TTL，Time to Live) 網路類別(class)， 資料類型(type) 答案(rdata) TTL 是此一筆資料被別的 DNS Cache 的時間值 IN 即是 Internet 資料類型分許多種 下列為一筆資源紀錄的內容 TTL與Class是可省略的 FQDN或是RDATA的主機名稱若最後加上‘.’表示為完整的FQDN， 無需再加上該zone的domain name FQDN TTL class type rdata IN A

30 正解:資源記錄範例 xxx.com.tw IN SOA ns1.xxx.com.tw. abelyang.twnic.net.tw. ( ; Serial ; Refresh 12 hours ; Retry 4 hours ; Expire 4 days ; Negative cache 2 hours ) xxx.com.tw IN NS ns1.xxx.com.tw. xxx.com.tw IN NS ns2.xxx.com.tw. ns1.xxxcom.tw IN A ns2.xxx.com.tw IN A ；以下略 常見的TYPE有: A IPv4 Address AAAA，A6 IPv6 Address CNAME 別名 NS Name Server MX mail exchanger PTR Pointer (反解使用) SOA Start of Authority 資源記錄的 TYPE 有許多不同類型

31 SOA RR SOA (Start Of Authority) 記錄用於DNS自身,代表其為權威主機
代替 SOA 記錄 Master 主機名稱 網域管理 用 . 代替 xxx.com.tw 1D IN SOA ns1.xxx.com.tw. abelyang.twnic.net.tw. ( ;serial ;refresh ;retry ;expire ;nagative cache ) TTL = 一天 SOA (Start Of Authority) 記錄用於DNS自身,代表其為權威主機 SOA 提供此一 Zone 之基本資料及更新時間參數供 Slave DNS 更新使用 每一個zone都必需要有 SOA 這個RR ;為註解 ;serial序號，用於 AXFR 時，Master 資料是否變動判斷，修改時至少要將序號加一，讓slave server會至master作同步的動作 43200 ;refresh，請 Slave 主機每隔此一時間向 Master AXFR 14400 ;retry，更新失敗，則每隔此一時間再做 AXFR ;expire，Slave 主機的資料超過此值則放棄此 Zone ;min ttl，在此 refresh + N x retry 小於此一時間內此會 ;做 AXFR，以確保資料的正確性與同步，超過此時間，Slave ;即不會再和 Master 做 AXFR 請求，需重啟 DNS 在 Zone File 符號表示現在這個 Zone 的名稱，故原來 要以 . 代替,若原來 中有 . ，則需以 \. 表示. TTL 一般建議值多為 半天(38400)或一天(86400)，如果您的 DNS 資料很穩定則可設得更高些 SOA 資料中的時間參數在於同步 Master/ Slave 間的 Zone file 資料一致,每次更改了 Zone File 的任何內容，請務必加大序號值，讓 AXFR 能順利進行,相關的時間建議值可參考 RFC 1912 說明

32 NS/A RR xxx.com.tw. IN NS ns1.xxx.com.tw.
ns1.xxx.com.tw. IN A ns2.xxx.com.tw. IN A NS (Name Server) 用於 DNS 的搜尋 每個 Zone File 如 SOA 一般，皆要有 NS RR，且接於 SOA 之後 NS 記錄之 RDATA ，若屬同一個zone以內者需接一 A (Address) RR，以標明其 IP Address 您在TWNIC 的指定內容(DNS 模式)需反應在這個 NS 記錄上,意即上下層的 NS 記錄要一致 NS 記錄說明了那些主機管理此一網域名稱 (權威主機)，需與上層 (如 TWNIC) 的指定一致 NS 記錄之 RDATA 需接一 FQDN 記錄，不可用 IP ，也不可接到一 CNAME 記錄 ( RFC 規範) NS 記錄的取用順序是隨機決定的，而非取用第一筆 A 記錄為指出某一 FQDN 其 IP 為何 NS 記錄對 DNS 解析影響極大,其作用如樹狀結構中之支幹 NS 記錄所指之 IP 不能是 Private/loopbak/multi-cast 等 IP Ex: xxx.com.tw IN NS ns1.yyy.com.tw. xxx.com.tw IN NS ns2.yyy.com.tw. 則不須加 A 紀錄，因為 yyy.com.tw 這個網域根本不屬這個轄區所管， 加了也沒用 FQDN1 IN NS FQDN2 FQDN2 不得直接寫為 IP FQDN2 IN A xxx.xxx.xxx.xxx FQDN2 不得指定為 CNAME (如 FQDN2 IN CNAME FQDN3)，在新版的BIND會造成Error 上述之 “與 TWNIC 指定一致” 說明需熟記，因為不一致會造成許多問題(不致於失敗，但可能浪 Traffic 或時間)

33 CNAME RR CNAME 用於機器別名，如查詢 FTP ，則會查到 WWW 位址
IN A ftp.xxx.com.tw IN CNAME CNAME 用於機器別名，如查詢 FTP ，則會查到 WWW 位址 建議使用 A 記錄來替 CNAME，以避免 NS/MX 等出現問題 CNAME Chain 問題，雖沒有禁止使用，但會導致效率變差甚至錯誤 Yahoo/奇摩/Google/Sina … 為什麼網站都用 CNAME ? NS/MX 避免使用 CNAME 紀錄 (CNAME and OTHERS Error) Ex: xxx.com.tw IN NS ns.xxx.com.tw. ns.xxx.com.tw. IN CNAME IN A 這種東西就應該避免，會造成錯誤 這種東西就叫CNAME Chain， 應避免 aaa.xxx.com.tw. IN CNAME bbb.xxx.com.tw. bbb.xxx.com.tw. IN CNAME ccc.xxx.com.tw. ccc.xxx.com.tw. IN A

34 MX RR MX (Mail eXchange) 記錄為 SMTP 服務所使用，其中的 10，20 表示郵件交換時的優先順序(數字小者優先)
@ IN MX mail @ IN MX imap mail IN A imap IN A ; 此時不可用如 mail IN CNAME www 語法 MX (Mail eXchange) 記錄為 SMTP 服務所使用，其中的 10，20 表示郵件交換時的優先順序(數字小者優先) 亦可使用 A 記錄來代 MX使用 (即 DN=FQDN)，但如此僅能使用一部機器當 Mail Server @ IN A Hotmail/Yahoo 的 MX 有什麼玄機 ? MX紀錄指到一個CNAME紀錄，這是Sendmail使用者最常出現的問題，須特別注意, 不同的 MX 記錄郵件如何同步視 Mail Server 性質而定， Mail Server 必須要作一些調整才能夠配合 MX 的設定請參考 不同的 MX 意義在優先權最高(數字最小)之主機失效時，次之 MX 主機能暫時將 Mail 收下 (是收在 queue 下，而不是收在信箱)，並根據 Mail Server 所定義之重試(Retry) 時間，試著將 Mail 轉至 MX 最小之主機，此為 MX 運作之主要精神所在， MX 做法如下: $ORIGIN xxx.com.tw. @ IN MX 10 mail.xxx.com.tw. @ IN MX 20 redundant.xxx.com.tw. a IN A b IN A 接下來在 mail.xxx.com.tw 機器上面做如下動作﹕ echo “xxx.com.tw” >> /etc/mail/local-host-names echo "mail.xxx.com.tw" >> /etc/mail/local-host-names ;service sendmail restart 再於 redundant.xxx.com.tw 機器上面做如下動作﹕ echo "redundant.xxx.com.tw" >> /etc/mail/local-host-names echo "xxx.com.tw RELAY" >> /etc/mail/access echo "mail.xxx.com.tw RELAY" >> /etc/mail/access makemap hash /etc/mail/access.db < /etc/mail/access ;service sendmail restart 至於像 yahoo.com 或 hotmail.com ， 您使用 dig yahoo.com mx 去查詢時，可發現許多有趣的現象，這個部份則因需要許多系統面的配合，您可以 google 查詢一下相關的做法,或於課堂上交換大家的意見.

35 正解檔完整內容範例 從上述來看是不是又臭又長呢 ?
xxx.com.tw IN SOA ns1.xxx.com.tw. root.xxx.com.tw. ( ; serial 1D ; refresh 1H ; retry 1W ; expiry 2D ; negative cache ) xxx.com.tw IN NS ns1.xxx.com.tw. xxx.com.tw IN NS ns2.xxx.com.tw. Ns1.xxx.com.tw IN A Ns2.xxx.com.tw IN A IN A ftp.xxx.com.tw IN CNAME xxx.com.tw IN MX mail.xxx.com.tw. xxx.com.tw IN MX imap.xxx.com.tw. mail.xxx.com.tw IN A imap.xxx.com.tw IN A wk1.dept1.xxx.com.tw IN A wk2.dept1.xxx.com.tw IN A 記得每個 FQDN 都要有 “.” 結尾,若沒有加的話,有時查詢時出現 xxx.com.tw.com.tw 這樣的東西,即可能是漏了 “.” 從上述來看是不是又臭又長呢 ?

36 以 $TTL/$ORIGIN 來簡化設定 $TTL 86400 ; 預設 TTL 值，原來每筆 RR 之 TTL 值可以此值代替
$ORIGIN xxx.com.tw. ; 預設附加字尾如同該 zone 則可不寫 @ IN SOA ns1 root ( ; serial 1D ; refresh 1H ; retry 1W ; expiry 2D ; negative cache ) IN NS ns1 IN NS ns2 IN MX mail IN MX imap ns1 IN A ns2 IN A www IN A ftp IN CNAME www mail IN A imap IN A $ORIGIN dept1.xxx.com.tw. ws IN A ws IN A $TTL 要放在最上面，若 RR 沒有設 TTL 值，代表使用 $TTL 的值 $ORIGIN 符號來代表該網域管理上也較為清楚，容易換名字

37 子網域的分割 上述例子 dept1 要自建一 Sub-domain，以管理自己部門之 DNS 資料，需以 NS 記錄再授權出去
;在 xxx.com.tw. 的 Zone File 內 $ORIGIN xxx.com.tw. IN NS ns1 IN NS ns2 ns IN A ns IN A $ORIGIN dept1.xxx.com.tw. ns IN A ns IN A 上述例子 dept1 要自建一 Sub-domain，以管理自己部門之 DNS 資料，需以 NS 記錄再授權出去 原在上頁 Zone File 中的 ws1/ws2 等資料應從 xxx.com.tw. 中移除，避免 DNS 混淆 於 ns1.dept1.xxx.com.tw 及 ns2 上再建立 dept1.xxx.com.tw. 的 Zone File，並做好 Master/Slave 之區分 可參考實例 相當於 ; $ORIGIN xxx.com.tw. IN NS ns1 IN NS ns2 Ns1 IN A Ns2 IN A Dept1 IN NS ns1.dept1 IN NS ns2.dept1 ns1.depe IN A ns2.depe IN A

38 Master/Slave 如何實現 ns1.xxx.com.tw ns2.xxx.com.tw
#/etc/named.conf #其他略 zone “xxx.com.tw” { type master; file “xxx.com.tw.hosts”; allow-transfer { /32; }; #/etc/named.conf #其他略 zone “xxx.com.tw” { type slave; masters { ;}; file “xxx.com.tw.hosts”; allow-transfer {none;}; }; 一般而言 Slave 主機應不允許 zone transfer Slave 主機啟動後即會和 Master 同步資料，而後資料的同步即是參考 SOA 資訊 Master 主機更改了資料請務必記得序號需加大，否則即使時間到了 Slave 不會同步資料 在新版的BIND中可設定 notify 的功能讓 master 在有資料異動時主動通知 slave 來更新資料，其通知對象主要根據該 Zone 內之 NS 主機，因為不是該 Zone 之 NS 主機並沒有意義，有時我們為了建立備援的DNS 主機，則會使用 also-notify IP 來特別做不宣告的 NS. Master 應只允許 slave來作zone transfer 容易出錯的部分:Slave 主機設定和 Master 設定稍有不同注意 masters 中的 s

39 Master/Slave 的同步問題 Zone transfer 只有一個方向，由 Slave 向 Master 發出要求
如果 Master 更改了資料，以上述 Zone File 的範例而言，最長要一天後 Slave 才會更新，顯然不夠即時 解決方法 降低 Refresh 之值：或可改善但仍會有時間差 使用 Bind 8.x/9.x 之 notify 功能 當 Master 重新啟動時，即會送出 notify 訊息至所有 Zone File 中的 NS RR，告知這些機器進行 AXFR 這個功能在 Bind 9.x 中預設即巳啟動，若欲關閉 options { …. notify no; }; TTL 對 DNS Server的穩定之間有很大的關聯 AXFR 即 Zone Transfer TTL 值越大表示越不會有變動，若有需要更動 DNS 資料時，建議可以先將 TTL 值改小，以減少修改時資料不同步的時間差，穩定之後再將 TTL 值改回來

40 反解: 域名設定 Zone “210.72.211.in-addr.arpa” { type master;
file “ rev”; }; 反解依然有 master/slave 主機之分，與正解同理 上例為一 Class C 反解，若為 Class B 則可寫成 in-addr.arpa. 若不滿一個 Class C，設定方法較特別，請參考 反解的zone仍必需有SOA及NS紀錄 DNS也是一樣有分master和slave

41 反解: Zone File 內容範例 反解之 Zone File 內容與正解類似
$TTL 86400 $ORIGIN in-addr.apra. IN SOA ns1.xxx.com.tw. Root.xxx.com.tw. ( ; 86400; 3600; 864000; 2D; ) IN NS ns1.xxx.com.tw. IN NS ns2.xxx.com.tw. 1 IN PTR ns1.xxx.com.tw. 2 IN PTR ns2.xxx.com.tw. 3 IN PTR pc3.xxx.com.tw. ; 以下類推….. 對於一些應用程式(如某些mail server)會檢查正反解是否一致， 若不一致可能會被拒絕連線 反解之 Zone File 內容與正解類似 反解之 TYPE 為 PTR ( Pointer)，指出這個 IP 對應什麼名稱 建議正反解最好一致

42 反解: 利用 $GENERATE 變數簡化 上述例子可以 BIND 9.X 之 $GENERATE 功能表示為:
;前 SOA 及 NS RR 略 1 IN PTR pc1.xxx.com.tw. 2 IN PTR pc2.xxx.com.tw. 3 IN PTR pc3.xxx.com.tw. … 31 IN PTR pc31.xxx.com.tw. 上述例子可以 BIND 9.X 之 $GENERATE 功能表示為: $GENERATE $ PTR pc$.xxx.com.tw. ; $ 即表 1-31，將會自動展開成 31 行的 PTR ; BIND 9.X 省略 IN (Class) 不寫 $GENERATE 亦可用於正解部分，語法相同 $GENERATE 就像是一個迴圈變數，但無法使用巢狀迴圈，通常用於反解或有規則的主機名稱，以簡化設定

43 負載平衡功能 (Round Robin) 如上資料，一個 FQDN 有兩個以上之 IP 位址是允許的
www IN A www IN A pc IN A pc IN A 如上資料，一個 FQDN 有兩個以上之 IP 位址是允許的 回答的答案基本上是循環的，不過在 BIND 9.X 中是以有些回答的依據設定 (rrset)，不過一般是較少用到 DNS 僅做名稱之負載平衡，如 www/mail 或他類型的服務之負載平衡要取決其他技術(ex: Level 4 switch) 對於相同名稱而有多筆資料時BIND預設是採用round robin的方式提供答案，因為client端通常都會採用第一筆資料先作連線因此可達到負載平衡的目的 RRset Ordering( Resource Record Set Ordering) Fixed: 固定順序 Random: 亂數 Cyclic: 輪詢(round-robin)

44 named 之及啟動與停止 基本上只要執行 named 即可啟動 DNS
$>named 或 named –u named (#視安裝方法而定) $>/etc/rc.d/init.d/named start named 啟動狀況會寫到 syslog (/var/log/messages) 中，只要查看log 檔即知啟動狀況 為了方便了解其執行狀況，可以讓 named 於前景執行 要停止 named ，可直接 kill 掉其行程即可 $>killall -9 named 或 $>kill -9 pid-file 或 $>/etc/rc.d/init.d/named stop 在BIND8和BIND9分別有NDC及RNDC這兩個程式以控制BIND的執行及其他動作，可試在以 rndc 指令了解其參數意義，在設定 rndc 時，要先在 named.conf 中設定 key， key 的產生與設定如下: etc]# rndc-confgen # Start of rndc.conf 設定一 rndc.conf ，建議與 named.conf 同一目錄 key "rndc-key" { algorithm hmac-md5; secret "lnWw5u3Jlr/8jaTpjfWF6w=="; }; options { default-key "rndc-key"; default-server ; default-port 953; #在 named.conf 中加入如下設定 controls { inet port 953 allow { ; } keys { "rndc-key"; }; 在啟動 DNS 後，即可使用 rndc 來檢測系統(輸入 rndc 會顯示參數) 一般來說， named 在啟動時是以背景方式進行，所有啟動時所發生的正確或錯誤訊息會寫入 syslog 內 (一般即指 /var/log/messages)，此時則需查看 syslog 的訊息來了解是否正確的啟動 DNS. 另一方面，也可以前景執行方式來進行檢驗，若一切無誤後再以正常的方式啟動即可. 前景執行: BIND 8: named –f –c /etc/named.conf BIND 9: named –g –c /etc/named.conf

45 Windows DNS：設定 以下範例僅以 Windows 2000 Advance Server 為例
Ｗindows DNS 位於 控制台->服務->系統管理工具->DNS 此二項目作用相同，在於設定 DN 之 Master/Slave 及正反解檔 即 SOA 中的 Expire 時間 即以手動方式清除過期(TTL 時間巳到)之 RR 所有的 Slave 設定做 AXFR 動作 Windows DNS設定與 BIND 類似 但相對簡單的多 若有設定BIND經驗的使用者必能駕經就熟 清除所有快取資料而不論其 TTL是否巳到

46 Windows DNS： Master/Slave 及正解/反解
正向對應：正解 反向對應：反解 先選擇 DNS Server 型態 標準主要區域(Master)或標準次要區域(Slave) 再選擇正向對應(正解)或反向對應(反解)

47 Ｗindows DNS: 新增一個標準主要區域-正解
將設定寫回檔案 將 Zone File 重新載入到視窗 即 A RR，可一併建立 PTR 資料 CNAME MX DN 下再加一層，如 dept1 (同一 Zone) 即 NS，建立 Subdomain 再授權出去 其他不常用 即反解，如您巳了解 Windows DNS 的正解的設功能，這個項目應可迎刃而解 若要新增各種資源紀錄，請於該網域上按右鍵進行新增 此處非常重要而常為人所忘…..見下頁

48 Ｗindows DNS: 網域的”內容”項目
這一個畫面是一般的 Windows DNS 管理者常常忽略之處 一般：項目中有一 “是否允許動態更新”，主要為 Windows 的特定需求而設 SOA: 這個畫面之值多要改，依據 RFC 1912 多不有不符合之處 名稱伺服器：需在此加上自身的名稱及 IP 及 Slave 主機資料 動態更新主要在配合DHCP的環境下 Windows 能直接將電腦名稱更新至 Windows DNS Server 但Server端與Client 端都需作些許的設定 由於預設的轄區傳送是全部開啟的，許多使用者並沒有注意此一部分 區域轉送：即 Zone Transfer，預設為全開，建議選擇第二項，僅允許您其他的 NS ，並勾選通知(Notify)功能

49 檢測工具: nslookup/dig nslookup dig UNIX 及 Windows 平台皆有 可使用命令模式與交談模式
較好用但資訊較簡略 dig 僅有命令模式 較不好用但資訊完整 nslookup [-option ...] [host-to-find | -[server]] # dig -h Usage: dig [domain] [q-type] [q-class] {q-opt} {global-d-opt} host {local-d-opt} [ host {local-d-opt} [...]] Where: domain are in the Domain Name System q-class is one of (in，hs，ch，...) [default: in] q-type is one of (a，any，mx，ns，soa，hinfo，axfr，txt，...) [default:a] (Use ixfr=version for type ixfr)

50 檢測及追蹤方式介紹 $TTL 86400 @ IN SOA ns1 root ( 2002021301 ; serial
1D ; refresh 1H ; retry 1W ; expiry 2D ; min ttl ) $ORIGIN xxx.com.tw. IN NS ns1 IN NS ns2 IN MX mail IN MX imap Ns1 IN A Ns2 IN A www IN A www IN A ftp IN CNAME www Mail IN A Imap IN A 此處將測試資料全貌貼上，以利後續查詢步驟解釋

51 以nslookup追蹤(1) [root@pc071 named]# nslookup
Default Server: ns1.xxx.com.tw Address: > set q=soa > xxx.com.tw. Server: pc071.twnic.net.tw Address: xxx.com.tw origin = ns1.xxx.com.tw mail addr = root.xxx.com.tw serial = refresh = (1D) retry = 3600 (1H) expire = (1W) minimum ttl = (2D) 啟動 nslookup 交談模式 連線至　nameserver 設定查詢類別為 SOA 資訊 查 xxx.com.tw. 如 Zone 所列之內容(SOA 訊息) nslookup之操作說明如下: set 設定某些值: debug N: 以 debug level N 來查詢， N 值欲大訊息會愈多. 此時會看到許多查詢時 所產生的訊息， 如查 ， 會列出其查詢的過程， 有關 其所產生的訊息分成五大部份， HEADER， QUESTIONS ， ANSWER， AUTHORITY RECORDS ， ADDITIONAL RECORDS ， 這 五大部份也就是一般 DNS 封包的格式， HEADER 段內說明了下面每一 段有幾節…欲知詳情， 請參考 RFC1034，1035 nodebug: 關閉 debug N 的設定. querytype=N: 查詢的類別， N 預設為 A 記錄， 您也可以使用較簡單的表示 法， 如 q=ns 或 q=ptr 等描述 class=IN 目前唯一可以使用預設值 timeout=N 每次查詢的 timeout 時間設為 N 秒， 第一次失敗會將上一次的值 X 2， 如 N=5 ，逾時時間則分為 5，10，20，40 retry=N 逾時後重查的嘗試設為 N 次， 若 N=4 即如上結果 server NS 切換使用的DNS 伺服器為 NS， 在切換過去時會以現在的 NS 來查詢對 方的 IP ls –a DN [ >FILE] 列出所有的 A 和 CNAME 記錄[ 到 什麼檔案] ls 即 AXFR(轄區傳送) ， 若您沒有設定 allow-transfer 則每個人都可以操作 ls 指令

52 以nslookup追蹤(2) ;續前頁 xxx.com.tw nameserver = ns1.xxx.com.tw xxx.com.tw nameserver = ns2.xxx.com.tw ns1.xxx.com.tw internet address = ns2.xxx.com.tw internet address = set q=soa 之功能，除 SOA 外，您尚可設定其他 TYPE (如 NS，A，MX，CNAME，PTR …等不同記錄)，以查到您想要的資訊 命令模式 (等同與上例) nslookup –q=soa xxx.com.tw. nslookup [-option ...] [host-to-find | -[server]]

53 以nslookup追蹤(3) [root@pc071 named]# nslookup
Default Server: ns1.xxx.com.tw Address: > server dns.hinet.net Default Server: dns.hinet.net Address: > set q=ns > hinet.net Server: dns.hinet.net ;以下結果略 >ls –d hinet.net [dns.hinet.net] *** Can't list domain hinet.net.: Unspecified error >server ns1.xxx.com.tw. >ls –d xxx.com.tw. ;以下會列出 xxx.com.tw. 的 Zone File 內容 以 dns.hinet.net 做為 DNS Server 設定查詢 NS 記錄 對 dns.hinet.net 要求 ls (list) –d(domain) 資料 (即 AXFR)，結果當然被拒ls –d 之指令不適用於BIND 9環境 (省略部份訊息)，切回 ns1 並做 AXFR，若允許 Client IP 做 AXFR 則會列出 Zone File 內容 假如您使用“除錯模式”的話，看到的資料還將更多﹗

54 以nslookup追蹤(4) >set q=a >www.xxx.com.tw. Server: ns1.xxx.com.tw
Address: Name: Addresses: ， > Non-authoritative answer: Name: Addresses: ， ， ， ， ， 查詢 個 IP，即是此記錄做 Round Robin， 再查一次可能是相同順序，亦可能 81 會排到前面，如果您在看此網站，有 時可能會連到 80，但有時又會連到 81，即可達到負載平衡之效果 查詢外面的網域名稱可以查的到，代 表root server的設定正常 Non-authoritative answer 表示為非權威資 料，意即是 Cache 而來 Server 會一次回應所查詢網域全部的 IP，Client 會依序使用，所以可以達到負載平衡之目的，但在 Windows 2000 以上的版本查詢，因為 Window 2000 會做 Cache (非 DNS 的 Cache，而是 2000 自己 Cache . 要避免這種狀況，可將服務中的 [DNS Client] 這一項關閉即可，實際案例可參考

55 以dig追蹤(1) [root@pc071 named]# dig @211.72.211.1 xxx.com.tw ns
; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY， status: NOERROR， id: 6 ;; flags: qr aa rd ra; QUERY: 1， ANSWER: 2， AUTHORITY: 0， ADDITIONAL: 2 ;; QUERY SECTION: ;; xxx.com.tw， type = NS， class = IN ;; ANSWER SECTION: xxx.com.tw D IN NS ns2.xxx.com.tw. xxx.com.tw D IN NS ns1.xxx.com.tw. ;; ADDITIONAL SECTION: ns2.xxx.com.tw D IN A ns1.xxx.com.tw D IN A dig ] [ -b address ] [ -c class ] [ -f file- name ] [ -k filename ] [ -p port# ] [ -t type ] [ -x addr ] [ -y name:key ] [ name ] [ type ] [ class ] [ queryopt... ] 此處可見 dig 顯示的資訊多了許多，一般我們常用 $>dig FQDN_or_Domain TYPE 來查詢 DNS 的資料， 這時候的 dig 所查的主機是使用 reslover 中所定義的 DNS 伺服器 若我們要臨時要自訂一個 DNS Server 則可使用 FQDN_or_Domain TYPE 來查詢，其作用就如在 nslookup 中指定 server 一般

56 Additional Records Section(32)
以dig追蹤(2) 命令格式為 domain type 由上頁可看出 dig 較 nslookup 複雜許多 其列出許多 DNS 封包的欄位資訊，可參考 RFC 1034/1035 或 Oreilly “DNS & BIND” 一書之介紹 DNS封包格式 Query Identifier(16) QR OPCodes Flags Reserved RCodes QDCount(16) ANCount(16) NSCount(16) ARCount(16) Question Section(32) Answer Section(32) Authority Section(32) Additional Records Section(32) DNS 的封包格式 QID DNS 查詢封包編號，作為確認依據. QR 查詢封包為 0 ﹔回應為 1 .長度為 1 bit . OPCodes 封包類別(QUERY， IQUERY， STATUS， Reserved).長度為 4 bits. Flags 共 4 bits ，各表示：AA(Authoritative Answer)、TC(Truncation)、RD(Recursion Desired)、RA(Recursion Avalable). Reserved 保留未用. RCodes 回應訊息，長 4 bits ，除 0 及 6-15 保留未用外，1-5 分別為：Format Error、Server Failure、Name Error、Not Implemented、Refused. Question Section、Answer Section、Authority Section、Additional Records Section 每一 Section 分為 NAME、TYPE、CLASS 三個子欄位，分別作為查詢、應答、授權、額外記錄等封包之資訊，及各自長度.

57 DNS Running ? 如何確定 DNS 是否運行呢 ? DNS 不正常原因: Port Scan 目標 53/UDP (敏感動作)
telnet 53 port nslookup –q=ns . Dns_server (查詢其 Root 記錄) . Ns DNS 不正常原因: 語法錯誤造成 DNS 未啟動 觀念錯誤造成運作不正常 網路是否正常 (流量，斷線…) 是否被 Router/Firewall 等檔掉了 53 port 被入侵或欺騙 判別密碼被猜出或離職員工惡意或其他非故意而被人為的改變了 DNS 的指向 是不是 TWNIC 的關係造成解析上的問題 版本差異與認知上之問題 上述為DNS Trouble Shooting 該注意的部分，若發生問題可以檢視是否發生上述狀況

58 DNS安全相關設定

59 DNS 各種問題之探討與觀念介紹 TTL 設定對網路的影響 兩部以上 DNS 之作用 Resolver query 的行為探討
BIND8/BIND9 的差異性 Lame Server 為什麼 SERVFAIL 中國大陸對 DNS 做了什麼 此部份主要探討一些重點觀念的釐清，及一些常碰到的問題

60 TTL 設定對網路的影響 TTL Time To Live， 他人DNS 快取了你的域名的某筆資料時，將在他的機器上暫存多久讓他人於查詢同一筆資料時可快速回應(這個值是由自己指定) 當 TTL 為 0 時，表示 RR 不為他部 DNS 主機所快取，不過就實際層面而言較少人會如此設定 當要更改 DNS 內容或公司網路變動時，預先縮小 TTL 值是必要的，可以縮短整體網路的更新時間 DNS 預設每小時檢查一次所有快取資料是否過期 下圖為 一個月之查詢量在不同 TTL 值上的變化，我們可以看出，只要設定了 TTL 值，即會減輕 DNS 查詢對網路的負載 圖為 的查詢量分析，當 TTL 定為 0時 每天有將近六百萬次的查詢，TTL改為6時卻降到約八十萬次，隨著TTL值的降低 查詢次數亦更著降低.故如動態 DNS 之設定 TTL 不為 0，設在 20 秒內則可以取得一個較佳的平衡.

61 兩部以上 DNS 之作用 根據 InterNIC 的規定，NIC 之 DNS 指定應兩部以上 兩部 NS 之意義在於 容錯 系統安全
負載平衡 若您設定了兩部以上的 DNS 主機，當有人連接您的網站前，其查詢乃是兩台主機輪流運作(輪詢，Round-Robin).在這樣的運作機制下讓您的系統可以更穩定 In a Men & Mice's February 2001 survey of 6000 randomly-selected .com domains， 38% of tested zones had all their DNS servers in one subnet， and only 9.9% maintained a single functioning DNS server. ( TWNIC 於2002年的調查中:所有.tw的網域，只有一部DNS Server佔了15.34%， 所有DNS Server 在同一個網段的佔了13.11%

62 Resolver query 的行為探討 DNS 預設查詢逾時為 5 秒 預設每次逾時時間加倍，嘗試３次 (5,10,20)
依據 /etc/resolv.conf 中設定的 nameserver 數量(最多不可以超過３，系統巳定義) 一台 nameserver, timeout 總長為 =35 秒 二台 nameserver, timeout 總長為 5*2+(10/2)*2+(20/2)*2=40秒 三台 nameserver, timeout 總長為 5*3+(10/3)*3+(20/3)*3=42秒 上述除數僅取整數,Ex: 10/3*3=9 Nameserver 選擇以 n1,n2,n3 為序，皆逾時後以新 timeout 時間再進行一次 調整 timeout 與 retry 於 /etc/resolv.conf 設定 Options timeout:3 attempts:2 意即只試二次，每個３秒，以上述例子看一台，二台，三台分別最大 time out 為 9,12,15 秒 應用程式可以改變上述之總總行為 Default Domain/Search 作用 所查詢的名稱不含點(.) 時會啟用 resolver 的 domain/search 功能，有的作業系統會查不到時就加(windows)，有的作業系統會一開始時加(Sun) 主要在於不同的 OS 預設稍有不同 如果域名為 tw.com.tw 或 tw.net.tw 會造成過多的問題,若其又使用 wildcard (*) 更會影響網域名稱的正常使用 因此查詢可能會拖延到 =15秒 才會出現找不到

63 DNS 不安全之後果 (1) 為何會不安全 可能的後果 被入侵: 可能從別的服務程式或直接從 DNS 入侵
若使用 BIND 建議您昇級至 以後之版本 可能的後果 DNS 失常 這是最常見的情況，使用者會感覺到 DNS 失去作用.此時除了重新啟動，還需去了解為什麼 DNS 會失效. 假造網頁 原來的 www 位於 ，但被改到 ，而其又 mirror 您的網頁，此時很容易套出您使用者的身份與密碼，而又不易被察覺(因為使用者輸入的是 )(即一般俗稱 man in the middle 手法) 根據目前已知的DNS版本漏洞資訊，可以歸納出幾種攻擊的模式： 　1. Buffer overflow：即緩衝區溢位的攻擊，藉由傳送特定的shell codes，可能會讓攻擊者取得named執行時的權限或是root權限，執行惡意的指令.甚至在被入侵的主機開啟一個remote login shell，即所謂的後門，以方便下次的入侵.例如在2000年4月間流傳的lion worm即是. 　2. Crash server：藉由傳送不正常的訊息，導致named處理時產生錯誤crash掉. 　3. Denial of Service：藉由傳送不正常的封包或是因為系統管理者錯誤的設定，導致伺服器無法提供正常的服務，即阻斷服務攻擊(DoS attack)的發生.和crash server不同的是，這種攻擊模式並未造成伺服器當機，只是忙於處理『不正常的』requests. 　4. Information leak：即洩漏伺服器資訊的攻擊方式.有心人士可以得知系統相關資訊，並擬定下一波的攻擊行動.

64 DNS 不安全之後果 (2) 可能的後果 複製郵件
所有的信件到達你的服務器之前可以被拷貝，修改或者刪除.入侵者只要了解郵件伺服器與 DNS 的運作原理輕易即可達成此一目的，而其也可以偽造成您的信件寄出，這些都是可以透過 DNS 完成，而您不會感覺到很明顯的異常.其手法同上一段所述 授權問題 某些與信任有關服務 (如 mail，firewall，proxy等等) 若涉及DNS域名信任時將會無效.如您的防火牆信任 any.com.tw 網域可自由通過，在 DNS 被入侵後防火牆將完全失效.因為入侵者可在您的 DNS 中潻加他機器為 any.com.tw 網域機器的資訊 系統權限 當駭客從 DNS 入侵後(指遠端溢位攻擊，remote buffer overflow ) ，通常亦直接取得 DNS 權限 建議: 以最小的權限執行 DNS Server 如果可能的狀況DNS Server上不要提供其他服務 隱藏版本資訊並注意 Access Control 如果是 BIND DNS 可以使用 chroot 的方式來增加安全性，chroot 做法可參考 升級至最新版本的DNS Server 安全性相關問題請參考:

65 BIND8/BIND9 的差異性 BIND 9 只相信權威主機的資料(aa=1)
有人在 twnic 指定設定 DNS 模式，主機分別為 www/mail 但實際未在該 IP架設 DNS Server 使用 BIND9 信件將寄不到 使用 BIND8，因 BIND8 只要有資料就會相信，所以信件仍可寄達 最多人用，而其使用 BIND8，所以造成許多人誤解用 hinet 就可以，別家有的就不能寄

66 Lame Server Lame Server 成因
DNS 並無管理該網域名稱(即非權威主機)，卻將 DNS 的 NS 記錄指向了該部 DNS 很多人將在 TWNIC 的 DNS 指定,設向了 或其他僅提供大眾查詢與解析網域名稱之DNS 主機（Cache Server）,但是此類主機並無管理該網域名稱 DNS 管理該網域名稱,但是 NS 記錄列表裏並沒有該 DNS 的名稱或不一致  domain.com.tw 在 TWNIC 的 DNS 指定為 ns1 及 ns2 , 但自己的 DNS 卻將 NS設為 ns3/ns4　等，或與上層不一致之主機名稱。 避免 LAME Server 最大的要求即在上層與下層的 DNS 設定完全一致,並且所有的DNS 主機都能正常工作，如此方是一個上下層完整的授權關係

67 為什麼 SERVFAIL SERVFAIL 意即 Server Fail ，主要的成因為:
在查詢端接收到超過 64K 的 DNS TCP 回應時，將判定為 Server Fail (DNS 使用基本的 udp 53 port 只能回應 512 bytes,TCP 最高可至 64K) 該 DNS 主機可接受遞迴查詢,但是又沒有 Root dns (.) 的設定,造成遞迴查詢上的失敗時,也會產生 Server Fail 之情形。 名稱伺服器雖有設立該網域名稱,但是載入或狀態不正確(SOA/NS 必需正確): Zone 過期,主要因為 slave 主機到達了 expire 時間仍未更新所造成。 Zone 載入時發生錯誤,主要因為 Zone File 有語法或語意上的錯誤,造成該網網域名稱稱實際上並未載入 DNS 中。 網域的 NS 記錄的不可以接 CNAME 記錄，否則亦會造成 Server Fail。 Zone 錯誤,不正確的 SOA 或 NS 資訊,也會造成 Server Fail。 名稱伺服器所設立的 CLASS(IN,CH,HS) 與查詢之 CLASS 不相符。 當 Server Fail 發生時，通常為設定上之問題，主要好發於第３點所描述狀況(其他情況亦有可能但較不常見)，若您有此情形，請檢查您的 DNS 啟動記錄中所發生的錯誤訊息，適當修正後即可避免此一情形。

68 中國大陸對 DNS 做了什麼 管制言論，中國Internet 進/出口的內容上進行了過濾
寄/收信常會 timeout,一段時間連不上 有些網站連不到 Search 後得到一個特定頁或無結果回應 在某些網頁跑出警語 重點期間(開會/十一國慶) 狀況會較嚴重 往外查詢 DNS時，對於特定 Query 內容進行阻檔，回應假的 IP 或說找不到 直接檔掉國外一些 DNS Server 或 Domain Name Ex: Internet Freedom DNS 查詢從外往內連時，也會經過過濾處理 發生任何你在他國都不會發生，只在大陸發生的狀況都不足為奇 使用 VPN 方式是最佳解法，專線雖貴但至少有一定保障，也可以找像 Frees/WAN (net to net) 或 pptpd 之類的進行連線時的加密，只要經過出口時資料是加密的就檔不到 DNS Query 往台灣或其他國外送

69 DNS安全相關設定 (1) 如何建講一個安全的 DNS Server DNS Server 要更新
8.4.3/9.2.2 以後版本目前是”安全”的 Windows 平台基本上隨 hot fix 或 Service Pack 而更新 兩部以上的 DNS Server 並實體適當分離 容錯考量 避免線路或實體上造成解析問題 區分可 Recursive 對象 架設兩部以上外的可供內部使用的 resolver 主機 或使用 BIND view 的架構，區分內外網查詢處理的差別 內網可 Recursive 查詢，外網則禁止以避免欺騙問題

70 DNS安全相關設定 (2) 區分內外網可 recursive 對象,善用 bind9 的 view (服務位於內網， NAT port mapping) acl “Lan” { /24; ;}; acl “public” { !Lan;}; options { directory “/var/named”; allow-transfer {none;}; }; view “intranet” { match-clients {Lan;}; recursion yes; zone "." { type hint; file "named.root"; }; zone “xxx.com.tw" { type master; file “xxx-intranet.com.tw"; }; }; view “internet” { match-clients {!Lan;}; recursion no; zone “xxx.com.tw" { type master; file “xxx-internet.com.tw"; };

71 DNS安全相關設定 (3) 如何建講一個安全的 DNS Server 以 firewall 適當過濾不相關之協議或服務請求
限制轄區傳送 (default any) 限制動態更新 (default none)，若一定要開需注意 Access Control 以非 root 啟動 named chroot/SElinux 視能力及狀況使用

72 存取控制　（１） acl=Access Control List , 通常 ACL 宣告要放在 named.conf 的最前面，以免發生未宣告之類的錯誤 除了用 firewall 之外，BIND 也可以對許多 DNS 行為做管控 acl “acl_name” 可接 IP/netmask (or CIDR),none ,any

73 存取控制　（２） 先宣告後使用 #同時間 recursive 最大數量 recursive-clients integer; # 可不可以接受 recursive,單純的 yes (default) or no recursion yes_or_no; # 設定最大的 Cache 時間，避免特長的 cache 出現 max-cache-ttl integer; # 允許 recursive 來源 IP,這些 IP 外就是不允許 allow-recursion {address_match_element; …}; # 允許查詢的 IP 段，設在 options 中代表全部有效 allow-query { address_match_element; ... }; # 同上用意，用於 update allow-update { address_match_element; ... }; # 同上用意，用於 Zone transfer allow-transfer { address_match_element; ... }; # Client IP 符合條件．．用於 view match-clients { address_match_element; ... }; acl “internal” { 1,2,3,4; /24; / ; 13.14/15; }; 或負面表列 Acl “external”{!internal;}; 檢測您的 DNS,建議您修正所有紅字，尤其 open server 該項，這是避免 Spoof 重要的問題

74 存取控制 （3） 只允許特定來源遞迴查詢 acl internal { 192.168.4.0/24; }; options {
存取控制　（3） 只允許特定來源遞迴查詢 acl internal { /24; }; options { allow-recursion { internal; }; use-id-pool yes; # 其他設定 }; zone "." { type hint; file "named.root"; }; zone “xxx.com.tw" { type master; file “xxx-internet.com.tw"; };

75 負載平衡 - NS 多個 NS 用意即在負載平衡及容錯考量 NS 間以 Zone transfer 達到資料同步作用
com.tw IN NS ns2.cuhk.edu.hk. com.tw IN NS a.twnic.net.tw. com.tw IN NS b.twnic.net.tw. com.tw IN NS c.twnic.net.tw. com.tw IN NS d.twnic.net.tw. com.tw IN NS e.twnic.net.tw.

76 負載平衡 - NS 實例中的 SLD 查詢流量(2007/03/03)
基本上每台主機的負載是均等的,但易受到外部頻寬限制影響,故有臨時性的波動 DNS 流量 (如左圖週六時間)常有臨時性的大量查詢,但時間不長 下右圖新增兩部 SLD 主機後可看出流量再次被平均分配了 SLD DNS 新增兩部主機

77 負載平衡 - A 多個 A 記錄常用於 Web 的分流使用 Web 的資料同步不是 DNS 管的 A 記錄回應可用 view 來控制結果
Hinet User 訪問到 Hinet 線路上的 User 其他 User 訪問到固定某一台 Server 內網訪問到內部的，外網訪問到外部的 中國大陸網通和中國電信間存在嚴重的 peering 問題，所以需要南方訪問到南方，北對北 台灣較無此問題,故跨 ISP 間的訪問對 User 而言並無障礙 使用 view 需要有足夠的 IP 分布資料，可以在 apnic 的 ftp 上找到(ftp.apnic.net)

78 負載平衡 – A + CNAME 著名的公司 www.akamai.com 以 DNS View + 反向代理技術聞名
rrd]# dig +short # 以上為向 twnic.net.tw 查詢之結果 rrd]# dig +short # 以上為向厦门 查詢所得之結果

79 負載平衡 – A + CNAME Cache 廠商宣稱離使用者最近的 Server 是不可能的，只是在 DNS Query 時，給予距離使用者 DNS 最近的答案 Cache 業者的 A 記錄時間皆很短，以避免 DNS Cache 過久，影響其更新速度(記錄改變的速度) 反向代理與一般代理的差別在於反向代理是把網站 A 記錄指到 Proxy 上 (不是設在 Broswer) Proxy 必需知道後台真正的 Web 在哪裏，所以可能另有一個對照表 IP (可能是 private dns 或 hosts )

80 負載平衡 – A + CNAME Google 自有一套算法，但取最近的 Web Site 仍是以 view 中的答案為主
SINA/百度.. 都是 A+CNAME View+反向代理 有時 CNAME 會超過一次 CNAME 用意在於把一筆記錄交給 Caching 業者管理，由業者給出 A 記錄

81 負載平衡 - MX 多 MX 用意本在當 best MX 無法傳送時，將信件傳送到次之的 MX 等待 best MX 復原後 relay 信件回到 best MX SMTP 傳送信件時，先 Query MX 若無則改 Query A 部份 antispam 方案要求必要有 MX 否則信件無法傳遞是較不符合 RFC 規定的 若多個 MX 下又多個 A，查詢原則是先選 MX 再選 MX 內的某一個 A 記錄

82 負載平衡 - MX SMTP 在使用 MX 時，相同的優先權只使用一次 若有多筆 A 記錄亦使用一次，所以
Yahoo: 信件在 mx1~mx3 (各有 4,4,7 個 IP)間循環,信件送到 mx1~mx3 的機率是相同的，但 mx3 有7 部,故每一部實收信件量會較低 Yahoo: 信件在 mx1~mx3 只要一連接失敗,發信端 SMTP Server 改送 mx4,由 mx4 再 relay 回 mx1~mx3 間任一部,如果mx4 再失敗則 queue 在發信端 Hotmail: MX 優先權皆相同,皆為 4 IP,所以送到任一部機會是相等的 Hotmail: 信件不能傳送時,會留在發信端的 Server 上,因為其沒有次之的 MX yahoo.com mx (註:此二列表常改變,可能與您目前查詢到的略有不同) 1 mx1.mail 1 mx2.mail 1 mx3.mail 5 mx4.mail hotmail.com mx 5 mx 5 mx 5 mx 5 mx

83 負載平衡 - MX MX 的優先權代表信件的投送順序,有時會為 spam/virus filter 所使用，真實的收件是次之的 MX
有些 spam 會直接寄往次之的 MX，此時將真正的信箱主機放在 filter 之後並僅接受 filter 的來信會較好(若不考慮成本問題) 非在表列的 MX 內，而是MX 10 將 filter 後的結果後送的主機，其需僅接受來自 MX 10 對 smtp 的連接 MX 10, filter MX 20, backup

84 DNS系統記錄解讀 ns_forw: query(mail.vinwell.com.tw.vinwell.com.tw) All possible A RR's lame 說明這個網域名稱可能有 Lame Server 狀況，也有可能是查詢人之 Resolver 之default-domain 之功能所引起的 /etc/named.conf:53: syntax error near '}' 語法錯誤，通常是少了 ; 號或忘了 {} 號，可使用 named-checkconf 檢查看看 unrelated additional info 'Manager.aluba.com.tw' type A from [ ].53 說明從 送來了和他無關的資料，通常發生的原因可能是該部 DNS 的一些域名設定有誤，但也有可能是 DNS 欺騙的一種狀況 bad referral (in-addr.arpa !< in-addr.arpa) from [ ].53 Bad Referral 狀況，可以從訊息中看到 (HINET)的反解設為”in-addr.arpa.”，可能原因是其 IP 太多，故如此偷懶，這樣的設定會造成此人往後的一段時間內($TTL) 查詢任何反解資料時都會到此 IP 查 ns_forw:query(BBS\.NNUT\.EDU\.TW\000.nhu.edu.tw) forwarding loop (dns.nhu.edu.tw: ) learnt (A= :NS= ) 查詢 bbs.nnut.edu.tw. 時發現有迴圈狀況，通常是 CNAME 所造成的，同時並記住管理nhu.edu.tw. 的上層主機為 (也就是這一次是使用這一部)

85 DNS系統記錄解讀 Response from unexpected source ([ ].53) for query "_ldap._tcp.tmt.gtmt.com.tw IN SOA" 查詢 _ldap 主機時，意外的從 168 的主機回應答案,其主要原因是 HINET 使用 Layer4 Switch，故回應的 IP 可能不固定所致，但亦有可能是 DNS Spoofing Cleaned cache of 1083 Rrsets 這是 named 清楚 Cache 的 log，表示有 1083 筆 TTL 時間到了 rcvd NOTIFY(tw, IN, SOA) from [ ].45599 從 將到一個轄區變更的通知 (notify) Sent NOTIFY for "tw IN SOA " (tw);4 NS, 4 A 同上，但是送出，可見送出時所帶參數，2001 為序號 sysquery: findns error (SERVFAIL) on pc071.twnic.net.tw? 這一部 DNS 發生錯誤造成 伺服器失敗,通常的原因是 SOA,NS 或是 Zone file 載入時有錯所造成 sysquery: query(mail.digi-age.com.tw) NS points to CNAME (lnx5.net-chinese.com.tw:) learnt (CNAME= :NS= ) 查詢 mail.digi 時，發現它的 NS RR 接的是一個 CNAME RR，這樣的 NS 是不被承認的 db_load could not open: /var/named/hosts:No such file or directory zone 的設定中指定的 file 位置找不到檔案 send AXFR query 0 to 這部機器向 作一 AXFR 請求，這個請求送的序號為 0 (這是因為手動使用 named-xfer 所產生的訊息)

86 DNS系統記錄解讀 slave zone "tw" (IN) loaded (serial 2001021959)
這部機器完成了”tw” 的 AXFR 請求，並將其載入 check_hints: no A records for E.ROOT-SERVERS.TW class 1 in hints 找不到 Root Server 中 E.ROOT 之 Class，也就是 named.ca 中沒有設定 IN stream_getlen([ ].42873): Connection timed out 和 的連線逾時 denied update from [ ].3633 for "." 拒絶來自 要求動態更新 . 的位置 xn--abc.tw has multiple CNAMES 這個名稱 CNAME 多次到不同的名稱(系統預設是 no,若真的要用需 multiple-cname yes ) Zone "" (file named.ca): No default TTL ($TTL<value>) set, using SOA minimum instead named.ca 沒有定TTL 值，使用 SOA 中的 TTL 代替 a.dns.tw IN A differing ttls: correct a.dns.tw 的 TTL 值與上層設定不同，調整之,BIND9 才會有,以下層資料為準 /var/named/abel.hosts.utf8: WARNING SOA refresh value is less than 2 * retry (2 < * 2) SOA 中的 refresh 的值小於 retry 值的二倍，建議您可達十倍左右

87 DNS系統記錄解讀 sysquery: findns error (NXDOMAIN) on ipopc-16.ipoware.ocm.tw? 找不到 這個網域名稱 (NXDOMAIN) Malformed response from [ ].53 (out of data in final pass) DNS 回應的封包格式不對 deleting interface [ ].53 這個網路介面 shutdown 了(bind 預設每小時會檢查 interface 狀況) There may be a name server already running on [ ].53 named 巳經在執行中了 invalid RR type 'NS' in additional section (name = 'auth.com') from [ ].53 194 的回答中，additional section 資訊中的 NS 資料不對，可能有設錯的狀況或 Spoofing log_open_stream: open(/var/log/named/dns-statistics.log) failed: Permission denied 開啟系統記錄檔時，權限不足,需注意 named run-time 時的 uid 和檔案(目錄)權限是否相符 cannot set resource limit on this system 無法設定這台機器的系統設定，如最大檔案開啟數，最大行程數．．．主因通常是權限不足 db.movie:16: data "hp.com" outside zone "com.tw" (ignored) hp.com 這個名稱不屬於 com.tw 這個 zone 之下

88 DNS系統記錄解讀 zone “tw” (class 1) SOA serial# (1) rcvd from [ ] is < ours ( ) 轄區傳送 ”tw”時發現 的序號小於現在的序號, 這會造成不傳的狀況. 每次更改 zone file 時要記得同時至少為 serial 加上 1, 這是一個基本的原則 Err/TO getting serial# for "edu.tw" secondary zone "edu.tw" expired slave 無法取得轄區資料,當到達了 SOA 的 expire 值時則會產生第二行的訊息內容, 表示 edu.tw 的轄區資料巳經過期了, 當再遇到有人來查 twnic.edu.tw 時則會產生 SERVFAIL 的系統訊息.會造成這樣的訊息可能的原因可能為: master 與 slave 間的網路連線有問題, slave 主機所指定的 master ip 有誤, master 沒有開 allow-transfer 或其 zone file 中的語法有誤 can't change directory to /var/named: No such file or directory 找不到 /var/named 這個目錄．這通常是因 options 中 directory 所指定的路徑不存在或打錯字 : master zone "movie.edu" (IN) rejected due to errors (serial ) Zone file 中語法或格式錯誤造成整個 Zone 不用 (BIND8 訊息, BIND9 仍可用,但可能出現 SERVFAIL 狀況) socket(SOCK_RAW): Too many open files 系統開啟的檔案數過多，造成 named 無法再開啟檔案或 socket gethostby*.getanswer: asked for " in-addr.arpa IN PTR" , got type "CNAME" gethostby*.getanswer: asked for " in-addr.arpa", got "37.32/ in-addr.arpa" 找 的反解時，發現其指到一 CNAME，通常這種狀況較少見，是小於一個 Class C 中常用反解的指定方法，所以其要再問 37.32/ in-addr.arpa 的結果 ns_udp checksums NOT turned on: exiting OS 中的 udp checksum 功能未打開，DNS 無法運作

89 DNS系統記錄解讀 can't fdopen tmpfile (sec_qip/db.135.156.HfeOrP)
DNS 在做轄區傳送時會在 directory 所指令的目錄下產生一個 temp file,若此時權限不對，即會出現此類訊息 couldn't create pid file 無法建立 PID file (process id)，權限問題 setsockopt(REUSEADDR): Operation not supported on socket 作業系統不支援 setsockopt 中某些參數(REUSEADDR) CNAME and other data (invalid) 一個巳是 CNAME rr 的記錄不能再用於其他記錄 $GENERATE unknown type: $i dyn.tw GENERATE 的語法錯誤，type 不對或是忘了加了 host name "t_terrall.dev.oclc.org" (owner " in-addr.arpa") IN (primary) is invalid - proceeding anyway FQDN 名稱不合法,不能有底線([A-Za-z0-9,-]) no SOA found for fs.dedip.oclc.org, SOA query got rcode 3, aa 1, ancount 0, aucount 1 雖是權威主機(aa=1)查無 SOA 記錄 (rcode 3 = NXDOMAIN, an=ANSWER , au=AUTHORITY NOTIMP 未實作 (Not Implemented ) NSTATS A=86974 NS=2 CNAME=59 SOA=6 MG=5 PTR=17610 HINFO=141 MX=5631 TXT=6 AAAA=138 LOC=2 MAILB=5 ANY=2066 BIND 8 特有，說明從何時至何時(UTC time) A 記錄查詢了 次…

90 DNS系統記錄解讀 ns_resp: query( in-addr.arpa) A RR negative cache entry (NS0.NAP.NET:) 因為負面答案快取，巳知其不存在 ns_resp: query( in-addr.arpa) Bogus LOOPBACK A RR (localhost.geosrv.com: ) 查詢 NS 記錄時，指向了 ，這個 IP 是有問題的 (Bogus) ns_resp: query( Glue A RR missing (ns1.def.com:) 沒有對應的 A 記錄(外部的域名) ns_resp: query( / in-addr.arpa) No possible A RRs 沒有對應的 A 記錄(自己的域名) ns_resp: TCP truncated: " in-addr.arpa" IN PTR from [ ].53 DNS 回應封包太大，改用 tcp 方式查詢 (超過 512 要 truncate 或使用 edns) "rr.com IN MX" points to a CNAME (mail.rr.com) MX/CNAME 不能混用 sysquery: query(ring.kotel.co.kr) NS points to CNAME (daiduk.kaist.ac.kr:) NS/CNAME 不能混用 [[ ].13172] transfer refused from [ ], zone psk.net 拒絕 對 .21 要求 zone transfer （psk.net) 的請求 (allow-transfer 沒有它) unapproved AXFR from [ ] for "riptor.com" 同上意，不同的版本字面稍有不同,’unapproved’ 有的版本會改稱 ‘deny’, 而 AXFR 因情況不同，可能是查詢(query),遞迴(recursive),或更新(update)等

91 DNS安全進階應用與實例探討 關閉非自己 client 的 recursive 網域名稱判別密碼應妥善保管
正面範例 : abc.com aol.com cnn.com … 負面範例: ncc.tw tsmc.com.tw 網域名稱判別密碼應妥善保管 業務人離職交接後應變更判別密碼 專屬業務人員，勿使人人皆知 pchome.com.tw 權責清楚 使用 BIND9 會比 BIND8 在查詢上嚴謹 留意 DNS 相關的系統漏洞或問題 避免或少用 ，主要其太多人用常有 timeout 情況發生

92 DNS安全進階應用與實例探討 開啟 query/security log 記錄查詢及安全方面相關訊息 網路有調整即檢視 acl 是否仍適當
版本隱藏 (options { version “abc”;};) 開啟 use-id-pool yes，增加 query id (2bytes) 的隨機性，且記錄 qid 與 IP 間的關係，以避免 spoof (會增加系統資源的使用) 可考慮 chroot 環境，以減少入侵後的風險 可參考去年講義

93 動態更新相關問題 bind 8 後支援動態更新 bind 動態更新可以只認 IP 或是使用 key 認 IP 簡單而實用
  動態更新相關問題 bind 8 後支援動態更新 bind 動態更新可以只認 IP 或是使用 key 認 IP 簡單而實用 認 key 需使用 tsig　（此教材不特別說明) Google with “bind nsupdate tsig” nsupdate 後會在 directory 產生日誌檔 (.jnl) nsupdate 後日誌檔用於 zone transfer,及稽核使用 nsupdate 會直接對 zone file 進行內容修改,及對巳載入 run-time 資料一併修改,以維持其一致性

94 動態更新相關問題 兩個 DNS Server, nsupdate 兩部 ? Bind 8 與 Bind9 間的動態更新支援情形
只需要 update master 即可 nsupdate 不需要處理 SOA serial 值 ,系統會自動加1 zone transfer 增量區域傳送 (IXFR,incremental zone transfer )的資料同步全部 DNS (只傳改變的部份) Bind 8 與 Bind9 間的動態更新支援情形 前版本只能傳全部(AXFR) 後版本可支援傳部份(IXFR)

95 動態更新相關問題 – 架構示意圖 用程式將 DB 的 record 轉成 Bind 認識的 zone file notify notify
DNS Server 固定時間讀取 Transaction Log 做成 nsupdate 產生日誌檔 options { directory "/var/named"; pid-file "/var/run/named/named.pid"; allow-transfer { sip1;sip2;sip3;bip1;bip2;bip3;}; also-notify { bip1;bip2;bip3;}; #備用主機 provide-ixfr yes; request-ixfr yes; recursion no; }; zone "tw" { type master; file "tw"; allow-update { ;}; also-notify zone "tw" { type slave; file "twnic.tw"; masters {master_ip;}; };

96 動態更新相關問題 –參數意義 acl “hotsite-dns”{ seednet_ip;hinet_ip;tanet_ip;hk_ip;}; acl “real-dns” { ; ; ;}; #acl 分別宣告兩個 ACL 用於區分服務性質及備援主機 options { directory "/var/named"; pid-file "/var/run/named/named.pid"; allow-transfer {real-dns; hostsite-dns;}; # zone transfer 要對兩個 ACL 全開 allow-notify { hotsite-dns;}; # also-notify 意在通知備份主機也要同步 recursion no; # 不接受遞迴,您可自依情況改用 allow-recursion provide-ixfr yes; # 差異化 transfer out request-ixfr yes; # 差異化 transfer in max-journal-size 1m; # nsupdate 記錄檔只留 1M size transfer-format many-answers; # zone transfer 以多個記錄一起傳,可以加快速度 };

97 動態更新相關問題–nsupdate command
> server localhost #設定要更新的 Server >zone twnic.tw #更新那個 zone file >update delete 1.twnic.tw A #刪除 1.twnic.tw 的 A 記錄 >update delete 255.twnic.tw. A #刪除255.twnic.tw 的 A 記錄 >update add 255.twnic.tw 8888 A #加一筆 ttl=8888 的 A 記錄 >show #顯示目前nsupdate 情形 Outgoing update query: ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: ;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0 ;; UPDATE SECTION: 1.twnic.tw ANY A 255.twnic.tw ANY A 255.twnic.tw IN A >send #送出更新指令(未送不會生效) >quit 註: 可以把上述指令寫在文字檔中,以 nsupdate Filename 一次處理完,nsupdate 若封包大於 512 bytes,則屬 truncate 模式,會改以 53/tcp 傳送此一 update 請求

98 動態更新相關問題 如果您只是給 windows client 做一般的動態更新,開啟 allow-update {您的網段;};
如果您是 dhcp + nsupdate 由 dhcpd 來做 update 動作會有較高的安全性,可參考 如果您是 DNS 相關廠商,使用 IXFR 能有效節省更新時間 Verisign rapid DNS update (.com) 每15秒更新 zone file 一次 (> 筆域名資料) dyndns.org,noip.com 都是60 秒內的更新 TWNIC 計畫今年內推出 30 秒內更新方案，目前仍在測試階段(預設的 NS 記錄 TTL 不會降低) 降低此值會增加上層的負擔

99 動態更新相關問題 – 動態 DNS dyndns.org/no-ip.com TWNIC dyndns
以 client 向其 Web Server 發送資訊 (hostname,id,passwd) 等必要資訊 Web Server 處理出其真實IP (因可能經過NAT 或 Proxy)後轉換成 nsupdate 指令結構 執行 nsupdate 更新其 bind 相關 RR 資訊(ttl=60) TWNIC dyndns TWNIC 自行開發 client/server 環境 後台結合各家 Registrar 以確認密碼正確性 不使用 nsupdate,而以資料庫操作 提供 client source code 供 Vendor 移植

100 動態更新相關問題 – 動態 DNS DB 化的動態 DNS 那種好 ? 如何從外部判斷其方法
主要使用 mydns (perl) /PowerDNS (C++) 從網頁接收資訊後直接操作資料庫( dns query 時直接 select 資料庫或從快取抓取資料 那種好 ? 查詢效率: Bind 顯然比 DB 快 安全性: Bind 相對承受壓力查詢較高(>10000 vs ~1000) 彈性: DB 性質的可變性高,前端易結合其他服務 管理: DB 化是較易管理,額外負擔較小, BIND 則需另有後台處理這類事情 如何從外部判斷其方法 SOA serial 變化, bind 會遞增, DB 則不用動 (DB 自有同步化機制 以 dns fingerprint 軟體測試 (fpdns) 其 nameserver, 可知其大概版本及平台 (具風險性)

101 動態更新相關問題 – 動態 DNS DB 模式 BIND 模式 HTTP Request HTTP Request
檢查 hostname,id,passwd 及抓取 Client IP 檢查 hostname,id,passwd 及抓取 Client IP 資訊寫入 DB 資訊寫入 DB 輸出 nsupdate 至 master DB DNS 資料同步 Master 通常隱藏在後 DNS query 時 select DB 求取 Answer Slave 向 master 同步 DNS Service DNS Service

102 大型網路DNS安全架構探討 可自行建立 Local-Root 提供內部完全的解析
不用現有的 named.ca 而是自己建立 Root server 只要一個叫 “.” 的 zone file 例如中美海覽斷線事件 善用 also-notify 做好備援主機隨時保持在最新資料狀態 為方便管理，可考慮以 DB 產生 zone file 方式進行 DNS 更新

103 利用DNS提升網路容錯能力 分布 DNS 在不同線路或實體機房，避免 SPOF (Single Point of Failure ) 情況發生 DNS round robin MX/A 記錄，以避免服務完全中斷 可適當利用動態更新技巧，對發生故障主機進行 Record 修改 預先寫好介面可事半功倍

104 案例探討 有一單位 (xxx.com.tw. )遭受來自網路上的 DNS Query 的 DDOS 攻，造成其 T1 的頻寬完全塞滿，每秒查詢萬次以上，無數的主機皆向其詢問， xxx.com.tw. AAAA 的內容，但該網域名稱並無 AAAA 之 Record， 請問如何解決 ? ( TTL 及 Cache 因素) 某人在 TWNIC 指定其 xxx.com.tw. 之 DNS Server 如下面內容: mail.xxx.com.tw xxx.com.tw 而其本身並沒有在這兩個 IP 上架設 DNS Server (有 MailServer)， 請問別人以 寄信給他時， 收得到嗎 ? 為什麼 ? (版本差異) VeriSign 在 .com .net 的 gTLD 上加了 $ORIGIN com. * IN A 請問，對 Internet 各種服務會有什麼影響 ? (綜合觀念，telnet /smtp/www …)

105 案例探討 上層 DNS 中 .tw 及 .com.tw 的 DNS 查詢量那一個較多 ? 為什麼 ? (TTL 及架構因素)
依據 ISC 及 CERT/CC 組織的說明，建議使用 BIND 運行 DNS 的人，為了安全的理由，最好都換到 BIND 9.X 版，為什麼像 HINET/SEEDNET 這些 ISP 都不願意換呢 ? (版本差異) 有一個網域名稱叫 tw.com.tw ， 為什麼他的查詢是高達每小時數萬次 ? 管理人員覺得很困擾，用 Fire Wall 將 DNS query 給檔下來又會發生什麼事 ? (Resolver 的 default domain/search 及 loop 問題)

106 DNS 其他的應用 SPF (Sender Policy Framework) Domain Key 的應用 ENUM 網路釣魚的問題
RBL 其他

107 SPF SPF 全名為 Sender Policy Framework
主要使用 dns 的 TXT 記錄說明這個網域的發信 source 有哪些 SPF 目前巳是標準 RFC 4408 可以使用精靈幫您產生 SPF 資料 這個資料要放到自己的 zone file 中 如果是代管則代管業者需提供 TXT 記錄

108 SPF 運作原理 Sender 寄信給 Recipient 收件人郵件主機收到信後檢查 Sender 的 Doamin 的 SPF 記錄
==> 查詢 twnic.net.tw TXT 記錄 如果來源的發信 IP 不在 SPF 的記錄中,則退信,若有則接收

109 SPF TXT 記錄說明 DNS 中本即有 TXT 記錄,用於 “說明” 事項
TXT 記錄只是一個 string, 自由格式,SPF 則直接使用此 TXT 做為應用 ip4|ip6:address 說明信來源 IPv4|IPv6,可使用 CIDR 表示法 a|mx|ptr:FQDN 來源可能為 A|MX 記錄的 IP include:Domain 說明這個來源包含了這個 Domain 的 SPF 記錄 redirect:FQDN 轉向以該域名做為 SPF 檢查

110 SPF 的行為 (action) 定義 網路上的例子 + Pass - Fail ~ SoftFail ? Neutral
Google.com “v=spf1 ptr ?all” 反解是 google.com 的,其他不表示意見 gmail.com "v=spf1 redirect=_spf.google.com“ 請改向 _spf.google.com 查詢 (使用這個功能要注意 loop 問題) _spf.google.com "v=spf1 ip4: /23 ip4: /19 ip4: /20 ip4: /18 ?all“ 這些 ipv4 位址是 gmail 的來源,其他不表示意見 (中立) Hotmail.com “v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all” 包含了這幾個名稱(spf-a.hotmail.com ..)的 SPF 記錄,同理, include 也要注意 Loop Sina.com "v=spf1 include:spf.sinamail.sina.com.cn -all“ 包含 spf.sinamail.sina.com.cn 的相關記錄,其他都不是我的

111 SPF 檢查過程 (同意連接) other.com twnic.net.tw 5 mx5.other.com.
連線到 other.com (擇最佳的 MX ) 220 other.com Other.com 回應連接訊息 ehlo twnic.net.tw Twnic 送出 ehlo/helo 訊息 250-SIZE (信件最大 size) 250-8BITMIME (本文允許 8bit 250 ENHANCEDSTATUSCODES (加強型的回應訊息) Other.com 回應250- extensions 訊息 twnic.net.tw 的主機發出一封 的信件到 gmail Mail from: IN TXT “v=spf1 ip4: /23 ip4: /26 ip4: /28 ip4: /27 a ptr include:twnic.tw –all” 註: 這個動作可能在收下來整封信以後才做,也可能在連接階段(如此處)就做 Other.com 檢查twnic.net.tw type=TXT 記錄 DNS 回應查詢結果 Other.com 回應 OK Other.com 回應 OK”

112 SPF 檢查過程 (拒絕連接) other.com Spam.com 5 mx5.other.com. 10 mx10.other.com.
ehlo twnic.net.tw spam 送出 ehlo/helo 訊息 250-SIZE (信件最大 size) 250-8BITMIME (本文允許 8bit 250 ENHANCEDSTATUSCODES (加強型的回應訊息) Other.com 回應250- extensions 訊息 spam 的主機發出一封 的信件到 gmail (他假冒身份) Mail from: Other.com 檢查twnic.net.tw type=TXT 記錄 IN TXT …略 DNS 回應查詢結果 Other.com 回應 Please see Other.com 回應 拒絕 訊息

113 SPF 檢查過程 (進來後才檢查) other.com Spam.com 5 mx5.other.com.
連線到 other.com (擇最佳的 MX ) 220 other.com Other.com 回應連接訊息 ehlo twnic.net.tw Twnic 送出 ehlo/helo 訊息 250-SIZE (信件最大 size) 250-8BITMIME (本文允許 8bit 250 ENHANCEDSTATUSCODES (加強型的回應訊息) Other.com 回應250- extensions 訊息 twnic.net.tw 的主機發出一封 的信件到 gmail Mail from: Other.com 檢查twnic.net.tw type=TXT 記錄 IN TXT …略 DNS 回應查詢結果 Other.com 回應 Please see Other.com 回應 拒絕 訊息

114 SPF + SpamAssassin (1) SPF 也可以將信收進來後再開始檢查,通常一般都使用 SA 來進行驗證
或以 perl -MCPAN -e “install Mail::SpamAssassin” 來安裝 SA 加載 SPF 功能 檢查目前 SA 是否支援 SPF #/etc/mail/spamassassin/init.pre # 設定檔是否載入 Plugin loadplugin Mail::SpamAssassin::Plugin::SPF # 檢查 Perl Modules 中是否包含了 SPF 必要的一些模組 (cmd line),若無錯誤訊息即表丕巳安裝這兩個 modules $>perl -e‘require Mail::SpamAssassin::Plugin::SPF’ $>perl -e ‘require Mail::SPF::Query’ 若無則使用 CPAN ( 安裝該模組 $>perl -MCPAN -e ‘install Mail::SpamAssassin::Plugin::SPF;install Mail::SPF’ # 此法能解決 Perl 模組之相依性問題,若您未用過則在初次使用時會有一些必要的詢問與設定動作

115 SPF + Spamassassin (2) SA 中 SPF 相關的設定 (/usr/share/spamassassin)
25_spf.cf 定義不同的狀況的檢查函式及描述 50_scores.cf 定義分數,內容很長,可找到有關 SPF 的項目 60_whitelist_spf.cf header SPF_PASS eval:check_for_spf_pass() # 檢測能否通過 SPF PASS 檢查 describe SPF_PASS SPF: sender matches SPF record # 這個項目的描述 tflags SPF_PASS net nice userconf # 分數定義的方式 # 我們省略了這個檔中的大多數內容,實際請根據您的系統及版本來看會較好 # 在此提醒,SA 版本低於 可能存在被 DOS 的風險 ( score SPF_PASS # 通過 SPF 檢查給予 分,因許多 Spamer 也曉得要建立 SPF 記錄 score USER_IN_SPF_WHITELIST #如果是 SPF_PASS 的白名單,那就真的是白名單而不是假的 sender header USER_IN_SPF_WHITELIST eval:check_for_spf_whitelist_from() # 此檔下半部定義了 SPF WL describe USER_IN_SPF_WHITELIST From: address is in the user's SPF white list tflags USER_IN_SPF_WHITELIST userconf nice noautolearn net # 不需自動學習

116 SPF + Postfix (1) Postfix : Postfix >2.3 可以使用 Sendmail 的 Milter 功能 (2.2 之前的使用 libspf2 本處不多做介紹) 安裝 sid-milter (支援 SPF) # 要讓 Postfix 支援 Milter 要先裝 sendmail 的 Milter (使用 8.13.X 版本 milter) $>wget ftp://ftp.sendmail.org/pub/sendmail/sendmail tar.gz # 取得 sendmail tarball 檔 $>tar -zxvf sendmail tar.gz # 解壓 $>cd sendmail /libmilter # 進入對應目錄 $>make ; make install # 編譯及安裝 milter 函式庫 # 取得 sid-milter $>wget # 依 進行幾行程式的修改 $>tar -zxvf sid-milter tar.gz # 解壓 $>cd sid-milter # 進行該目錄 $>make;make install # 編譯及安裝 sid-milter $>/usr/bin/sid-filter -a /etc/postfix/milter/peerlist -l -p -h

117 SPF + Postfix (2) 續前頁 sid-milter 參數說明 (僅列較重要的)
添加自己 Domain 的 SPF (TXT) 記錄 修改 mail.cf 重啟 postfix 後即可生效 sid-milter 參數說明 (僅列較重要的) smtpd_milters = inet: :3332 # IP:Port, 需配合 sid-milter 中的 -p 參數 -a peerlist list of hosts to ignore # 那些來源忽略,通常指自己的主機及用戶 IP,可以是 FQDN,DN,IP,CIDR -A auto-restart # sid-milter 若失常自動重新啟動 -D softfail DNS errors # 查詢該域名發生錯誤時以 softfail (~) 看待 -d domlist domains to always pass # 那些 DN 不檢查,通常指外部 -h prepend identifying header# 在 Header 中添加 SPF 檢查訊息 Ex: # Received-SPF: pass (google.com: domain of # designates as permitted sender) -M text rejection message # 拒絕連接時的訊息內容 -q quarantine instead of rejecting # 以隔離代替拒絕 -t test-only mode # test only, 不熟悉時建議使用 -T secs DNS timeout # DNS 查詢逾時時間 -u userid change to specified userid # run time 時的 user id -

118 SPF + Sendmail (1) 做法同前兩頁說明,但不需進行任何程式修改 sid-milter 本來就是做給 sendmail 用的
sendmail 必需支援 Milter,多數的 Linux 版本預設即巳支援 若不支援,因做法較複雜請參考下列連結第二節之說明 $> sendmail -d0 </dev/null # 檢測自己目前使用的版本支援情形 Version Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETUNIX NEWDB PIPELINING SASLv2 SCANF STARTTLS TCPWRAPPERS USERDB XDEBUG

119 SPF + Sendmail (2) 續前頁 Sendmail 的其他方案 補充: 何謂 MILTER (Mail fILTER)
接著您就可以多加測試了 (我們的介紹可能太簡短,有賴有興趣的朋友多加實驗) Sendmail 的其他方案 Milter-SPF 主要以 Perl 來進行 SPF 驗證 Smf-spf 主要以 C 來進行 SPF 驗證,需函式庫 libspf2 Mimedefang 主要以 C 來 hook perl 程式進行認證,同時可以搭 配 Spamassassin 及 Virus scan 等諸多功能 補充: 何謂 MILTER (Mail fILTER) Sendmail 為開放第三方 (third-party) 使用的一種方案,讓每個 SMTP 協商階段都可以呼叫一個以上的外部程式進行驗證或調整部份郵件表頭,以達到最佳的開放性 $>vi /etc/mail/sendmail.mc # 前略 # 在 MAILER 前加入 INPUT_MAIL_FILTER(`sid-filter', # 後略 $> m4 /etc/mail/sendmail.nc > /etc/mail/sendmail.cf $> service sendmail restart

120 SPF 工具程式 在前面的介紹中,安裝了 Perl Module 中的 Mail::SPF::Query 時,亦會安裝一個工具程式 spfquery twnic.net.tw 的 SPF 內容 使用 spfquery 來測試結果 $>dig twnic.net.tw txt +short # +short 表示只要最短的結果值 "v=spf1 ip4: /23 ip4: /26 ip4: /28 ip4: /27 a ptr include:twnic.tw -all" $>spfquery spfquery --mail-from|-m < -address>|<domain> --helo|-h <hostname> # Sender,helo 主機名稱 --ip|-i <ip-address> [OPTIONS] # IP 位址 spfquery --helo|-h <hostname> --ip|-i <ip-address> [OPTIONS] # 或是以主機名稱及 IP 來測 $>spfquery -m -h twnic.net.tw -i # 查此一比對結果 Fail # 因為我們是使用 -all Please see # 訊息較長,主要是 link 到spf網站說明資訊 domain of does not designate as permitted sender Received-SPF: fail (spfquery: domain of does not designate as permitted sender) client-ip= ; helo=log.twnic.net.tw; # SPF 標準的 header 表示 $>spfquery -h twnic.net.tw -i # 是 twnic 宣告的發信 IP Pass # 符合,所以 pass Please see …略,同上 Received-SPF: pass (spfquery: domain of designates as permitted sender) client-ip= ; envelope-from=; helo=twnic.net.tw; # spf 檢查結果為 pass,及其相關訊息

121 SPF .tw 目前 SPF 設定情形 我們以 twnic 目前所管理之 DNS 資料抽樣 各主要類別 SLD 1000 筆以計算設定情形,不足1000筆者則以全部檢測 SLD 檢測筆數 有 SPF 記錄 edu.tw net.tw com.tw gov.tw

122 SPF 的問題 Spammer 也可以建立 SPF 來規避 SPF check,這個問題也存在 Domain Key 中
MTA 可以拒絕這個 Domain 的來信,造假的 Envelope Sender 其 IP 無法符合 SPF Check 多數的 Domain 都沒有設 SPF , 這個需要時間多加推廣 (SPF 去年4月方成為標準) 自己的 DNS 要記得設定 SPF 記錄,但不一定需要在 MTA 實作去檢查來信的 SPF 記錄,以免錯失必要的信件 SPF 需注意處 ISP 所提供 Relay 主機之問題 因為 Sender 還是自己,但 IP 為 ISP 的主機 Mailing-List / Aliases / Forward / 退信 時 (同上理) 使用 Mailman / Majordomo 等可避免此一問題 郵件若有使用 Virtual domain,可善用 include 或 redirect 統合 SPF 相對於 DK 較簡單易懂,本質疏途同歸

123 Domain Key DK 目前仍不是 RFC 標準,細節爭議仍不少,故本處我們僅介紹原理,不涉及實作介紹
主要是由 Yahoo 所提出之一套 認證方式以確保發信人或 Domain 之真實性 Sender 將自己 Domain 的 Public Key 置入 DNS zone file 中 (TXT) 發出去的信件使用自己的 Private Key 對必要欄位(或內文)進行簽章動作 收件端由 dns 查詢取得 Public Key 進行還原確認 依結果再決定處理行為

124 DKIM 近況 DKIM 在過去一年來巳陸續通過了三篇 RFC 目前 DKIM相關之標準巳經確立
RFC 4686 Analysis of Threats Motivating DomainKeys Identified Mail RFC 4871 DomainKeys Identified Mail (DKIM) Signatures RFC 5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol 目前 DKIM相關之標準巳經確立 根據 TWNIC 以 Domain Name 查 _domainkey.DN 目前台灣約有700個域名有此相關記錄

125 DK 範例 (1) 經過 twnic.net.tw 郵件主機 Signing 後產生如右之結果
DKIM-Signature: a=rsa-sha256; s=brisbane; d=twnic.net.tw; c=simple; q=dns/txt; h=Received : From : To : Subject : Date : Message-ID; bh=jpltwNFTq83Bkjt/Y2ekyqr/+i296daNkFZSdaz8VCY=; b=bnUoMBPJ5wBigyZxLWJATkSkb9Ig+8OAu3cE2x/er+B; Received: from pc133.twnic.net.tw [ ] by twnic.net.tw with submit.cf; Fri, 9 March :00: (CST) TWNIC 客服寄出一封回應給 User 的信件 From: To: Customer Subject: Problem fixed ? Date:Fri, 9 March :00: (CST) Message-ID: Good Luck ! TWNIC. From: To: Customer Subject: Problem fixed ? Date: Fri, 9 March :00: (CST) Message-ID: Good Luck ! TWNIC. 經過 twnic.net.tw 郵件主機 Signing 後產生如右之結果 Received 欄位是傳送記錄 (Trace Field),為原來 SMTP 的範疇,和 DK 無關 Mail Header 是由最上開始往上加,所以多個 Received 代表經過了多次轉送 由於 b= 和 bh= 內容較長,我們去掉了部份簽章內容

126 DK 郵件表頭 欄位解釋 DKIM-Signature: a=rsa-sha256; s=brisbane;
Selector 名稱 DKIM 識別欄位名稱,這個是 Sign 的欄位 Canon 類別 所使用的簽章演算法 DKIM-Signature: a=rsa-sha256; s=brisbane; d=twnic.net.tw;c=simple; q=dns/txt h=Received : From : To : Subject : Date : Message-ID; bh=jpltwqr/+i296daNkFZSdaz8VCY=; b=bnUoMBPb9Ig+8OAu3cE2x/er+B; Domain Sender 對那些Header 的簽章,如列, DKIM 建議至少要包含 From Body 的簽章結果,若含有 l=n 表示 Body 的前幾個 Bytes,以避免信件過大的消耗 Header Value 的簽章結果這個結果會受到 Canon 影響,且不包含 Header 的名稱,Ex: From DomainKey-Status: pass pass: verify 成功 no sig: 沒有 DKIM-Signatur miss: 沒有 b= 的值 dns : dns 查詢方面的錯誤 Int: internal error , 內部方面的錯誤 針對不同的狀況 verify 端可以決定自己的採取對策: Accept Discard Reject Tempfail

127 DK 欄位說明 在 DK 草案的 Section 5 中提到每個 DKIM-Signature 欄位 (tag)的意義
a= 演算法,為 rsa-sha256/rsa-sha1 h= 取用那些表頭欄位進行簽章,建議至少要含 From b= 取用 h= 表頭的簽章結果 bh= 本文的簽章結果 l= 取用本文的長度 c= (canonicalization ),以 訊息標準化的方法,有 simple 和 relaxed, header/body 分別為什麼標準化方法,Ex: c=simple/simple (見後述) d= 網或名稱 s= selector , 使用的 domain key 頭 selector._domankey.DN v= 版本,目前為 0.5 q=dns/txt (目前為固定此值),表示查 DNS 的 TXT 記錄 t= signature time , 為 1970/1/1 後的 UTC 秒數 x=signature expiration, 簽章的有效期間 詳細的說明可以參閱 Working Group (DKIM) 上之說明

128 DK 何謂訊息的標準化 主要因為表頭訊息可能有一行內放不下之情形, 可能存在 ‘縮排 (folding)’ 情形(可以是 TAB 或是一個以上的空白),實際上 folding 的訊息是該欄位名稱全部的值 標準化動作主要統一訊息的取用方法,兩種方法 Simple: 欄位及 folding 皆保留 (就是原封不動) Relaxed: 進行欄位的 unfolding ,將多行併成一欄,多行需補空白 舊版原名 nofws,但意思是一樣的 <TAB> <TAB> Folding 經過 relaxed 處理後的結果, 冒號左右的空白需去掉/欄位名稱轉成小寫/unfolding 成一行/去掉行未的空白字元 (<TAB> 表示 ascii 9 的 tab, <SP> 表示空白字完)

129 DK 建立 DNS 記錄 (1) 以 _domainkey.DN 形成 TXT 解析條件
產生 rsa 的 public/private key Key 的長度不要超過 2048 bits 以避免 DNS 封包長度 512 bytes 的限制 $>openssl genrsa -out rsa.private # 建立 private key $>openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM # public key # public key 內容 -----BEGIN PUBLIC KEY----- MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhALUlcpnslrckb3GVOBxrkUiwXs PfA8Xpd/tU31B/MxXcSI4nSzRGWrBrlXiSBYfSyXLM8rX3iyDnwXZh5++E6Cn+ 8+OXiX6Vtxk8otrcN9BSUC3YyNag0XVUFW3B4kF/1wIDAQAB -----END PUBLIC KEY----- # 去掉那些 --- 的行,接成一行放到 DNS 的 zone file 中 (一行) _domainkey.twnic.tw IN TXT "k=rsa; t=y; p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhALUlcpnslrckb3GVOBxrkUiwXsPfA8Xpd/tU31B/MxXcSI4nSzRGWrBrlXiSBYfSyXLM8rX3iyDnwXZh5++E6Cn+8+OXiX6Vtxk8otrcN9BSUC3YyNag0XVUFW3B4kF/1wIDAQAB

130 DK 建立 DNS 記錄 (2) 如果 DKIM-Signature 有 s= 的話則解析 selector._domainkey.DN
gmail 寄出來的信 s=beta (您可以自行觀察該欄位上之值) 則查 beta._domainkey.gmail.com Yahoo 的 s 為 1024 $> dig beta._domainkey.gmail.com txt +short "t=y\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC69TURXN3oNfz+G/m3g5rt4P6nsKmVgU1D6cw2X6BnxKJNlQKm10f8tMx6P6bN7juTR1BeD8ubaGqtzm2rWK4LiMJqhoQcwQziGbK1zp/MkdXZEWMCflLY6oUITrivK7JNOLXtZbdxJG2y/RAHGswKKyVhSP9niRsZF/IBr5p8uQIDAQAB" $>dig s1024._domainkey.yahoo.com.tw txt +short "k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrEee0Ri4Juz+QfiWYui/E9UGSXau/2P8LjnTD8V4Unn+2FAZVGE3kL23bzeoULYv4PeleB3gfm" "JiDJOKU3Ns5L4KJAUUHjFwDebt0NP+sBK0VKeTATL2Yr/S3bT/xhy+1xtj4RkdV7fVxTn56Lb4udUnwuxK4V5b5PdOKj/+XcwIDAQAB\; n=A 1024 bit key\;" "

131 DK 建立 DNS 記錄 (3) DK DNS TXT 中的 tag 說明 v= 版本,可不寫,日後標準形成後為 v=DKIM1
k= 編碼方式 k=rsa 為預設 n= 註解 (如上頁 yahoo 例子) p= public key 的值 (base64) t= flag, y 為 test 之意,若為 n 表示限定 DKIM-Signature 中的 i= (Sender) 必需同於 d= (Domain)

132 DK 的實作 可參考下列連結之介紹 目前標準的細節仍可能變動,尤其是 tag 資訊的異動可能較多,但精神是不變的
目前標準的細節仍可能變動,尤其是 tag 資訊的異動可能較多,但精神是不變的 Spamassassin 亦有 DKIM 之 Plugin,目前較少看到 Domain Name 有設定 _domainkey 的相關記錄 相同於 SPF 的抽樣,僅看到4筆 DK 資料 雖有 DK 的 TXT 記錄,但若其 MTA 若實作亦無作用 為 dkim 之官方網站,上有多種 MTA 之建置資料

133 DK 的問題 雖然功能較多,能識別到 user 是否真實,但內容遠比 SPF 複雜許多
SPF 的 sign/verify 會消耗較多系統資源,造假的 signature 會讓系統過於忙碌 RSA 演算法存在碰撞現象,不同的 key 可能產生相同的 signature (巳證實) 郵件內容改變 Header Insert/delete/rewrite (如主旨加了 {spam} ) 會造成 verify 失敗 綜觀 DKIM 的立意良好,但其實作程面要求的程度較 SPF 來得高許多,其中又關係到 sign / verify 及安全等議題,故可能在最後的導入上遭遇困難 Tags 太多不易理解,容易形成障礙 標準尚未完全確立

134 網路釣魚

135 網路釣魚的動機 網路釣魚主要是要竊取各種機密資訊，或是冒用其他的人身份從事各種活動，最主要的動機就是賺錢 網路銀行帳號、密碼 信用卡卡號
網路拍賣轉帳 遊戲虛擬寶物 各種系統帳號、密碼

136 網路釣魚 常見方法 電子郵件網釣 偽造網頁 偽造網站 發送偽造的email(社交工程) 入侵其他人的主機設置偽造的網頁
註冊一個相似的domain name 發送偽造的 (社交工程) 以各種理由騙使用者使其連線到事先安排好的偽造網頁或是網站

137 網路釣魚 視覺上的欺騙 使用相似或容易混淆的域名 www.hsbc.com.hk->www.hkhsbc.com
多了-、_、.net等輔助或不明顯的符號 以數字取代英文 -> 使用者拼錯字或按錯鍵盤

138 網路釣魚 最近的幾個案例 華航 日盛證券 土銀 china-airlines.com.tw china-air1ines.com.tw
jihsunbank.com.tw jinsunbank.com.tw 土銀 landbank.com.tw 1andbank.com.tw

139 網路釣魚 上述案例之目的 網域名稱和原網站相似，使用者不易察覺
使用frame技術連到原來之網站，使用者之操作直接與原網站連線，過程資料不會經由假網站，使用者不會查覺有異樣 另一個隱藏frame暗藏木馬程式，下載至使用者電腦執行,以側錄 user 的資訊 在搜尋引擎上買關鍵字廣告或造假左側排名 當這些公司向 TWNIC 反應時,我們的困難 犯罪事實的認定 刪除或凍結的依據 因為這些法律上的問題會拉長受害時間

140 網路釣魚 停止該假網頁之運作 刪除假網站之網頁內容(網站代管)—立即生效 停止假網站使用之網頁轉址服務—立即生效
ISP 停用假網站之電路-立即生效 通常網釣者不會用自己的網路以避免被抓到 代管業者停止假網站使用之DNS代管—有cache效果，無法立即停止 TWNIC 停止假網站網域名稱之授權解析—有cache效果，無法立即停止

141 網路釣魚 TWNIC可能協助的方式 儘速通知檢調機構完成搜證並通知中心停止解析服務—時效上之問題 其他預防措施
檢查現有註冊資料庫中有下列情況有上千組，但無法確定那一個是有問題 l1 h n m rn 提醒使用者自行保護其網域名稱，如微軟除了註冊microsoft.com外還註冊micr0soft.com，山富旅遊除了註冊travel4u.com.tw外還註冊trave14u.com.tw等 由registrar或domain monitor公司提供之當有其他人註冊可能混淆域名之alert服務 此方案目前 TWNIC 正在推動

142 網路釣魚 公司如何自我保護 對 Web Log 應時常 monitor, 檢查是否有來歷不明的 Referer
公司可常上常用之搜尋引擎以了解自己公司關鍵字查詢結果 預先註冊類似之網域名稱,以防止受害 公司合併仍應保留原有之網域名稱一段時間,以避免被他人所申請

143 DNS 其他的應用 DNS RBL 黑名單機制

144 RBL 涵義 RBL DNS Realtime Black List (dnsrbl)
通常用於用於郵件主機之 IP 連線時即時查詢,以驗證該主機是否為黑名單主機,若是則拒絕連接 網路上之接受公開查詢之 RBL 很多,也有需要付費的,需視情況使用之 有的 RBL 雖然 active 但巳經不維護了,故資料正確性可能有問題 有的 RBL 只是單向的添加,但並不允許移除 有的 RBL 有很高的準確度,但也可能存在較高的誤判率 有的 RBL 只是針對地區性,而沒有考慮到合理性 有的 RBL 有很高的準確度,也有很好的政策機制 (如舉報,移除,通知等),建議多採用這類 RBL 有的 RBL 是其他幾個 RBL 的集合,是否好用應視自己的情況來考慮 如果 IP 為 , 被列入 bl.spamcop.net (以下投影片都以這個為例) 中,則其存在於 DNS 中的記錄為 bl.spamcop.net A 此處的 中的 2 可能介於 2-15 間,主要視不同的 RBL 定義而定,多數的 RBL 使用 2 表 spam 或 3 表 open relay…等,不一而足,此處並無一定

145 RBL 檢查過程 (連接時檢查) other.com Spam.com (IP=219.56.182.46)
5 mx5.other.com. 10 mx10.other.com. 連線到 other.com (擇最佳的 MX ) 220 other.com Other.com 回應連接訊息 ehlo twnic.net.tw spam 送出 ehlo/helo 訊息 Other.com 回應250- extensions 訊息 250-SIZE 250-8BITMIME 250 ENHANCEDSTATUSCODES Mail from: Other.com 回應250 OK 訊息 Rcpt to: Other.com 檢查 IP 的 RBL 記錄 Other.com 檢查連的的 IP 是否被列入 RBL: 查詢 bl.spamcop.net 的 A 記錄 DNS 回應查詢結果 Other.com 得到結果為 ,來源被列入 RBL,代表他可能是 Spam 的來所以拒絕連接,通常回應的訊息會帶 link 資訊如: spam blocked see: Other.com 回應 拒絕 訊息

146 RBL 的連結資訊 以下是該連結所提供的訊息,包含了
被列入 bl.spam.net 的 RBL 中, DNS 查到的結果是 spamcop 的政策是你被列入一段時間就解除,目前這個要 11 小時才解除 過去一週以來有人檢舉 (不提供證據) 如果這個 IP 沒有再被舉報 Spam, 就會自動解除 RBL 若一個 IP 第一次被列入 RBL 時,只會有 24 小時限制,但第二次後視條件有不同的時間限制 下半部尚有少量訊息,但較不重要

147 RBL 廣告信檢舉 ( spamcop 為例) 必需先在 spamcop 上申請一個以 email 為名的帳號
平均反應時間,也就是收到 Spam 到 Report 給 spamcop 的平均時間差,時間愈短,其儘早列入 RBL 可減少其他人受害的機會 處理巳自己寄來的 Spam 內容,最主要是確認的工作,因為不是寄了就算舉報完成 您可以把 SPAM 附件轉寄的方式寄到這個帳號,他們就會處理後續的問題,而以回信的方式給你一個 link 去處理後續的問題 您也可以把郵件的表頭及內及貼在此處並按下 “Process Spam”,他會把表頭所有的 Received: 取出來判斷 IP 資訊,並且取出內文中所有的 Link,分析 Link 的資訊,這些資訊包含了 Domain MX/Whois ,IP Whois 的查詢結果,Spamcop 會出析出所有有用的資訊並將之寄給對應的人 ,連 SOA 中的 都可能會被其取用,其目的是儘最大能力通知所有的人注意此事,並向其反應,如果沒有人反應,他就會把這個 IP 列為 RBL

148 RBL 另外一種型態的捕捉 (以下簡稱 SH)的 RBL 是以設陷阱(trap) 的方式來補捉 spam mail 以一些公開的 讓 spammer 把信送到這些帳號 Spammer 只儘力收集名單而不知那些 是 trap 一些 spam 統計也是以 trap 方式進行 SH trap 收到信後直接列入 RBL 要移除 SH 被列入 RBL 的 IP 需要一番手續,而不像 spamcop 自動解除,在一般的情況 user 所用的 MTA 不會被無故列入該 RBL, 但可能因為 open relay/proxy 之故而被列入

149 RBL 檢查自己是否被列入 可以用 google 找 rbl check 可以找到很多
新申請線路時若巳知 IP,建議您先 check ,若被列入再請 ISP 換別的 IP (再 check 一次) 若被列入 RBL 請依對方網站說明方能解除 RBL 有些 RBL 需要 ISP 去提才能解除,因需與 ISP 溝通故相當花時間才能解封 (還需看 ISP 配不配合) 若自己被列入 RBL 有什麼現象 寄出的信可能被退回,一般而言退信訊息上會有相關連結 (連接時就拒絕) 寄出的信可能會被對方歸為 Spam, 而致使對方可能沒有看見 (收下來後才檢查)

150 RBL MTA 如何搭配 Postfix Sendmail 修改好 MTA 的設定後需重新啟動 MTA 之相關服務
#/etc/postfix/main.cf # sbl-xbl 含義建議您自行參考 SH 網站上的說明 smtpd_client_restrictions = reject_rbl_client bl.spamcop.net,, reject_rbl_client sbl-xbl.spamhaus.org # /etc/mail/sendmail.mc FEATURE(`enhdnsbl‘,`bl.spamcop.net’,`“spam blocked see: # 為同一行,勿斷行 $>m4 sendmail.mc > sendmail.cf

151 謝謝