改個 DNS 是要改多久？- Domain 管理的常見問題
Background
身為網路世界的一般使用者或是開發者，其實無時無刻都在使用 DNS 解析位於網址其後的真實運算資源在哪邊，因此當一個網路服務準備上線讓其他人或是服務可以使用前，一定需要先把 DNS 設定好，而這篇文章並沒有要講解 DNS 背後太深入的運行機制，因為自己對於網路底層也不太熟，只有一些堪用的常識而已；最主要是想藉由這篇文章談談自己這幾年來協助相關 DNS 設定時所遇到的常見問題，希望跟我一樣對 DNS 不熟的人看到這篇文章後，可以避免未來犯下一樣錯誤
Basic Concept
在開始之前先說明一點，就是整篇文章都會用 abc.com 來當作自己所擁有的 DNS Domain 來做範例解說，接下來讓我們稍微提一點點要管理 Domain 所必須要具備的基本概念
DNS 是什麼?
當你在瀏覽器輸入 https://www.google.com 時，其實 Google 搜尋服務背後的真實伺服器看不懂英文，並不知道使用者透過這一串網址就是想要找他幫忙服務，這個時候 DNS 就會把 www.google.com 這個 Domain Name (網域名) 轉換成 IP (Internet Protocol) 位址，舉例來說，DNS 會把 www.google.com 轉換成 172.217.160.68，而這個 IP 位址就是要連接到 Google 搜尋服務的真實位置，世界上所有的網頁都是如此運行，畢竟要大家去記得 IP 位置是不切實際且不可能的，所以都是透過 DNS 來做網域名跟 IP 位置的轉譯
~$ nslookup www.google.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53Non-authoritative answer:
Name: www.google.com
Address: 172.217.160.68
主要的 DNS Record 種類
底下會就十種主要的 DNS Record 種類做基本介紹，讓大家可以更了解 DNS 內部機制，不過這篇文章主要會提到的只有 A Record, CNAME Record 還有 NS Record
01. A Record: 全名為 Address Mapping Record，也常被稱為 DNS Host Record，用來儲存該 Hostname 對應的 IPv4 位址
02. AAAA Record: 全名為 IP Version 6 Address Record，是用來儲存 Hostname 對應的 IPv6 位址
03. CNAME Record: 全名為 Canonical Name Record，可以把 Hostname 別名到另外一個 Hostname，例如把 aaa.abc.com 這筆 CNAME Record 設定別名到 bbb.abc.com，當使用者請求的 DNS Record 中含有 CNAME Record 時，DNS 就會重複解析到真實對應的 Hostname
04. MX Record: 全名為 Mail Exchanger Record，指定這個網域名所使用的 SMTP 郵件伺服器，用來把對外的電子郵件路由到電子郵件伺服器去
05. NS Record: 全名為 Name Server Record，用來指定 DNS Zone，例如 abc.com 是專屬於哪一個特定的 Authoritative Name Server，所以 DNS Client 送出的查詢請求才知道是要去找誰詢問
06. PTR Record: 全名為 Reverse-lookup Pointer Record，允許 DNS 解析的時候可以使用 IP 位址反查出 Hostname (reverse DNS lookup)
07. CERT Record: 全名為 Certificate Record，用來儲存加密憑證，如 PKIX, SPKI 和 PGP…等
08. SRV Record: 全名為 Service Location Record，有點像是 MX Record，但是用來儲存其他種通訊協定
09. TXT Record: 全名為 Text Record，通常用來儲存機器才能讀懂的資料，例如 DKIM, DMARC, Sender Policy Framework…等
10. SOA Record: 全名為 Start of Authority Record，這種 Record 會出現在 DNS Zone 檔案的開頭，用來表示該 DNS Zone 的 Authoritative Name Server，並且紀錄這個 DNS Zone 的主要管理人員聯絡資料，Domain 的序號，還有關於重新獲取該 DNS Zone 資訊的頻率
科普完基本的 DNS Record 種類之後，接著來分享自己協助設定 DNS 常常遇到的幾個問題
Issue 1: WWW or Non-WWW
情境對話
PM: 為什麼我連到新設定好的網址 abc.com，可是無法成功啊？
Engineer: 怎麼記得你當初是說要設定 www.abc.com ，所以不能直接連 abc.com 啦！
PM: 這兩個不是都一樣嗎？！不過我已經對外說是 abc.com 了，你趕快把設定幫忙改好吧！
背後問題
以上面的例子來說 abc.com 跟 www.abc.com 是完全不一樣的兩個東西，但大家平常在使用時，其實都有人默默地幫忙處理掉這個 DNS 查詢問題，所以當自己在設定的時候，必須要特別注意請你幫忙設定的人，是不是希望 abc.com 和 www.abc.com 都可以存取到某個 Hostname
abc.com 這種不帶任何 Subdomain 的網址稱為 Domain Apex (也可以稱作 Zone Apex 或是 Naked Domain)，用來表示所擁有網域層次結構的 Root，該網域的任何其他子網域，例如 www.abc.com, mail.abc.com…等都不能被視為 Domain Apex，只能被當成是 abc.com 的子網域
解決方法
那要如何設定好一切呢？讓使用者不管使用 abc.com 或是 www.abc.com 都可以連接到想去的地方？答案不是那麼地非黑即白，需要根據架構面來決定解決的方式
應用服務可以透過簡易且固定的 IP 位址存取
一般的 DNS 服務只允許 Domain Apex 是簡單的 A Record (原因可以查看 RFC 1912 section 2.4 CNAME Records)，所以假如網路服務可以簡易的使用靜態 IP 位址存取，那其實就什麼問題都沒有了，只要設定好兩筆 A Record 給 Domain Apex 跟 WWW 就可以搞定，而假設 Domain Apex 和 WWW 之間需要擁有自動重新導向功能，在 Apache 可以使用 .htaccess 或是修改 httpd.conf，而使用 Nginx 的話，則可以修改 nginx.conf (設定範例可以參考這邊)
應用服務不能透過簡易且固定的 IP 位址存取，但是有使用第三方 CDN 服務
就像上面提到的 DNS 服務不允許 Domain Apex 是 CNAME Record，而假如你的應用服務本身就是網址，而且解析到的還是浮動 IP (使用 Cloud Provider 提供的各種服務相當常見) 該如何是好呢？！這時候要是應用服務的前端還有一層 CDN 服務，例如 Akamai (Zone Apex Mapping), Cloudflare (CNAME Flattening) 的話，就可以鬆一口氣，因為這類型的服務知道使用者一定會有 Domain Apex 需要是 CNAME Record 的需求，所以都會幫忙實作此功能，幫忙多轉一手；而自己對 AWS 使用的經驗多一些，所以多提一下使用 AWS Route53 管理 Domain 的話，Domain Apex 可以 Alias 到同一個帳號底下的託管服務網址，也算是達成 Domain Apex 可以使用 CNAME Record 的目標 (其他在 AWS 的 Workaround 做法)
上面兩個條件都無法滿足的話….
那就比較慘了，可能就要透過比較麻煩的手段，例如有個服務在中間幫忙轉一手，讓 Domain Apex 可以解析到動態的 IP 位址去，這邊就無法細談下去了，因為要取決於應用服務架設在哪裏，去拜 Google 大神找到自己比較可以接受的解決方式
Issue 2: DNS Propagation
情境對話
PM: 我們是不是已經買到 abc.com 這個網址了？
Engineer：對啊，沒錯
PM：那你幫我設定好 www.abc.com，下班前搞定喔！
Engineer：囧，沒辦法那麼快啦 T_T
背後問題
修改 DNS Domain 的設定值之後，通常需要經過一段時間的發酵之後才能夠生效，這個過程叫做 DNS Propagation，為什麼需要這段時間呢？因為修改完的結果，必須要散布到全球各地的 DNS Server 上面去，如此一來全世界的使用者才有辦法查詢到正確的網址，而有哪些因素會影響到 Propagation 的時間呢？！
DNS Record 的 TTL
每一筆 DNS 紀錄中都會包含有 TTL 的設定值，這個值用來決定伺服器暫存 DNS 紀錄資訊的時間，假設我們將 www.abc.com 這筆 DNS 紀錄的 TTL 設定為一小時，那麼伺服器就會將 www.abc.com 的解析結果儲存在本機端達一小時之久，超過這段時間之後，伺服器才會跑去 DNS Server 再次詢問該筆 DNS 紀錄，縮短 TTL 設定可以加快 Propagation 的速度，但這樣做也會增加 DNS Server 的查詢次數，進而影響到網站的效能
ISP
有時候 ISP 暫存的 DNS 並不是遠端 DNS Server 裡面的最新資料，也是將 DNS 紀錄資訊儲存在自己的本機端，這樣做可以加快網路瀏覽速度並且降低流量，當然缺點就是會加長 Propagation 所需要的時間，而且部分 ISP 甚至可能會忽略 TTL，兩三天才更新一次暫存的 DNS 紀錄資訊
Domain 註冊處
假如是要把擁有的 Domain 從某個註冊處移動到另外一個，例如把 abc.com 從 Godaddy 移動到 Cloudflare，也就是需要去修改 Name Server 時，就會需要比較多的時間，因為這種變更會需要 Propagation 到更高層級的 DNS Server 上，而這些 DNS Server 內設定的 TTL 搞不好會設定到 48 小時甚至更久來避免過度被使用，所以 Propagation 的時間通常要花得更久
解決方法
自己覺得最正確的解決方法就是提這種需求的人需要給予工程部門時間並且尊重專業，不要在最後一刻才提出類似的請求，而自己在修改的過程時，常常會透過 whatsmydns 這個網站來確定自己修改的 DNS 紀錄在全球 Propagation 的進度到哪邊了，確保修改的結果符合預期
Issue 3: Buy Domain Carefully
情境對話
PM：我們公司的縮寫是 xx，最近準備上線的服務就去買 *.xx 的 Domain 來使用吧
Engineer：可是不買 *.com 的嗎？
背後問題
世界上有很多的 Top Level Domain，從 WiKi 上可以看到每個 TLD 的詳細資訊，一般來說，商業用途都會購買 *.com，組織類則是 *.org，常見的還有政府單位 *.gov 跟教育單位 *.edu…等，而這些 TLD 分別是不同的單位在管理，上面提到常見的 TLD 通常不會有什麼問題，但是有一些由某個小國家所管理的就很看運氣，可能是在購買流程上有問題，或是管理系統上有漏洞…等，導致自己買到的 Domain 可能一不小心就變成別人的也不一定
解決方法
建議重要的網站或是服務還是購買常見且比較大的 TLD，已經被別人買走了，就想另外的名稱，或是多花點預算去競標，不要為了耍酷或是貪小便宜就去買一些奇怪的網域，到頭來自己的網域被別人奪走的話，公司受到的影響跟形象損失將會得不償失
Issue 4: Internal & External DNS
情境對話
PM：為什麼 xxx.com 連不到啊？！
Engineer：因為那是內部使用的服務，必須透過辦公室網路，或是 SSL VPN 才有辦法使用
PM：這樣好麻煩喔，沒辦法讓我用家裡網路就連的到嗎？！
Engineer：這個嘛….
背後問題
有一點規模的組職一定會在自己辦公室內部架設 DNS 服務，讓員工可以使用它來解析內部才能夠使用的服務，雖然這樣做會讓使用上比較沒那麼方便而且常常會造成某些奇怪的問題需要花上不少時間 Troubleshooting，不過這也算是必要之惡
提升 DNS 查找的效率
因為是內部才會使用到的服務，所以沒有必要跑到外面公開的 DNS 做查詢，只需要到離自己比較近的內部 DNS 做查找並且將結果暫存起來即可，進而提升網路效率
避免被知道內部資訊
其實從 DNS Domain 可以查到不少資訊，例如從 MX Record 知道使用什麼 Mail Server，從一些 CNAME Record 知道這間公司使用哪一個 Cloud Provider, 從 Domain 紀錄知道使用哪一些第三方網路服務或是工具，進而去研究這些第三方提供者有什麼漏洞可以鑽研；所以假如是只有內部才需要使用到的網路服務，就可以只把 DNS 紀錄資訊放在內部的 DNS 服務就好，避免被外界知道太多不應該知道的資訊
解決方法
有耐心地跟遇到問題的人說聲抱歉，並且稍微解釋為什麼會需要使用到公司網路才能夠存取這些內部服務，最重要的就是不能夠妥協把內部服務的資訊洩漏出去
Issue 5: Subdomain TLS Certificate
情境對話
Engineering A：為什麼我剛剛申請的 Wildcard TLS Certificate可以給 www.abc.com 使用，但是 www.test.abc.com 不行啊？
Engineering B：因為你申請的時候只有填 *.abc.com，對不對？
Engineering A：可是 * 不就是 wildcard，代表前面要加什麼都可以才對啊？
背後問題
以工程師的直覺出發會覺得 * 可以通吃一切是毫無疑問的，但是在 DNS 的世界卻不是如此，從 RFC 2818 Section 3.1 Server Identity 裡面所舉的範例就可以知道原因，裡面提到 foo.a.com 是可以涵括在 *.a.com 內的，但是 bar.foo.a.com 則不行
解決方法
所以在申請 TLS Certificate 的時候，必須要注意 Wildcard * 符號並不能夠通吃到下一層的 Subdomain，他只能夠涵括一層而已，所以假如這一點沒有釐清的話，申請到的 TLS Certificate 一定會無法使用，導致你的瀏覽器跳出 Certificate 錯誤訊息
Conclusion
這篇文章提到了幾個自己常遇到的 DNS 相關問題，這些一定只是冰山一角而已，但還是希望透過此文讓剛接觸的 DNS 設定的人可以少走一些冤枉路，或是讓非 Engineering 角色的人在溝通專案時，可以多留一些時間在 DNS 相關的任務上面，避免在最後一刻才發現專案時程可能因為 DNS 出問題
