分類
技術文章 網域名稱

DNS 除錯教學系列文章(5) – 常見 DNS 問題與 dig 除錯方法

DNS 系列文章目錄

DNS 除錯教學系列文章(1) – DNS 入門
DNS 除錯教學系列文章(2) – DNS 架構
DNS 除錯教學系列文章(3) – DNS 紀錄
DNS 除錯教學系列文章(4) – dig 指令
DNS 除錯教學系列文章(5) – 常見 DNS 問題與 dig 除錯方法

首先你一定有一個問題,或是查詢的目標,譬如問題是郵件不會通、網站打不開、或是想知道 www 目前指到那一台伺服器,針對你要查詢的問題,首先查 NS 的位址然後再查詢你要確認的狀況。

第一步驟 – 查詢 NS 的位址

在你作 dig 除錯開始之前,首先你要確認網域名稱的名稱伺服器(NameServer) 位址,因為所有回應都一定從名稱伺服器回應,如果你使用的是域名註冊商或是 CloudFlare 之類的服務,那你的名稱伺服器就是這些業者,就是你在網域名稱註冊商中填寫的名稱伺服器(NameServer) 欄位的資料。

但是你在除錯的時候,不要用登入網頁去查你現在的設定值是什麼,因為你應該模擬 DNS 運作的方式去取得名稱伺服器的位址,就跟正常的查訊一模一樣,該怎麼查詢名稱伺服器的位址呢?請查詢 NS 類型,你可以先用 +short 查看簡易輸出:

$ dig +short rsync.tw ns
ns2.gandi.net.
ns3.gandi.net.
ns1.gandi.net.

這樣就能知道目前網域名稱的名稱伺服器是哪幾台,也就是 DNS 紀錄是由這些伺服器管理。這是一般人查詢 NS 的方式,但最正確的方式應該是透過上層的名稱伺服器來查詢下層名稱伺服器的位址,舉例來說我要知道 rsync.tw 的名稱伺服器,我應該要對 .tw 的伺服器送出 rsync.tw 的 NS 查詢,要直接由 .tw 伺服器回應我才對,這部份要分兩個階段來做,第一步驟是你必須知道上層網域的名稱伺服器,然後第二步驟是直接對這些名稱伺服器送出查詢:

# 第一步驟
$ dig +short tw ns
a.dns.tw.
g.dns.tw.
c.dns.tw.
e.dns.tw.
b.dns.tw.
f.dns.tw.
d.dns.tw.
ns.twnic.net.
h.dns.tw.
anytld.apnic.net.

# 第二步驟
$ dig @h.dns.tw rsync.tw ns
[省略]
;; AUTHORITY SECTION:
rsync.tw.		3600	IN	NS	ns2.gandi.net.
rsync.tw.		3600	IN	NS	ns1.gandi.net.
rsync.tw.		3600	IN	NS	ns3.gandi.net.

為什麼要分兩次查詢呢?難道不能直接用 $ dig +short rsync.tw ns 的方式嗎?若是你直接用 dig 去查詢域名的 ns,系統會透過 DNS Cache Server 來查詢 NS 紀錄 (如下圖左邊),這樣有可能會拿到 Public DNS 的暫存資料,所以你應該用到第二種方式直接對 .tw 伺服器發送查詢 (如下圖右邊),才會拿到最正確的資料。

DNS 查詢

這邊是以 .tw 的網域名稱為範例,如果你是要查詢 .com 或是 .info 的域名,就要去查詢不同的上層名稱伺服器喔!

可能發生的問題

空的、沒有回應

如果你在查詢 NS 的時候出現錯誤,或是發現有回應,但是沒有資料,那表示可能是 (1) 名稱伺服器資料填錯了,請去網域名稱註冊商那邊檢查 (2) 網域到期沒繳,或是狀態有問題,可以用 Whois 查看一下是否有問題。

名稱伺服器是 Public DNS

有些人會把 Public DNS 以為是名稱伺服器,結果就把 8.8.8.8 或是 168.95.1.1 填入名稱伺服器,這當然是不對的。

跟你填的資料不同

NameServer (NS) 的資料就是你在域名註冊商所填入的名稱伺服器,像下面是我在註冊商填入的:

