TWNIC DNS檢測服務
錯誤/警告訊息列表

錯誤（建議您務必處理）
虛擬 IP/保留 IP 網段 虛擬 IP: 代表僅能使用於內部網路之 IP ,無法由外部主動連接或交換,其使用網路區段為:
10.0.0.0/255.0.0.0 (10/8)
172.16.0.0/255.240.0.0 (172.16/12)
192.168.0.0/255.255.0.0 (192.168/16)
以上之 IP 區段不能用於任何外部 DNS 之資源記錄，以避免他人DNS 查詢時雖可解析但無法連接。

保留 IP 網段:
主要根據 IANA IPv4 Address Space 中之最新之分配紀錄來判斷，若為保留網段則可能會有無法連接之情形。


若您的DNS所設定的IP只要存在以上兩種情況其中之一，則您需要修正以上的錯誤，方能讓他人順利連接到對應的主機。
名稱無法解析(無 A 記錄) 您的網網域名稱稱雖有 NS (NameServer)記錄，但是並沒有對應的 A (Address)記錄，會造成 DNS 在查詢時，無法找到您的DNS IP 位址，造成無法解析之情況

您必需修正這種錯誤，方能正常解析。若您有多部 DNS 主機，但僅有少數存在這種情況，亦請您修正之，以減少查詢端其他可能發生錯誤之情形。
Lame Server Lame Server 成因:
1. 該 DNS 並無管理該網域名稱(即非權威主機)，卻將 DNS 的 NS 記錄指向了該部 DNS:
  例如:很多人將在 TWNIC 的 DNS 指定,設向了 168.95.1.1 或其他僅提供大眾查詢與解析網域名稱之DNS 主機（Cache Server）,但是此類主機並無管理該網域名稱。
2. 該 DNS 管理該網域名稱,但是 NS 記錄列表裏並沒有該 DNS 的名稱
  例如:domain.com.tw 在 TWNIC 的 DNS 指定為 ns1 及 ns2 , 但自己的 DNS 卻將 NS設為 ns3/ns4　等，或與上層不一致之主機名稱。

避免 LAME Server 最大的要求即在上層與下層的 DNS 設定完全一致,並且所有的DNS 主機都能正常工作，如此方是一個上下層完整的授權關係，不完整的授權關係在此TWNIC提供之DNS檢測服務報告中皆會判定為 Lame Server。
Server Fail SERVFAIL 意即Server Fail ，主要的成因為:
1. 在查詢端接收到超過 64K 的 DNS TCP 回應時，將判定為 Server Fail (DNS 使用基本的 udp 53 port 只能回應 512 bytes,TCP 最高可至 64K)
2. 該 DNS 主機可接受遞迴查詢,但是又沒有 Root dns (.) 的設定,造成遞迴查詢上的失敗時,也會產生 Server Fail 之情形。
3. 名稱伺服器雖有設立該網域名稱,但是載入或狀態不正確(SOA/NS 必需正確):
   I. Zone 過期,主要因為 slave 主機到達了 expire 時間仍未更新所造成。
   II. Zone 載入時發生錯誤,主要因為 Zone File 有語法或語意上的錯誤,造成該網網域名稱稱實際上並未載入 DNS 中。
   III. 網域的 NS 記錄的不可以接 CNAME 記錄，否則亦會造成 Server Fail。
   IV. Zone 錯誤,不正確的 SOA 或 NS 資訊,也會造成 Server Fail。
4. 名稱伺服器所設立的 CLASS(IN,CH,HS) 與查詢之 CLASS 不相符。

當 Server Fail 發生時，通常為設定上之問題，主要好發於第３點所描述狀況(其他情況亦有可能但較不常見)，若您有此情形，請檢查您的 DNS 啟動記錄中所發生的錯誤訊息，適當修正後即可避免此一情形。
拒絕連接 DNS 查詢時主要使用 udp 53 port ，發生連拒絕連接之情形主要為您的防火牆阻擋了 53/udp 的 dns 查詢，而回應了拒絕連接之訊息（常發生），或是您的 DNS 設定不允許某一 IP 向您查詢也會發生此一情況(較少發生)。

請檢查您的防火牆設定，設定成允許通過向您 DNS 查詢及回應封包(53/udp) 之rule ，若非防火牆設定的問題，則可能是 DNS 中與存取控制相關的設定所引起。
沒有回應 您的 DNS 沒有回應主要原因可能是:
1. 該 IP 可能不存在或路由及防火牆等問題等引起不能連接等情形。
2. 該 IP 有上線，但沒有 DNS 的 Service 存在。

