使用Cloudflare的名稱伺服器代管DNS & 設定DNSSEC

雖然本部落格在新版Google PageSpeed Insights上的評分非常悽慘,
在把網站主機從新加坡搬到日本東京後,想說對台灣讀者而言此站的速度應該有變快,
就一直沒有進行速度優化的打算,不過用了幾個月…..實在忍不住了…..
我人在地球另一邊的英國,這個部落格開起來超慢的啊啊!  “orz
於是用Chrome開發人員工具看了一下載入流程,才赫然發現…..
DNS Lookup
DNS Lookup、Initial connection、SSL和TTFB幾個關鍵指標,表現還真的都不怎麼樣 XD

為了再次確認,我還用了Webpagetest分別測試了從倫敦和香港連接到此部落格的狀況:
webpagetest, London
webpagetest, HongKong
上圖為倫敦,下圖為香港,從香港出發的DNS Lookup、Initial connection和SSL名顯耗時較少,
但TTFB(time to first byte)仍是最主要的效能瓶頸…..
目前網站沒有設定任何快取,看來是時候裝個快取外掛了;
除了超高的TTFB,那個將近300ms的DNS Lookup看了也實在滿礙眼,
剛好最近有打算改用Cloudflare代管DNS,就順便記錄一下前後差異,
看Cloudflre那自稱全球最快DNS代管到底能縮短多少查詢時間 ww

個人之前為了使用Cloudflare的CDN有申請免費帳號,然而據說因為與Hinet的互連費率喬不攏,
僅有付費方案的Cloudflare用戶能使用台北節點,其他來自台灣的流量都會被導到美國,
導致開了CDN比不開還更慢的情況,所以目前這個網站是”Pause”、也就是未開啟CDN的狀態;
不過沒開啟CDN一樣能使用DNS代管服務,只要到上方的DNS區域加入網站,
Cloudflare record
Cloudflare就會自動讀取DNS紀錄,接著把提供的Name Server貼到域名註冊商那邊,
不用幾分鐘立刻就能生效,整個過程非常簡單快速;
在Cloudflare中也能選擇開啟DNSSEC,只要把啟動後顯示的資料複製,
回到域名註冊商的管理系統中新增DS record即可,同樣很快完成.
cloudflare dnssec
然而Fastcomet在客戶端的管理系統不支援手動新增DS record,
僅能透過申請技術支援的方式請官方工程師來幫忙添加…..官方回覆非常快,
不過工程師一開始似乎沒搞懂如何添加DS record,
把Cloudflare提供的官方教學寄過去方才解決,多花了些時間…..
Fastcomet的客戶服務確實是滿棒的,今年Black Friday若還有特價應該會續約吧 ww

DS record添加完畢後幾乎是立即生效,
使用DNSVizDNSSEC Debugger測試很快就能看到狀態與信任鍊,
不過使用Cloudflare代管DNS後,intoDNS的報表就出現了錯誤,顯示:
I could use the nameservers listed below to performe recursive queries.
It may be that I am wrong but the chances of that are low.
You should not have nameservers that allow recursive queries as this will allow almost anyone to use your nameservers and can cause problems.

Cloudflare的技術支援社群有滿多人都在問這個問題,根據支援團隊的回應,
這似乎是intoDNS那邊的顯示結果不正確,無須擔心…..
嘛,原本就是為了增進安全性及(某種程度上)防止DNS汙染,
才選Cloudflare代管並啟用DNSSEC的,要是反而出現新問題那可就得不償失了呢.

至於關鍵的DNS Lookup的速度是否真的有變快呢?
DNS lookup time
在住處的測試結果,從275.69ms縮短為46.61ms,加速了229.08ms!
(註:前後測都已經刪除本機與瀏覽器DNS暫存,recursive resolver為Google Public DNS 8.8.8.8)
゚Д゚)<用老子的authoritative nameserver了,居然沒順便改1.1.1.1?
⊂彡☆))Д′)<噫噫噫噫
speed after cloudflare
speed after cloudflare
從倫敦(上圖)出發出發的DNS Lookup所需時間亦從284ms變成66ms,
自香港(下圖)連接的改進幅度較小,卻也從97ms進步為66ms;
三個測試中分別縮短了229.08、218和31ms,總體來說確實是明顯降低了查詢DNS的時間,
Cloudflare能長期盤據DNSPerf榜首,果然不是浪得虛名!

使用Cloudflare後所縮短的時間帳面數字看起來滿威的,
不過接著還是得要認真規劃網站暫存機制與壓縮方式才行,
畢竟DNS Lookup的單位ms是毫秒…..所以其實沒真的省下多少時間啊 XD

迴響: 8 則迴響

文章分類:電腦相關

標籤: , , , , ,

在〈使用Cloudflare的名稱伺服器代管DNS & 設定DNSSEC〉中有 8 則留言

  1. 在台灣用CF免費方案沒悽慘到被轉去美國啦,剛才測試我自己架在家裡光纖的站台,會轉去韓國節點。對台灣用戶來說日本韓國應該不會差太多,對站長來說可以取用歐洲節點肯定比較快。

  2. 感謝經驗分享,那應該是我查到的資料太舊了,
    看很多網站在CF改免費方案政策後都在哀號,說走中華電信的被轉到洛杉磯或聖荷西,
    才以為一直到現在還是如此;但會被轉去韓國節點還真是想不到,
    根據CF之前的文章: https://blog.cloudflare.com/bandwidth-costs-around-the-world/
    Seoul和Taipei是唯二被特別點名超級貴的地方,
    把台灣的轉去韓國到底是怎麼回事…..好像有種賺到了的感覺呢(誤)

  3. >>要測試特定站台會轉去哪邊節點可以參考
    哇,謝謝提供資訊,原來可以直接加”/cdn-cgi/trace”就看到節點資訊,
    之前cloudflare部落格的文章翻了不少篇,結果我還是完全沒注意到有這招 “orz

    話說Blog很慢的元兇好像找到了…..居然是niconico的外嵌!?
    僅載入”https://secure-dcdn.cdn.nimg.jp/extplayerv/embed/js/lib/dll_aa0a1bc369108260ea88.js”就花了近5秒,
    有放niconico動畫的文章被擠到第二頁後,首頁開起來變快好多 XD

  4. >>我這邊是被轉去 Cloudflare 香港
    個人請幾個朋友測試,轉的地方有時都不一樣,
    不曉得是否和網路公司有關呢?
    紀錄到的地方包括台灣、韓國和新加坡,現在新增了香港,謝謝您的回報 ww

  5. 又再次看到這篇
    再來回報一下 今天看真的被轉到洛杉磯了⋯⋯

  6. >>再來回報一下 今天看真的被轉到洛杉磯了
    欸欸欸!?真的被送到美國西岸去了 XD
    這幾天想說反正有Cloudflare所以載入速度不會差很多,
    就把部落格從FastComet東京伺服器搬到Hostinger的新加坡主機,
    難道這會影響到節點選擇嗎…..? 我會再查查相關資料,感謝您的通知 ww

發表迴響

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料