rsync.tw 的名稱伺服器 – Gandi.net

然後這邊是我實際查詢出來的,跟上方要長的一樣,順序沒有關係:

$ dig +short rsync.tw ns
ns2.gandi.net.
ns3.gandi.net.
ns1.gandi.net.

如果你查詢出來不一樣,則表示域名註冊商沒有將您的名稱伺服器更新到域名管理局 或是你剛好更換名稱伺服器中。

第二步驟 – 直接查詢名稱伺服器的資料

在你確認 NS 的位址之後,接下來直接對名稱伺服器送出查詢,查詢你要解析的網域名稱,名稱伺服器回應的資料應該是最新、最完整的,所以你要知道紀錄更新了沒、解析到底正不正確,都是透過直接查詢名稱伺服器來獲得解答。

假設我現在要查詢的是 www.rsync.tw 的資料,或是 rsync.tw 的 MX 紀錄,我直接對名稱伺服器查詢:

$ dig +short @ns1.gandi.net www.rsync.tw a
webredir.vip.gandi.net.
$ dig +short @ns2.gandi.net www.rsync.tw a
webredir.vip.gandi.net.
$ dig +short @ns3.gandi.net www.rsync.tw a
webredir.vip.gandi.net.

可能發生的問題

名稱伺服器同步不一致

為什麼上面的範例要查三次?因為這個網域名稱有三台名稱伺服器,如果你有十台,麻煩查 10 次,因為你要確保每一台的資料都是正確的,如果有其中一台不正確,或是尚未同步,則實際在網站連線的時候,連線就會跳來跳去,一下跑到舊的,一下跑到新的,所以若你發現舊的伺服器持續有連線,表示有某個名稱伺服器還是舊的資料。

名稱伺服器沒有回應

如果你在對名稱伺服器查詢的時候,沒有回應,表示名稱伺服器的 DNS 服務有問題,通常不一定是機器壞掉,有可能是單純 DNS 沒有啟動,這時候你才可以用 ping (ip) 的方式去看一下機器有沒有回應,如果有,表示單純 DNS 服務的問題,這是後又可以用 dig +tcp 的方式將查詢改為 TCP 連線,就可以測試是否是火牆的問題,因為有先防火牆設備 (不論是本機防火牆或是額外的設備) 預設是不開啟 UDP 連線。如果 dig +tcp 的方式有回應,就要朝向防火牆的問題去解決。

所以查詢指令有:

# 查詢名稱伺服器回應,你可以查詢 SOA,因為一定有這筆紀錄
$ dig @(NS IP) (domain) soa

# 如果上面沒有回應,改用 ping 看看是不是主機或網路問題
$ ping (NS IP)

# 如果 ping 有回應,但依舊查不到,改用 +tcp 查看是否為防火牆
$ dig +tcp @(NS IP) (domain) soa

檢查權威伺服器回答

名稱伺服器指的是由上往下的授權,譬如 rsync.tw 的名稱伺服器是由 .tw 上往下授權到 ns[1-3].gandi.net 的名稱伺服器。

雖然上往下授權了,但可不見得授權是正確的,因為上往下的授權其實是使用者自己填的,他可以亂填、或是填錯了,你會發現上層會依照使用者輸入的資料直接變成名稱伺服器(NS)。

但實際上,必須要由系統管理者在伺服器中建立正確的區域檔紀錄,並且告訴 DNS 伺服器要管理某個網域名稱,這時候電腦才會知道說這個網域是我管理範圍,所以要由我來回應。在伺服器設定了管理網域之後,這台伺服寄就會變成所謂的 “權威伺服器” ,而這台伺服器的回應,就叫做 “權威伺服器回答 (回應)” ,所以 DNS 的正確授權應該要確認兩個因素:(1) 由上對下正確授權 (2) 伺服器具備權威伺服器回答,缺一不可!

檢查權威伺服器回答很簡單,因為在 dig 的回應中本來就會顯示是否是權威伺服器回答。在 dig 的參數中不要使用 +short 就可以看到標頭 (header) 的部份,答案就在標頭的 “AA” 旗標。

$ dig @ns1.gandi.net rsync.tw a

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @ns1.gandi.net rsync.tw a
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45858
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;rsync.tw.			IN	A

