資安基礎惡補 - 網路篇 - SRV Record 的愛恨情仇

SRV 紀錄

不知道讀者們是否還記得我們在 上一篇 文章提到的 SRV 紀錄呢？

先來複習一下我在 GoDaddy 截圖的 DNS SRV Record 設定～也就是上面這張圖 XD

仔細看會看到幾個關鍵設定，如：

1. 服務（Service）：

指定提供的服務名稱，如 _sip（SIP 通訊協議）或 _xmpp（XMPP 即時通訊）等。

2. 協議（Protocol）：

指定使用的協議，如 _tcp 或 _udp 等。

3. 姓名（Name）：

為此 SRV 記錄所對應的 主機名稱（子域名），通常是 @（代表根域）或 email。

4. 值（目標，Target）：

提供該服務的「伺服器主機名」，如 host.domain.com。

5. 優先級（Priority）：

數字越小，優先級越高，伺服器會被優先使用。

6. 粗細（官方的翻譯有夠怪，應該是指「權數」，Weight）：

「權數」越高的伺服器，分配到的流量就越多，讓負載更均衡。

7. 端口（Port）：

表示該服務運行的 TCP / UDP 埠號，如 5060（SIP）、5222（XMPP）等。

8. TTL：

表示 DNS 快取時間，單位為秒，影響記錄多久才會刷新（例如 3600 ＝ 1 小時）。

在大致了解其基礎後，我們一起來看看實際的 SRV 記錄範例： 

_xmpp._tcp.kikasecures.com.86400 IN SRV 10 5 5223 chat.kikasecures.com.

而上述紀錄其實就是對應到如下（以下為 Chatgpt 幫忙整理的表格）：

唯一比較沒有特別說明到的是類別 Class，此處代表的是 Internet 類型的 DNS 紀錄，而 Internet 類型也是目前很廣泛使用的一種。

在了解其紀錄個別代表的涵義後，此時應該會有讀者心想：「有了這個 SRV 紀錄，那具體會怎麽運行啊？」

筆者就根據上述提到的「_xmpp._tcp.kikasecures.com.86400 IN SRV 10 5 5223 chat.kikasecures.com.」範例做講解：

1. 連線：

當 XMPP 客戶端（如 Pidgin、Gajim 等）連線 kikasecures.com 時，會查詢這條 SRV 記錄，並連線到 chat.kikasecures.com。

2. 使用協議：

連線時使用 TCP 協議，Port 為 5223。

3. 優先順序 10：

如果有多台伺服器，會「優先選擇數值較小」的。

4. 權重 5：

當多台伺服器的優先順序相同時，這個值影響流量分配。

如何查閱 SRV 紀錄？

如果你是使用 macOS / Linux，使用 nslookup 就可以了～

nslookup -q=SRV kikasecures.com

不過，這時候你可能會踩到一個坑...

有可能會遇到「No Answer」的情況 XD 會遇到這樣的情況可能的原因是「該網域沒有設置 SRV 紀錄」。

這時候就需要觀察，你的這個 Domain 是否有對應的 A 、 AAAA record～

以 A 紀錄為例，我們可以使用以下的指令：

nslookup -q=A kikasecures.com

這時候，你可能會看到我們的網站有兩個 IP ~

但是實際上不能真的用該 IP 直接去訪問（因為伺服器後面有 CDN），如下圖：

那麼，這時候可能讀者會有疑問：「我要怎麼確定有用 CDN ？」

很簡單，萬用 nslookup 大法，加上剛剛查到的 IP 就行了！

這邊表示有用到 AWS 的 CDN，如果想要進階查詢 AWS CDN 的 NetRange 則可以使用 whois + ip ，如：

就會得到以下的結果（13.244.0.0 - 13.251.255.255）

好的，廢話這麼多@@ 讓我們回到正題「找到 A、AAAA Record 可以幹嘛？」

在找到紀錄後，我們基本上可以確認幾點：

1. A 記錄可確認該域名是否已啟用 DNS

在查詢過程中，如果 A 記錄也不存在，那就代表「這個網域還沒有對應到任何伺服器」，自然也不可能有 SRV 記錄。

2. 若 A 記錄查詢成功，再進一步確認 SRV 記錄

如果 A 記錄存在，但 SRV 記錄查不到，那可能只是「服務沒有設定 SRV 記錄」，而是透過其他方式運作（例如 A 記錄 + 特定 port）。

那依照先前的結果我們可以知道 DNS 是有正確被啟用的，只是查不到 SRV 紀錄。

如果想要排查錯誤，可以往這幾個方向看，如：

1. SRV 記錄沒有正確設定

2. SRV 記錄未公開或受到限制 

有些 DNS 提供商（如 Cloudflare）可能不支援 SRV 記錄解析，或預設不會對外提供這些記錄。

3. 本機 DNS 伺服器未更新

參考資源

Cloudfare SRV 紀錄：

https://www.cloudflare.com/zh-tw/learning/dns/dns-records/dns-srv-record/

延伸閱讀

在大致了解 SRV Record 之後，應該就可以嘗試研究看看最近（2024）的 LDAPNightmare 攻擊，或許就能了解其中的 SRV 查詢到底是在幹嘛了 XD

相關新聞：https://www.ithome.com.tw/news/166868