Q: 什麼是「DNS 代管」？
HiNet Pro DNS 代管與其他代管產品有什差異？
如果你不想自己架設權威主機，同時又希望維持對 DNS 設定內容的主導與掌控權；如果你的網域名稱有 30 筆以上的 DNS 紀錄需要設定且尚未找到其他代管產品有提供足夠容量；如果你希望在異動 DNS 紀錄後，不用等 24 小時而能更快速（5~10分鐘內）生效， 那麼 HiNet 提供的「HiNet Pro DNS」會是您很好的解決方案。
每個網域名稱都必須有「權威主機」負責管理所有與該網域名稱相關的 DNS 紀錄。網域名稱的權威主機可以由網域名稱的持有者自己架設，也可以直接使用 HiNet 等業者所提供且負責維運的 DNS 軟硬體。其中，承接此類 DNS 軟硬體外包的服務即「DNS 代管」。這種將 DNS 服務 outsourcing 給 ISP 等業者代勞的合作模式，有助於降低網域名稱持有者本身所需付出的 DNS 伺服器維運成本。這對於 MIS 人力資源有限的單位而言不失為一個值得考慮的 DNS 服務解決方案。
HiNet Pro DNS 代管具有以下特色，提供了相較於其他代管產品更大的自由度與掌控性：
如果您的域名是於「HiNet 網域註冊」取得，則登入 domain.hinet.net 即可使用 HiNet 網域註冊的免費 DNS 代管服務。若您是「HiNet 固定制」客戶，則登入 enoc.hinet.net 亦有免費 DNS 代管服務可選用。Pro DNS 代管與前述免費方案對比如下：
Q: 關於 DNS DDoS 防護，中華電信的解決方案是？
1. Pro DNS 的產品定位
Pro DNS 代管主要為用戶免除自行建置、維護 DNS (權威)主機的麻煩，同時提供以下產品特點：
實務上，權威主機的擴容可透過配置額外的頻寬與 DNS 伺服器進一步提升安全性與可用度。這些權威主機「生力軍」所使用的 zone file (DNS資料)，則可透過 DNS 原生的資料同步機制「zone transfer」取得。這代表著若用戶本來就自行建置並維護權威主機，則不使用 Pro DNS 代管、直接在 DNS DDoS 防護專案中延用自家既有 DNS 主機做為 zone transfer 的資料來源「(hidden) master」也是可行的。您可依需求與偏好自由選購、搭配 DNS 代管與 DNS 防護服務。
2. 可為所申裝線路購買的on-demand資安「DDoS清洗」服務與「DNS DDoS防護」專案的差異？
您如果已經為所申裝線路購買過on-demand資安「DDoS清洗」服務，對照到下方關聯示意圖，保護效果主要彰顯於左側標有 "HN" 的線路(攻擊流量將會。前述「DNS 防護」專案則將由 HiNet DNS 團隊以「ISP 級」的規格、技術、資源建置權威主機「生力軍」，與前述用戶所申裝的線路屬於不同群組，也可獨立於 Pro DNS 代管的預設配置。
Q: 關於Pro DNS代管的其他「加值服務(們)」
依照您所回饋的意見，Pro DNS代管將持續更新功能以盡力符合您的需求。以下摘要自 Pro DNS 代管上線後陸續推出的加值服務項目：
1. HiNet DNS cache 清洗
如果需要「臨時」異動 DNS 紀錄（也因此無法事先調短該筆紀錄的 TTL），即可透過清洗（flush）cache 來補救。由於 HiNet DNS（168.95.1.1、168.95.192.1）同樣也是 Pro DNS DevOps 團隊所負責，可以幫助您加速所託管網域名稱紀錄的生效。 縱使 cache flushing 範圍不及於其他業者的 DNS 服務，HiNet DNS 做為在地最主要的 DNS 解析服務提供者，一旦更新將可使大部分台灣的用戶即時查詢到新的紀錄。
欲試用此功能，可開啟您的 Pro DNS 代管「網域名稱列表」頁面，並點選待更新之網域名稱對應的「更新」按鈕（如下圖紅框所示），系統將於 2~3 分鐘內為您執行完指定網域名稱的 cache flushing。 由於 HiNet DNS 系統具有相當規模，且為避免 cache flushing 對設備負載與服務造成衝擊，系統將批次完成指令，並限制指令發送的頻率。若發送頻率過高，請依系統指示稍候。
2. 操作紀錄回顧
在網域名稱之 DNS 紀錄編輯頁面點擊「操作紀錄」按鈕，系統將列出（當下頁面所屬域名之）相關編輯紀錄如下圖示。
3. 管理介面允入IP管控
您可為託管域名定義允入管理介面的IP位址。簡述使用方式如下：
a. 首先進入 DNS 紀錄編輯介面，點選左上角「允入管控」按鈕
b. 輸入可編輯此域名的終端IP位址
c. 將「允入管控」介面上方的開關設定為 On
完成上述步驟後，若不是由允入IP進入「DNS紀錄編輯」或「允入管控」介面，將會看到如下警示訊息並被轉導回「託管域名列表」
4. 分頁呈現DNS紀錄
為避免DNS紀錄筆數多導致網頁載入時間過長，改以分頁的方式呈現所設定的紀錄。可使用如下圖示的選單挑選瀏覽的分頁與每頁呈現的筆數。
PS：新紀錄可於任何一個分頁新增，新增後將呈現於最後一個分頁。
5. 域名解析可用度「強化方案」（選配）
HiNet DNS（168.95.1.1、168.95.192.1）為中華電信所提供的 DNS resolver 系統，服務台灣相當高比例的上網用戶。
此「強化方案」將可確保指定域名於 HiNet DNS 的解析可用度，且不受 NS 紀錄所發佈的權威主機狀態影響。
若有相關需求，請洽專案經理或參考本代管服務的申請流程向客服反應，會再安排技術人員說明。
6. DNSSEC 簽署（選配）
Pro DNS將可協助處理 DNSSEC 金鑰管理、簽署等作業。
詳情請洽專案經理或參考本代管服務的申請流程向客服反應，會再安排技術人員說明。
Q: 如何使用本 DNS 代管服務？
變更 DNS 代管產品的選擇，技術上是指將網域名稱授權給不同套的權威主機。為了確保切換期間各種服務仍能正常運作，建議採取前述「先建後切(換)」的策略來進行 DNS 代管的異動，分以下兩個步驟說明。
（1）先在「Pro DNS 代管」建立 zone file
在使用 HN 號碼與對應連線密碼登入本系統候， 點選「網域名稱代管」，再將欲託管的網域名稱輸入對應的欄位中並「確認送出」（如下圖所示）。
完成網域名稱登錄後可以點選「編輯」進入 DNS 紀錄（Resource Record）設定頁面（如上圖示），本代管服務支援的 DNS 紀錄類型如 Q3 回答所列。填寫過程中系統會依照輸入資料給予提示：例如填寫 TXT、CAA 紀錄時，不需要雙引號（系統會自動補上）。如若設定內容為反規定系統也會提出警告並拒絕送出（如下圖示）。完成 DNS 紀錄的填寫後請按「確認」送出。
nslookup
C:\Users>nslookup 預設伺服器: hntp1.hinet.net Address: 2001:b000:168::1 > server nsp1.hinet.net 預設伺服器: nsp1.hinet.net Addresses: 2001:b000:180:808:203:66:88:194 203.66.88.194 > www.example.co.tw 伺服器: nsp1.hinet.net Addresses: 2001:b000:180:808:203:66:88:194 203.66.88.194 名稱: www.example.co.tw Address: 2.2.2.2
dig
>dig.exe @nsp1.hinet.net www.example.co.tw a ; <<>> DiG 9.3.2 <<>> @nsp1.hinet.net www.example.co.tw a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 782 ;; flags:qr aa rd; QUERY:1, ANSWER:1, AUTHORITY:1, ADDITIONAL:1 ;; QUESTION SECTION: ;www.example.co.tw. IN A ;; ANSWER SECTION: www.example.co.tw. 600 IN A 2.2.2.2 ;; Query time: 10 msec ;; SERVER: 203.66.88.194#53(203.66.88.194) ;; WHEN: Thu Jun 30 15:13:16 2016 ;; MSG SIZE rcvd: 99
Q: 向nsp1.hinet.net提出DNS查詢但卻得到「No response from server」的訊息!?
以Windows的nslookup為例，有被觀察到會將指定DNS主機的 IPv4 與 IPv6 位址都查出，並可能優先向 IPv6 位址送出查詢。由於 HiNet DNS 主機都以 dual-stack 模式同時支援 IPv4 與 IPv6 連線，若客戶端未啟用 IPv6 並向 DNS 伺服器的 IPv6 位址提出查詢，即可能得到標題所列與下圖示的「No response from server」結果。
此時可以直接指定 Pro DNS 權威主機的 IPv4 位址進行複測(以目前 Pro DNS 代管的權威主機 IP 之一示範如下)。或向 recursive resolver 服務如 Google 的 8.8.8.8、8.8.4.4 或 HiNet DNS 168.95.1.1、168.95.192.1 也可(最遲待被查詢 DNS 紀錄的 TTL 過期後即會反應出更新)。
nslookup
C:\Users>nslookup 預設伺服器: hntp1.hinet.net Address: 2001:b000:168::1 > server 203.66.88.194 預設伺服器: [203.66.88.194] Addresses: 203.66.88.194 > www.example.co.tw 伺服器: [203.66.88.194] Addresses: 203.66.88.194 名稱: www.example.co.tw Address: 2.2.2.2
dig
>dig.exe @203.66.88.194 www.example.co.tw a ; <<>> DiG 9.3.2 <<>> @nsp1.hinet.net www.example.co.tw a ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 782 ;; flags:qr aa rd; QUERY:1, ANSWER:1, AUTHORITY:1, ADDITIONAL:1 ;; QUESTION SECTION: ;www.example.co.tw. IN A ;; ANSWER SECTION: www.example.co.tw. 600 IN A 2.2.2.2 ;; Query time: 10 msec ;; SERVER: 203.66.88.194#53(203.66.88.194) ;; WHEN: Thu Jun 30 15:13:16 2016 ;; MSG SIZE rcvd: 99
（2）透過網域名稱註冊商修改上層登記的 NS 紀錄
假設 example.co.tw 是透過 domain.hinet.net 網域名稱註冊服務所取得，則在任何一個 WHOIS 網站輸入 example.co.tw 都可以查到對應的註冊商（Registration Service Provider、Registrar）為「HINET」（如下圖示），而註冊商也必須提供介面供使用者輸入其網域名稱的 NS 紀錄，並將資料同步給對應的上層權威主機。
本 Pro DNS 代管的用戶請透過當時註冊到網域名稱的域名註冊商，將 NS 紀錄改為「nsp1.hinet.net.」與「nsp2.hinet.net」。( 下圖以透過 domain.hinet.net 所註冊的網域名稱示範上層 NS 的設定 )
再次強調網域名稱不見得是從 HiNet 的網域名稱註冊而得，該聯絡哪家業者請用 WHOIS 查詢服務輸入您的網域名稱確認。另外關於為何需要同步更新網域名稱「上層」所登記的 NS 紀錄，請參考本文「Appendix：DNS 解析的運作原理」段落的說明。
附錄：DNS 解析的運作原理簡介 & NS 紀錄異動的「先建後切(換)」策略
DNS（逐級而下）的解析原理
網際網路上網站難以計數，沒有任何一個「DNS 解析（resolution）」服務提供者（像 HiNet 的 168.95.1.1 或 Google 的 8.8.8.8 等「DNS resolver」系統）能獨立掌握網上所有網域名稱與對應 IP 等 DNS 資料，那麼 DNS 解析究竟是如何運作的呢？簡言之是一種「階層分工」、「逐級而下」的模式，概念類似於以下的情境：
我們若想找某校的小明同學（請忽略直接廣播的手段），在對該校一無所知的情況下，請該校負責人校長出馬應該是個可靠的起頭。但全校學生之多，校長大概無法每位都認識，但校長知道這問題跟學籍有關，因此可以建議你向負責學生註冊編班的註冊組長詢問。而註冊組長雖然不見得會跟小明或其他同學直接互動，但他可以查出小明所在班級並提供該班導師以及教室位置等資訊。聯絡上該班導師後基本上就可以把小明找到根前了。
對照 DNS 系統的運作，以用戶瀏覽 HiNet 首頁（www.hinet.net）為例，用戶使用的電腦或手機必須取得 www.hinet.net 對應的網頁主機 IP 位址，而 DNS 可透過以下解析流程來取得答案：
- 1. DNS 系統首先由「根域名伺服器（root servers）」（類比校長）打頭陣。雖然根域名伺服器無法直接提供 www.hinet.net 的 IP，但可以指點迷津、引導向「與 www.hinet.net 最相關的頂級主管機關」，即 net 層的權威主機查詢。（net 層權威主機負責管理、提供所有 .net 結尾域名的 NS 紀錄）
- 2. net 層權威主機（類比註冊組長）雖然不知道 www.hinet.net 的 IP 這樣細節的資訊，但可以提供「關於 hinet.net 相關問題可以找誰（即 hinet.net 被授權給哪幾台權威主機）」的指引。
- 3. hinet.net 的權威主機（類比班級導師）負責所有關於 hinet.net 子域名 DNS 紀錄，便可提供 www.hinet.net 之 A 或 AAAA 或 CNAME 紀錄的設定值了。
PS：
「先建後切(換)」的 DNS 代管移轉策略
每一個網域名稱的 DNS 紀錄都必須有「權威主機（authoritative nameservers）」負責保存與對外發布，而「網域名稱是由哪幾台權威主機負責」的對應關係則是以「NS 紀錄」定義。由於 DNS 解析是以一種「階層分工」、「逐級而下」的模式運作，因此 NS 紀錄除了存在於網域名稱自身的權威主機上之外，也必須登錄於網域名稱的「上層」權威主機，才能在 DNS 解析過程中被外界習得，進而指引 resolver 去找您指定的權威主機索取網域名稱相關紀錄。
以 hinet.net 為例，「上層」就是「.net」。而 .net 層的權威主機除了記錄 hinet.net（早期）的權威主機是 ans1.hinet.net 與 ans2.hinet.net 之外，其他以 .net 結尾的網域名稱之權威主機也同樣會被登錄在此（例如 fetnet.net 的 dns01.fetnet.net 與 dns02.fetnet.net 等，如下圖示）。
DNS 代管移轉意味著權威主機的替換（即 NS 紀錄的修改）。為了引導外界改向新的權威主機查詢域名相關 DNS 紀錄，且為了確保移轉過程中解析不受新舊權威主機切換的影響，我們建議以「先建後切(換)」的方式進行。其中，
所謂「下層權威主機」即您所選用的 DNS 代管方案，會由業者提供資料編輯的管道（以 Pro DNS 代管為例，您可自行透果網頁介面 DIY 設定 DNS 紀錄）；至於在「上層權威主機」的 NS 紀錄，則可透過（您當時取得網域名稱的）「域名註冊商（registrar）」修改，相關操作可參閱前文「（2）透過網域名稱註冊商修改上層登記的 NS 紀錄」的範例。
附錄：什麼是「NS紀錄上下層不一致」？會造成什麼影響？
從前文可知，為了在「逐級而下」的 DNS 解析過程中，將關於網域名稱的 DNS 紀錄查詢都引導至您指定的（代管或自管）權威主機，您必須確保 NS 紀錄同時存在於「上層」且內容與您指定的（代管或自管）權威主機之版本一致，以 hinet.net 的現況示範如下：目前 hinet.net 配有 ans1.hinet.net、ans2.hinet.net、ans3.hinet.tw 三台權威主機，而向該三者或是 net 層任何一台權威主機查詢 hinet.net 的 NS 紀錄，所得結果都應該一致地為 ans1.hinet.net、ans2.hinet.net、ans3.hinet.tw（如下圖示）。
「NS紀錄上下層不一致」的檢測方式
相對的，如果登錄在上層權威主機的 NS 紀錄錯誤，則發生網域名稱解析結果不正確，甚至無法解析等障礙都不足為奇。由於只有網域名稱持有者才擁有其在域名註冊商的登入帳密，因此「NS紀錄上下層不一致」的問題無法由 DNS 代管業者或 ISP（僅做為服務提供者）介入、代理修正。
那麼該如何檢測「NS 紀錄上下層不一致」的問題呢？除了有「TWNIC DNS check service」等線上工具可供參考外，也可以使用 dig 或 nslookup 等指令自行檢測，介紹如下。
用 dig 指令檢測「NS紀錄上下層不一致」問題
如果您使用的是 LINUX-based 作業系統，則可執行「dig @168.95.1.1 您的網域名稱 NS +trace +nodnssec +additional」。該指令意義為：向 168.95.1.1 查詢您的網域名稱之 NS 紀錄，並列出每一層權威主機所提供的 NS 紀錄（授權 delegation）資料、忽略 DNSSEC 相關紀錄、並顯示「additional section」。以 hinet.net 示範如下：
; <<>> DiG 9.12.3-P1 <<>> @168.95.1.1 hinet.net ns +trace +nodnssec +additional ; (1 server found) ;; global options: +cmd . 55231 IN NS c.root-servers.net. . 55231 IN NS j.root-servers.net. . 55231 IN NS a.root-servers.net. . 55231 IN NS d.root-servers.net. . 55231 IN NS i.root-servers.net. . 55231 IN NS m.root-servers.net. . 55231 IN NS f.root-servers.net. . 55231 IN NS e.root-servers.net. . 55231 IN NS b.root-servers.net. . 55231 IN NS h.root-servers.net. . 55231 IN NS l.root-servers.net. . 55231 IN NS k.root-servers.net. . 55231 IN NS g.root-servers.net. ;; Received 267 bytes from 168.95.1.1#53(168.95.1.1) in 16 ms net. 172800 IN NS a.gtld-servers.net. net. 172800 IN NS b.gtld-servers.net. net. 172800 IN NS c.gtld-servers.net. net. 172800 IN NS d.gtld-servers.net. net. 172800 IN NS e.gtld-servers.net. net. 172800 IN NS f.gtld-servers.net. net. 172800 IN NS g.gtld-servers.net. net. 172800 IN NS h.gtld-servers.net. net. 172800 IN NS i.gtld-servers.net. net. 172800 IN NS j.gtld-servers.net. net. 172800 IN NS k.gtld-servers.net. net. 172800 IN NS l.gtld-servers.net. net. 172800 IN NS m.gtld-servers.net. a.gtld-servers.net. 172800 IN A 192.5.6.30 a.gtld-servers.net. 172800 IN AAAA 2001:503:a83e::2:30 b.gtld-servers.net. 172800 IN A 192.33.14.30 b.gtld-servers.net. 172800 IN AAAA 2001:503:231d::2:30 c.gtld-servers.net. 172800 IN A 192.26.92.30 c.gtld-servers.net. 172800 IN AAAA 2001:503:83eb::30 d.gtld-servers.net. 172800 IN A 192.31.80.30 d.gtld-servers.net. 172800 IN AAAA 2001:500:856e::30 e.gtld-servers.net. 172800 IN A 192.12.94.30 e.gtld-servers.net. 172800 IN AAAA 2001:502:1ca1::30 f.gtld-servers.net. 172800 IN A 192.35.51.30 f.gtld-servers.net. 172800 IN AAAA 2001:503:d414::30 g.gtld-servers.net. 172800 IN A 192.42.93.30 g.gtld-servers.net. 172800 IN AAAA 2001:503:eea3::30 h.gtld-servers.net. 172800 IN A 192.54.112.30 h.gtld-servers.net. 172800 IN AAAA 2001:502:8cc::30 i.gtld-servers.net. 172800 IN A 192.43.172.30 i.gtld-servers.net. 172800 IN AAAA 2001:503:39c1::30 j.gtld-servers.net. 172800 IN A 192.48.79.30 j.gtld-servers.net. 172800 IN AAAA 2001:502:7094::30 k.gtld-servers.net. 172800 IN A 192.52.178.30 k.gtld-servers.net. 172800 IN AAAA 2001:503:d2d::30 l.gtld-servers.net. 172800 IN A 192.41.162.30 l.gtld-servers.net. 172800 IN AAAA 2001:500:d937::30 m.gtld-servers.net. 172800 IN A 192.55.83.30 m.gtld-servers.net. 172800 IN AAAA 2001:501:b1f9::30 ;; Received 831 bytes from 193.0.14.129#53(k.root-servers.net) in 12 ms hinet.net. 172800 IN NS ans1.hinet.net. hinet.net. 172800 IN NS ans2.hinet.net. hinet.net. 172800 IN NS ans3.hinet.tw. ans1.hinet.net. 172800 IN A 168.95.192.15 ans1.hinet.net. 172800 IN AAAA 2001:b000:168::1:100:1 ans2.hinet.net. 172800 IN A 168.95.1.15 ans2.hinet.net. 172800 IN AAAA 2001:b000:168::2:100:1 ;; Received 191 bytes from 192.5.6.30#53(a.gtld-servers.net) in 37 ms hinet.net. 86400 IN NS ans1.hinet.net. hinet.net. 86400 IN NS ans2.hinet.net. hinet.net. 86400 IN NS ans3.hinet.tw. ;; Received 103 bytes from 168.95.192.15#53(ans1.hinet.net) in 11 ms
從以上 output 可見，對於 hinet.net 的上層「net」，這次指令的執行挑選了「a.gtld-servers.net (192.5.6.30)」這台權威主機進行 hinet.net 相關的查詢並得到了紅色字區塊來自上層權威主機的答覆；至於下層 hinet.net 則由「ans1.hinet.net (168.95.192.15)」提供了藍色區塊來自下層權威主機的答覆。詳細比對紅色與藍色的 NS 紀錄，若不論順序則兩者內容是一致的。
每次執行 dig +trace 的查詢指令，各層負責回答的權威主機可能更換。例如 hinet.net 有 ans1.hinet.net、ans2.hinet.net、ans3.hinet.tw 三台權威主機，則任何一者都有可能做為被查詢的對象。倘若不確定每一台權威主機的資料都同步一致，可以重複多執行幾次指令，或用「@」直接向每一台權威主機提出查詢。
PS：
上層權威主機的資料同步基本上會由各區 NIC（Network Information Center）負責確保，故擇一查測即可，例如「dig @a.gtld-servers.net hinet.net ns」。
; <<>> DiG 9.12.3-P1 <<>> @a.gtld-servers.net hinet.net ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29252 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 5 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;hinet.net. IN NS ;; AUTHORITY SECTION: hinet.net. 172800 IN NS ans1.hinet.net. hinet.net. 172800 IN NS ans2.hinet.net. hinet.net. 172800 IN NS ans3.hinet.tw. ;; ADDITIONAL SECTION: ans1.hinet.net. 172800 IN A 168.95.192.15 ans1.hinet.net. 172800 IN AAAA 2001:b000:168::1:100:1 ans2.hinet.net. 172800 IN A 168.95.1.15 ans2.hinet.net. 172800 IN AAAA 2001:b000:168::2:100:1 ;; Query time: 91 msec ;; SERVER: 192.5.6.30#53(192.5.6.30) ;; WHEN: Mon Mar 04 01:11:50 Taipei Standard Time 2019 ;; MSG SIZE rcvd: 191
另外，上層權威主機清單可以且必須依網域名稱的 Second-Level Domain 或 Top-Level Domain 之 NS 紀錄解析結果更新。例如：如果您的域名是 testdomain.com.tw（以 com.tw 結尾），則上層（即 com.tw）權威主機清單的 dig 指令可參考「dig @168.95.1.1 com.tw NS」，從中挑選 c.twnic.net.tw 等項目做為查詢對象。
C:\Users\您的帳號>dig @168.95.1.1 com.tw ns ; <<>> DiG 9.12.3-P1 <<>> @168.95.1.1 com.tw ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33653 ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ; COOKIE: 0e05cdb29b304e28983c7de15c7cc6080b6e7ff0180c992b (good) ;; QUESTION SECTION: ;com.tw. IN NS ;; ANSWER SECTION: com.tw. 2981 IN NS b.twnic.net.tw. com.tw. 2981 IN NS h.twnic.net.tw. com.tw. 2981 IN NS c.twnic.net.tw. com.tw. 2981 IN NS anytld.apnic.net. com.tw. 2981 IN NS h.dns.tw. com.tw. 2981 IN NS f.twnic.net.tw. com.tw. 2981 IN NS d.twnic.net.tw. com.tw. 2981 IN NS a.twnic.net.tw. com.tw. 2981 IN NS e.twnic.net.tw. com.tw. 2981 IN NS g.twnic.net.tw. ;; Query time: 1207 msec ;; SERVER: 168.95.1.1#53(168.95.1.1) ;; WHEN: Mon Mar 04 14:30:33 Taipei Standard Time 2019 ;; MSG SIZE rcvd: 251
用 nslookup 指令檢測「NS紀錄上下層不一致」問題
若作業系統沒有 dig 指令可用，則可改用 nslookup 指令以 hinet.net 示範檢測方式如下，指令目的以綠色字註記於右。
C:\Users\你的帳號>nslookup
Default Server: dns.hinet.net
Address: 168.95.1.1
> set type=ns （指定待查詢的紀錄類型）
> net （指定待查詢的網域名稱，首先指定「上層」域名）
Server: dns.hinet.net
Address: 168.95.1.1
Non-authoritative answer:
net nameserver = l.gtld-servers.net
net nameserver = k.gtld-servers.net
net nameserver = d.gtld-servers.net
net nameserver = g.gtld-servers.net
net nameserver = m.gtld-servers.net
net nameserver = i.gtld-servers.net
net nameserver = c.gtld-servers.net
net nameserver = h.gtld-servers.net
net nameserver = a.gtld-servers.net
net nameserver = e.gtld-servers.net
net nameserver = j.gtld-servers.net
net nameserver = b.gtld-servers.net
net nameserver = f.gtld-servers.net
> server a.gtld-servers.net （挑選 DNS 伺服器，可於上列權威主機中任意擇一，此次先選 a.gtld-servers.net 做為上層權威主機的代表）
Default Server: a.gtld-servers.net
Addresses: 2001:503:a83e::2:30
192.5.6.30
> server 192.5.6.30 （直接指定 a.gtld-servers.net 的 IPv4 位址，為了避免終端 IPv6 支援度不足造成檢測失敗）
Default Server: [192.5.6.30]
Address: 192.5.6.30
> hinet.net （搭配前面參數，向上層權威主機查詢指定網域名稱的 NS 紀錄）
Server: [192.5.6.30]
Address: 192.5.6.30
hinet.net nameserver = ans1.hinet.net
hinet.net nameserver = ans2.hinet.net
hinet.net nameserver = ans3.hinet.tw
ans1.hinet.net internet address = 168.95.192.15
ans1.hinet.net AAAA IPv6 address = 2001:b000:168::1:100:1
ans2.hinet.net internet address = 168.95.1.15
ans2.hinet.net AAAA IPv6 address = 2001:b000:168::2:100:1
>quit
C:\Users\你的帳號>nslookup
Default Server: dns.hinet.net
Address: 168.95.1.1
> server ans1.hinet.net （擇一待檢測域名的權威主機）
Default Server: ans1.hinet.net
Addresses: 2001:b000:168::1:100:1
168.95.192.15
> server 168.95.192.15 （同樣指定該權威主機的 IPv4 位址）
Default Server: [168.95.192.15]
Address: 168.95.192.15
> set type=ns （指定待查詢的紀錄類型）
> hinet.net （指定待查詢的網域名稱）
Server: [168.95.192.15]
Address: 168.95.192.15
hinet.net nameserver = ans2.hinet.net
hinet.net nameserver = ans1.hinet.net
hinet.net nameserver = ans3.hinet.tw
> quit