請檢示您的 DNS 是否仍正常服務及連接的狀態是否正常。
上下層 NS 記錄內容不一致 此亦為導致 Lame Server 錯誤的原因之一，但因經常發生，故獨立一項說明。發生與上層NS記錄不一致的情形時，不同版本的 DNS查詢結果會有差別:
1. BIND 8.X版將取用上層的回應做為答案，並作為下次查詢該網域名稱的快取資料(Cache)
2. BIND 9.X 版則會取用下層的權威回答做為答案，並作為下次查詢該網域名稱的快取資料
故若您在與上層NS記錄不一致的情況下(網域名稱及 IP 之設定皆作為此項檢查)，可能易造成一些意料外的解析結果。

請您修正下層(即您自己的 DNS Server) 或上層的 DNS 設定，來達到上下層DNS設定一致的完整授權狀態，一般情況下修改您自己的 DNS 較修改上層(如 TWNIC) 的DNS設定反應時間來得快。
非權威回答 權威回答的意思為管理該網網域名稱稱的 DNS 所回應的答案稱之，故非權威回答之意即為快取資料(Cahce)之回應，所以沒有管理該網域名稱但能回應該網網域名稱稱的資料皆稱為非權威回答。

我們的檢測主要皆針對權威主機進行，故若您的 DNS 回應了非權威回答，表示您的設定是錯誤的，也就是您所設定的網域名稱的 DNS是一個不管理該網域名稱的 DNS，例如 168.95.1.1 等僅提供大眾查詢與解析網域名稱之DNS 主機（Cache Server）即是。您必需修正此一情況以避免不正確的授權關係。
SOA 訊息不一致 DNS 的 SOA 記錄主要用於同步機制，同時亦存有管理人員的 Email，我們的檢測以檢查 SOA 中的序號欄位資料為主，驗證每部權威主機間的序號是否同步，若其值皆相同則視為同步，不同則視為不同步或不一致。但若您並非使用 BIND 或 Windows DNS 這類常用DNS服務，這個值則僅供參考，如果在不同序號的情況下您自己可以確認為資料為同步，則您可以忽略此值不一致之情形。

若檢測到SOA 訊息不一致的情形，您可以檢查一下每部 DNS 的設定是否正確，是否正確定義出每部權威主機不同 DNS 的類別(BIND 稱為 master/slave ,Windows 稱為 主要/次要)，並在 Slave (次要) 主機上指出了同步主機(Master/主要)的來源 IP，若您的設定皆正確但仍不同步，請檢查　allow-transfer 項目 (Windows 稱為 允許區間傳送) 是否允許 Slave 主機之 IP 要求傳送，或者是否防火牆允許 53/tcp 的連接要求。
HTTP 發生錯誤 每個 HTTP 回應 (Response)時皆會有一個 HTTP Code,而其中 HTTP Code 2xx 為成功的代表(如 200 OK) ， 3xx 為要求轉向(Redirect) ，其他為錯誤情況，每種錯誤情況皆不同的定義，您可參考 RFC 2616 中的第１０節 (Status Code Definitions) 的描述，此DNS檢測服務主要判定若非為 2xx 或 3xx 皆視為錯誤狀況。

若您的 Web Server 出現非 2xx 或 3xx (3xx 您由 Broswer 看不到) ，且在您的預期外，請您檢查一下自身之設定，例如 IIS 中關於 “啟用預設的文件” 或是 Apache 中 DriectoryIndex 項目，若您是故意如此設定則可忽略此一錯誤。
EMAIL 錯誤,找不到郵件主機 此項主要是針對 SOA 中的 EMAIL 欄位及 postmaster@your_domain 進行 Mail 的檢測，而該 Email Address 中的 Domain 不找不到任何 MX 或 A 記錄。

一般習慣以 username@DOMAIN 來做為 email address ，若您本身非使用此一格式或這個網域名稱原本就無 Mail Service，則可忽略此一錯誤，若您有設定 MX/A 記錄並又打算做為 Mail Service ，則可能是上述檢測項目所引起無法解析之問題，請您根據上列檢測項目修正設定。
試寄 Email， 郵件主機回應非 250 訊息 SMTP Server 的回應以 250 代表 OK，此檢測將試送 postmaster@DOMAIN 到您的郵件主機，並以 EHLO/MAIL FROM/RCPT TO 為測試指令，若您在任一階段出現非 250 的訊息時，我們將判斷為錯誤。