;; ANSWER SECTION:
rsync.tw.		10800	IN	A	217.70.184.38

在上述的回應中,有一個 “flags: qr aa rd;”,aa = AA 就是權威伺服器回答的意思,也就是這個伺服器知道自己管理了此網域,所以會從區域檔中的資料回應給查詢端。如果你對 Public DNS 查詢的話,是不會有這個 AA 旗標的。如果你查詢的是名稱伺服器,但卻沒有 AA,表示管理員沒有正確設定伺服器。

如果你剛更新了 www 的紀錄,或是想知道 MX 的紀錄是否正確,或是設定了任何 TXT、A、CNAME 的紀錄,想知道權威伺服器是否正確,就可以做幾個查詢,然後順便檢查一下 AA 旗標,記得把名稱伺服器與網域名稱都換成你自己的喔:

# 查詢權威伺服器的 www 紀錄
$ dig @ns1.gandi.net www.rsync.tw a

# 查詢 CNAME 紀錄
$ dig @ns1.gandi.net www.rsync.tw cname

# 查詢 MX 紀錄
$ dig @ns1.gandi.net rsync.tw mx

# 查詢 TXT 紀錄
$ dig @ns1.gandi.net rysnc.tw txt

查詢快取伺服器 (Public DNS)

最後一步就是要查詢快取伺服器的回應資料,看看是否正確,一般所有的用戶電腦都會透過快取伺服器 (譬如8.8.8.8、168.95.1.1) 取得 DNS 的資料,所以我們要測試一下是否正確:

$ dig @8.8.8.8 www.rsync.tw a

可能發生的問題

查詢到舊資料

如果你查詢到舊的資料,其實不用太緊張,因為 DNS 有 TTL 暫存時間,在暫存時間內,都會保留資料直到 TTL (秒) 時間過去。這時候你要做的就是確認每一個權威伺服器的查詢是否都是最新的資料,然後你重複對同一個快取伺服器查詢,理論上你應該會看到 TTL 的時間越來越少,這時候就是等待 TTL (秒) 的時間過去。

但這時候你其實你可以查詢一下其他快取伺服器的回應,應該會回應最新的資料,例如你剛剛查詢的是 8.8.8.8,你可以試試看 101.101.101.101 或是 1.1.1.1。

# 對 Google 的 Public DNS 查詢
$ dig @8.8.8.8 www.rsync.tw a

# 對 APNIC 的 Public DNS 查詢
$ dig @101.101.101.101 www.rsync.tw a

# 對 Cloudflare 的 Public DNS 查詢
$ dig @1.1.1.1 www.rsync.tw a

解析失效 NXDOMAIN

如果你在上述查詢的過程中,都沒有問題,但是在 Public DNS 這些快取伺服器卻沒有回應,則有可能是錯誤是 DNSSEC 壞掉了,這時候請找你的域名註冊商取消你的 DNSKEY 金鑰。你可以用這個連結來測試一下 DNSSEC 有沒有問題。

分類
技術文章 教學 網域名稱

DNS 除錯教學系列文章(2) – DNS 架構

DNS 系列文章 2,來談談 DNS 的架構。

DNS 系列文章目錄

DNS 除錯教學系列文章(1) – DNS 入門
DNS 除錯教學系列文章(2) – DNS 架構
DNS 除錯教學系列文章(3) – DNS 紀錄
DNS 除錯教學系列文章(4) – dig 指令
DNS 除錯教學系列文章(5) – 常見 DNS 問題與 dig 除錯方法

DNS 的架構

在你了解 系列文章 1 的入門之後,現在我們來看看 DNS 的架構,DNS 是透過階層、分散資料的方式來完成查詢。在你輸入網址的時候:

https://haway.30cm.gg

系統會知道你是要在 rsync.tw 這個網域裡面查找 blog 這台主機(為什麼? 請看系列文章1),系統會先檢查你的 hosts 檔的設定,如果沒有,就會查看 resolv.conf (Linux 系統) 的設定,將網域變更為 FQDN,然後從根網域開始尋找網域名稱。

來源:dns-learning.twnic.net.tw

