還記得在前幾次說到要來講解 AWS 內網 DNS 的神奇之處了嗎?
其實會發現這件事情是因為小編有一個客戶因為覺得系統效能不太好,經過檢查發現是對方 DNS 效能不太好,細查之後才發現這個特性的,而經過了多次測試發現真有此事,官方也有說明這件事情是正常的,因而有了這篇文章,現在就帶大家來看看是什麼事情吧!
首先先來說明這次要用到的 dig 指令
dig +nocmd +noall +answer +ttlid a google.com |
指令 | 解釋 |
+[no]cmd | 切換輸出中的初始註釋的顯示,該註釋標識dig 的版本和已應用的查詢選項。 預設情況下會顯示。 |
+[no]all | 設置或清除所有顯示標誌。 |
+[no]answer | 顯示或不顯示應答的回答部分。 預設情況下會顯示此項。 |
+[no]ttlid | 顯示記錄時顯示或不顯示TTL。 |
了解指令之後我們開一台 t2.small 的機器使用上面教的指令,得到以下回應。
這個回應感覺怪怪的小編映像中自己機器的 TTL 設定是 300
clarence@ip-10-0-0-0:~$ dig +nocmd +noall +answer +ttlid blog.clarence.tw | |
blog.clarence.tw. 60 IN A 104.31.80.250 | |
blog.clarence.tw. 60 IN A 104.31.81.250 |
我們換一下 DNS Server 位置,改成 Google 的 DNS,不要使用 VPC 內部的 DNS,使用指令 @8.8.8.8 來達到此目的。
clarence@ip-10-0-0-0:~$ dig @8.8.8.8 +nocmd +noall +answer +ttlid blog.clarence.tw | |
blog.clarence.tw. 299 IN A 104.31.80.250 | |
blog.clarence.tw. 299 IN A 104.31.81.250 |
神奇的事情發生了 TTL 從 60 變成 299,怎麼回事呢?理論上來說 DNS 第一次詢問都會得到一個擁有者希望得到的 TTL,如上所說小編 DNS 的 TTL 時間設定明明就是 300,這件事情真的非常的奇怪,因此小編又開了一台不一樣等級的機器做測試,這次使用的等級是 t2.medium,得到的答案如下:
clarence@ip-10-0-0-0:~$ dig +nocmd +noall +answer +ttlid blog.clarence.tw | |
blog.clarence.tw. 60 IN A 104.31.80.250 | |
blog.clarence.tw. 60 IN A 104.31.81.250 |
詭異的事情發生了,明明是新的機器竟然 TTL 時間是 60,理論上新的機器應該不會有 cache 才對啊!這時候小編又開了一台不一樣等級的機器做測試,這次使用 c4.large,得到的結果如下:
clarence@ip-10-0-0-0:~$ dig +nocmd +noall +answer +ttlid blog.clarence.tw | |
blog.clarence.tw. 60 IN A 104.31.80.250 | |
blog.clarence.tw. 60 IN A 104.31.81.250 |
真是見鬼了,竟然還是依樣的結果,小編依然不相信,因此開始在網路上尋找,終於被我找到了一篇 AWS 官方論壇的說明,裡面說明了他們把 DNS 設計成 TTL 會被改成 60 的情況,好拉!雖然覺得滿神奇的不過看來就是這樣設計
雖然如此小編依然沒辦法接受,後來又開了不一樣等級的機器,這次是新系列的機器等級是 t3.micro,結果如下:
clarence@ip-10-0-0-0:~$ dig @8.8.8.8 +nocmd +noall +answer +ttlid blog.clarence.tw | |
blog.clarence.tw. 300 IN A 104.31.80.250 | |
blog.clarence.tw. 300 IN A 104.31.81.250 |
挖嗚 ~ 竟然是 TTL 300 耶!不過只有測試一種 type 感覺不太準,因此又開了另一個等級的機器 c5.large,結果如下:
clarence@ip-10-0-0-0:~$ dig @8.8.8.8 +nocmd +noall +answer +ttlid blog.clarence.tw | |
blog.clarence.tw. 300 IN A 104.31.80.250 | |
blog.clarence.tw. 300 IN A 104.31.81.250 |
也是 TTL 300,這下好玩了,再測試一種好了, type 使用是 m5.large,結果如下:
clarence@ip-10-0-0-0:~$ dig @8.8.8.8 +nocmd +noall +answer +ttlid blog.clarence.tw | |
blog.clarence.tw. 300 IN A 104.31.80.250 | |
blog.clarence.tw. 300 IN A 104.31.81.250 |
看來結果出來了新機型的 type 不會影響 TTL 的時間,舊的機器 type 會影響 TTL 時間
重點整理一下
因此在這邊做一個整理,小編推測會引響 TTL 時間的 type 是 t2 與 c4 系列
- t2.nano
- t2.micro
- t2.small
- t2.medium
- t2.large
- t2.xlarge
- t2.2xlarge
- c4.large
- c4.xlarge
- c4.2xlarge
- c4.4xlarge
- c4.8xlarge
不會引響 TTL 時間的 type 是 t3 與 c5 系列
- t3.nano
- t3.micro
- t3.small
- t3.medium
- t3.large
- t3.xlarge
- t3.2xlarge
- c5.large
- c5.xlarge
- c5.2xlarge
- c5.4xlarge
- c5.8xlarge
以上是小編遇到的問題與重點整理,希望可以幫助到大家!
參考資料
- https://www.ibm.com/support/knowledgecenter/zh/ssw_aix_72/com.ibm.aix.cmds2/dig.htm
- https://dev.classmethod.jp/cloud/aws/dig-route53-begginer/
《AWS CDK 完全學習手冊:打造雲端基礎架構程式碼 IaC》
第 12 屆 iT 邦幫忙鐵人賽 DevOps 組冠的《用 CDK 定 義 AWS 架構》
第 11 屆 iT 邦幫忙鐵人賽《LINE bot 好好玩 30 天玩轉 LINE API》
一個熱愛分享的雲端工程師!