客戶發生實際案例。他在安裝 SiteGround 的 SSL 憑證的時候,裝不進去,SiteGround 的客服回應說域名解析有問題,所以自動安裝的程式無法正常運作。
因保護客戶隱私,我使用我自己的域名替換原始域名。
客戶在 Gandi.net 購買了域名,並且啟用了 DNSSEC 與 SSL 來保護自己的域名,但因為想要測試 SiteGround 的主機,所以將網站與名稱伺服器搬了過去,結果想要安裝 SiteGround 的 SSL 時一直失敗,SiteGround 的客服回應他說域名的解析有問題,所以無法安裝 SSL,請他找域名註冊商。在域名註冊商這邊,因為很巧的介面設計的原因,無法檢查 DNSSEC 的狀態。所以變成沒人知道問題在哪裡,也變成踢皮球。
DNSSEC 壞掉會怎樣?
小工具 dig 指令格式:
dig (參數) @(DNS Server) (domain) (type) (+short 簡短回應)
會出現下面這種情況:
(先查詢域名的權威伺服器)
{13:26}:@~]$ dig haway.xyz ns +short
ns1.sgp71.siteground.asia
ns2.sgp71.siteground.asia
(權威伺服器 ns1 有回應)
{13:26}:@~]$ dig @ns1.sgp71.siteground.asia haway.xyz a +short
146.66.105.148
(權威伺服器 ns2 有回應)
{13:26}:@~]$ dig @ns2.sgp71.siteground.asia haway.xyz a +short
146.66.105.148
(中華電信 168.95.1.1 有回應)
{13:26}:@~]$ dig @168.95.1.1 haway.xyz a +short
146.66.105.148
(Google DNS 死掉、Cloudflare 死掉、TWNIC Cache DNS 死掉)
{13:26}:@~]$ dig @8.8.8.8 haway.xyz a +short
{13:26}:@~]$ dig @1.1.1.1 haway.xyz a +short
{13:26}:@~]$ dig @101.101.101.101 haway.xyz a +short
(取消 +short,會看到 SERVFAIL 回應)
{13:27}:@~]$ dig @8.8.8.8 haway.xyz a ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @8.8.8.8 haway.xyz a [略] ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 63895
問題重現
問題在於客戶原先使用了 Gandi 的 LiveDNS 代管域名,並且開啟了 DNSSEC,而後又直接將名稱伺服器變更到 SiteGround,導致 DNSSEC 鏈 (Chain) 驗證失敗! 其實有點像是你做好了 DNSSEC,但是有人偷偷把你的名稱伺服器換成別的,這時候因為 DNSKEY 沒有移轉(因為是代管在 Gandi,所以也不能移轉)。新的名稱伺服器沒有原本的 DNSKEY,在 Cache Server (8.8.8.8) 驗證時,就會判定驗證失敗,而回應 SERVFAIL 。如下圖:紅色是原本的 DNSSEC 驗證鏈,名稱伺服器被修改成 SiteGround 之後變成藍色線, DNSSEC 就驗證失效了。
為什麼 168.95.1.1 有回應?
168.95.1.1 是一群 DNS 伺服器,在台灣有好幾百台,擁有強大的 DNS 回應處理能力,是我國最強中華電信所維護(先稱讚一下)。這群伺服器是很久很久很久以前就建立,裡面可能眾多的歷史包袱與維護的狀況,裡面有些 DNS 的版本是比較舊的,或是沒有強制開啟 DNSSEC 驗證,所以不會驗證 DNSSEC 信任鏈,會直接使用原本的 DNS 協定,於是會取得回應。Google DNS 與很多新的 Public DNS 服務都是後來才建立,使用的都是新版的 DNS 軟體(BIND),新本的軟體預設會開啟 DNSSEC 驗證。所以就是為什麼 Google、Cloudflare、TWNIC 這些新的 Public DNS 會驗證失敗。
怎麼檢查?
如果你認為所有的 DNS 設定都正確,唯獨 8.8.8.8 沒有回應,你可以試一下這個指令:
(8.8.8.8 沒有回應)
{13:26}:@~]$ dig @8.8.8.8 haway.xyz a +short
(用 CD Flag 來讓 DNS Cache Server 關閉 DNSSEC 驗證)
{13:26}:@~]$ dig +cdflag @8.8.8.8 haway.xyz a +short
146.66.105.148
CD Flag 就是告訴 8.8.8.8 ,這一個 DNS 查詢不需要進行 DNSSEC 驗證。所以 8.8.8.8 會直接回覆你答案。
怎麼修正?
很簡單,使用你域名註冊商的介面,找尋關閉 DNSSEC 的功能,或是直接聯絡客服,請他們幫你把 DNSSEC 移除。
或是在新的名稱伺服器重新簽署 DNSSEC,然後更新你的 DNSKEY 金鑰。
範例
你可以使用 ICANN 所提供的域名來測試:dnssec-failed.org,這個域名是 ICANN 故意把他弄壞,你可以用 Verisign 的工具來檢查,你可以透過上述說的一些指令自行操作,查詢一下 dnssec-failed.org 域名的回應,以下指令供您參考,如果您能搞懂為什麼會有回應,為什麼不會有回應,就代表你懂了:
$ dig @8.8.8.8 dnssec-failed.org a +short
$ dig dnssec-failed.org ns +short
$ dig @doug.ns.cloudflare.com dnssec-failed.org a +short
$ dig @168.95.1.1 dnssec-failed.org a +short
$ dig +cdflag @8.8.8.8 dnssec-failed.or a +short
後記
應該是後來 Gandi 的 LiveDNS 有改版,因為我想使用自己的域名重現問題,在 LiveDNS 開啟 DNSSEC 後,直接將名稱伺服器變成到其他 DNS 代管。在過程中 Gandi 會自動幫你取消 DNSSEC 並且移除上層 DS 紀錄,也就是說,你的域名是不會有問題的。
ps 本文圖片使用 yEd 線上板 製作。