若非 250 訊息是在您預期之內，請忽略我們所顯示的錯誤狀態，相反的，若是在您的預期之外，請參考本報告中郵件主機回應之訊息代號檢視您 Mail Server 的相關設定。
Mail Server無法連接 無法連接的因素可能是因為防火牆的阻擋或是該主機並沒有開啟 SMTP 服務等情形。請您檢查SMTP服務之開啟狀態及防火牆設定之 rule。

若此狀態在您的預期內您可以忽略不管，若在預期外建議您適當修正之。
郵件主機被列入 RBL RBL 即 Realtime BlackList 之意，通常意指郵件之黑名單，主要由管理郵件黑名單之單位在受理廣告信檢舉後建立了RBL，故若您的郵件主機若被列在其中，代表您的郵件主機可能存在某些問題(SMTP Open-Relay,SPAM,Open Proxy,被植入木馬或後門等情況 )。在您的郵件主機被列入 RBL 的情況下，若您發信給有使用 RBL 的廠商或客戶的郵件主機時，您的郵件可能無法正常傳遞(視對方使用什麼 RBL 及 anti-spam 方法而定)。此檢測主要是針對您的 MX(或 A)記錄進行五個較常使用的 RBL 進行檢測，若您不在其中不代表您一定沒有被列在RBL之問題。

被列入某些 RBL 時，可從檢測報告中提供之RBL 的網站上查詢到被列入的原因， 請根據您的狀況及移除(Remove)該 RBL 的申請要件進行處理，此檢測僅為您做查詢上的測試，並不受理RBL 移除的要求。
BIND 的安全問題 在 ISC BIND 的官方網站上，詳列了每個 BIND 版本是否存在問題及存在什麼樣的問題，您可至BIND Vulnerabilities查閱弱點表，此檢測主要是比較了您的 DNS 版本與此表之關係，只要您的 DNS 版本在此表有弱點存在，我們即會提醒您可能您的系統存在這樣的問題。

我們會建議您更新您 DNS 的版本至最新版或上述連結中無安全問題之版本，以避免遭受到攻擊或是入侵，您影了整個機器或單位的安全。如果您確實的版本和我們所列的不同，而又不在 BIND Vulnerabilities中，您可以忽略我們的錯誤訊息。


警告（建議您視情況處理）
至少需要兩部以上的 DNS 主機 兩部以上 DNS 主機的要求是公認的，若您的網域名稱只有一部 DNS 時，若 DNS 發生問題容易造成所有的服務都發生問題，而這種狀況其實不符合 InterNIC 或 TWNIC 的規定，以 TWNIC 提供之 DNS 指定服務，都要您填寫兩部以上之資料，原因如下:

容錯：若您僅有一部 DNS 主機時，該主機失效後，網路的眾多功能也會跟著發生問題（Web/Mail…），但若您有兩部以上的 DNS 主機則大大降低了這樣的可能性。若您的 DNS 分佈在不同的 ISP 網段，更可降低網路斷線所造成的眾多問題。
負載平衡：若您設定了兩部以上的 DNS 主機，當您的 DNS 在接受查詢時，其間是採輪流詢問的方式(Round Robin)，故在面對較大的查詢壓力時，更能適當的分擔系統的壓力或流量。
系統安全：目前網路上有著許多可以針對 DNS 作攻擊的程式，若您擁有兩台以上的主機，可降低許多來自於攻擊的危險（相對來說，就 DNS 而言增加了一倍的安全性，其中不同的主機尚可運作不同的作業系統）。
DNS 主機 IP 於相同網段 若您的 DNS 主機皆在相同的 ISP 網段上，在ISP線路發生問題時，雖然您有多部的 DNS主機，仍可能引起您的 DNS 無法解析，故建議您適當的分配 DNS主機 在不同ISP的網段中，以達到備援的要求。
IP 重複 實質上這仍是一部 DNS Server，建議您能達到兩部以上之要求。
Mail Server IP 無反解 由於 SPAM 日多，故許多郵件主機在收信時會要求發信端 IP 需有反解，所以若您的 Mail Server 沒有反解，可能造成您無法寄送郵件至對方主機，故建議您尋求 ISP 幫您的 IP 設立反解(PTR Record)，以利您的郵件順利傳送。 尚請您注意，反解之設立單位為發放給您 IP 之 ISP，請您尋求 ISP 協助，而非找您的網域名稱冊註單位(Registrar)。