“.” 我們又叫做 “Root” 或是 “根網域”,是所有 DNS 查詢的起始點,接者就會看你要查詢的網域是那一個,根網域向下”授權” 了很多子網域,像是 “tw”、”hk”、”cn”、”com”、”net” 等等的子網域,然後這些網域的域名管理局(Registry),又會依照使用者所註冊的網域名稱來向下授權,譬如 rsync.tw 就會去查找 .tw 底下的 rsync 網域,所以就會透過 .tw 的 DNS 主機,如果是 rsync.jp,那就會去查找 .jp 的主機,在網域名稱就是透過 “.” 來區分每一層的 DNS 授權,blog.rsync.tw 就表示有兩層域名,主機是 blog。

階層式 DNS 架構

關於 DNS 架構的其他參考文章:

DNS 快取伺服器 – /etc/resolv.conf

在每個人的電腦裡面,一定會紀錄 DNS 快取伺服器的位址,快取伺服器的作用是協助電腦 (用戶端) 來查詢 DNS 的解析。

遞迴查詢與非遞迴查詢

在整個 DNS 的解析過程中,包含了遞迴查詢與非遞迴查詢兩種查詢模式。因為 DNS 架構是階層、分散式的,所以在每一個層裡面都只擁有自己所管理的一層資料,譬如 .tw 的主機內就只擁有 *.tw 的所有子網域 (但只有下一層),所以 .tw DNS 主機內有 rsync.tw 的資料,但卻沒有 blog.rsync.tw 的紀錄。

因為每一層都只有自己的資料,所以當使用者要查詢 blog.rsync.tw 的時候,必須透過多次的查詢才能獲得最終的資料。

使用者的電腦在發起 DNS 查詢的時候,會對 DNS 快取伺服器發起”遞迴查詢“,然後快取伺服器就會針對查詢一層一層的幫使用者查詢到最終的答案,並將解答回傳給使用者。在使用者與快取伺服之間,使用者電腦只需要透過一次查詢,(例如送出 https://www.gandi.net),快取伺服器就會透過根伺服器、.net 伺服器、gandi 伺服器依序查詢到最終主機(權威伺服器),快取伺服器的這個過程我們稱為”非遞迴查詢” (因為要多次詢問)。

DNS 查詢圖解

resolv.conf

前面有提到在使用者電腦發起 DNS 查詢的時候,他怎麼知道要去哪裡找快取伺服器呢?答案就是 /etc/resolv.conf (Linux 系統) 這個檔案,在這個檔案中,我們可以設定快取伺服器,你的電腦就會將 DNS 遞迴查詢送到這些伺服器做查詢。Linux 系統可以使用指令來查看你電腦的名稱伺服器:

{14:44}:@~/]$ cat /etc/resolv.conf 
domain rsync.tw
nameserver 168.95.1.1
nameserver 8.8.8.8
search hdns.com.tw example.com

這個檔案內的 nameserver 指的是 DNS 快取伺服器 (Cache Server),並不是管理網域的名稱伺服器。

如果你有注意到,你會看到有 domain 與 search 這兩個設定,要講解他們的用途之前,你應該先了解什麼是 FQDN,在沒有 “.” 結尾的主機名稱,都會被系統自動附加網域名稱,而此設定就是告訴系統可以附加什麼網域名稱。

如果你只輸入 blog,系統會自動改為 blog.rsync.tw 並嘗試送到 168.95.1.1 進行 DNS 解析,如果不成功,會換成 blog.hdns.com.tw 再次嘗試解析,又失敗的話會改為 blog.example.com,所以你知道為什麼要先了解主機名稱、子網域與網域名稱的區別了嗎?

如果 168.95.1.1 的 DNS 服務無法連上,系統就會自動跳到第二筆 8.8.8.8 快取伺服器。

DNS 權威伺服器 (名稱伺服器)

DNS 權威伺服器就是管理 DNS 紀錄的主機,實際上是由系統管理員設定 DNS 服務,並將網域名稱加入到主機中,當主機接收到 DNS 查詢的時候,就會回應該網域名稱的資料。那你會覺得說 DNS 快取伺服器也會接收 DNS 查詢並且回應。跟權威主機有什麼不一樣呢?

快取伺服器是幫你去詢問其他主機的 DNS 資料,而權威主機是從自己的資料庫中取出資料並且回應。

因為現在多數人都會使用 DNS 代管服務。會在購買網域名稱的時候就使用域名註冊商所提供的 DNS 代管或是用其他第三方 DNS 代管,代管主機就是你的網域名稱的權威伺服器。

向下授權

前面有提到 DNS 架構的階層概念、主機名稱、網域名稱與權威主機。而串起所有 DNS 流程的功能,最重要的就是向下授權這個動作。我們再看一次這張圖:

DNS 運作流程

圖中的 .(root) 指向了 tw 就是一個向下授權,代表根伺服器將 tw 網域向下授權給其他主機,而 .tw 又將 rsync(.tw) 與 com(.tw) 向下授權給不同的主機。

就像一個主管把技術授權給工程師小明,把行銷工作授權給阿美,把會計工作授權給大寶。如果有人跑來問主管說系統的問題要找誰,主管就會請他去找小明,而行銷與會計的工作,就分別去找阿美跟大寶,由主管來分配,而在 DNS 中,目前是由 ICANN 根據當初申請的狀況將各網域名稱分配給不同的機構,如 tw 是分配給TWNIC 進行管理,而 TWNIC 就要負責架設 tw 的權威伺服器來管理此網域與之下的所有子網域。

你將認識的第一個紀錄 – NS

ICANN 可以知道實際管理的機構,但電腦不知道,電腦只認識伺服器與 IP 位址,根伺服器會記錄每一個子網域 (.tw 對根伺服器來說是一個子網域) 的授權主機位置,就是透過 NS (NameServer) 紀錄,例如說根網域(.)的主機中會紀錄 .tw 主機的位置,所有查詢 .tw 的 DNS 就都會轉去 .tw 的授權主機進行下一步的查詢。

第一個除錯技巧-正確的授權主機是誰?

所以,第一個你將學習到的除錯技巧是你的 DNS 主機目前到底是正式授權到哪些主機上面,因為所有你網域名稱的 DNS 查都會從授權主機中查出答案,正式授權主機是什麼產生的呢?就是你在購買網域名稱的時候所填寫的名稱主機 (NameServer) ,網域註冊商 (Registrar) 會依照你所註冊的域名,把你的名稱伺服器送給域名管理局 (Registry),管理局確認後就會把你的主機資料放入他們的紀錄中,就會產生一組 NS 資料。以本網站來說,筆者跟 .tw 註冊了 rsync.tw 的網域名稱,並且在網域註冊商的名稱伺服器中填寫了:

rsync.tw 名稱伺服器

我們就可以從 dig 指令查詢到 rsync.tw 的 NS 紀錄,雖然我們還沒教你怎麼使用 dig ,但聰明的你一定可以小試伸手把域名改成你自己的,然後看看你的名稱伺服器是什麼:

{11:23}:@~]$ dig rsync.tw ns
; <<>> DiG 9.10.3-P4-Ubuntu <<>> rsync.tw ns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1881
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rsync.tw. IN NS
;; ANSWER SECTION:
rsync.tw. 2085 IN NS ns2.gandi.net.
rsync.tw. 2085 IN NS ns1.gandi.net.
rsync.tw. 2085 IN NS ns3.gandi.net.

查詢網域的名稱伺服器非常重要,因為當你在做 DNS 除錯的時候,一定要先確認目前的名稱伺服器是不是你所填寫的資料,如果不是,表示網域註冊商沒有更新,或是你填錯了,請立刻修正。

其實 ns 的查詢不是像本範例中那麼簡單,因為這樣查詢到的資料有可能是 TTL 的資料 (TTL 是什麼?),後續會教你如何正確的查詢 NS(NameServer) 紀錄。

接者我們將在下一章結先看一下一些常見的 DNS 紀錄,然後在繼續學習 dig 的使用。

DNS 系列文章目錄

DNS 除錯教學系列文章(1) – DNS 入門
DNS 除錯教學系列文章(2) – DNS 架構
DNS 除錯教學系列文章(3) – DNS 紀錄
DNS 除錯教學系列文章(4) – dig 指令
DNS 除錯教學系列文章(5) – 常見 DNS 問題與 dig 除錯方法