DHCP and DNS


DNS 尾碼

Q: 為何連線到某個 AP 內,出去的 request 有時會自動加上一個後綴?

Answer: 這個是由 Host 自動加上的 DNS 尾碼,由 DHCP 夾帶的資訊所設定的。

(先讀下面 DHCP 相關的資訊!) 我們知道 DHCP 會將一些網路設定包在 DHCP payload 中送給 client。 當中就有 DNS 的相關資訊,告訴 client 該跟哪個 DNS 來發送 DNS query。

相關欄位的設定:

可以從 DHCP Offer 封包當中看到這個 Options:

而 Host 端在發送封包到某個目標 url 時,DNS 會嘗試將 DNS 尾碼加在這個 url 後面 做發送。

舉例來說,在公司我們連線到特定的網域時,當中的 DHCP server 便會把相關的 network configuration 送給我們的電腦; 此時我們 Host 端便會將包在內部的 DNS 資訊做設定。 而當我們打 ping <主機名稱> 時,host 便會在後面加上所設定的 DNS 尾碼。

這也是為何我們在這個網域下 ping 我們的開發主機時會自動 append 一段網址的原因!

DHCP Overview - dhcp request

  1. DHCP discover (BCAST)
    • 由 client 發出 (觸發條件: 插入乙太網路、或是取得 wifi 連線時 etc)
    • 發出一個 Bcast IP 封包,向連線的網路中詢問有無可用的 DHCP server 可提供服務
  2. DHCP Offer (UCAST)
    • 當 DHCP server 收到這個指令時,將檢視內部的資源是否足夠 (e.g. IP address 是否滿了?)
    • 使用 Client 的 MAC address 作為儲存的 index/key
    • 若發現這筆 MAC address 已經存在,並且對應的 IP address (於上一個連線週期所使用) 還沒有被占用,則會將這個上一次連線的 configuration 作為該 client 的 network config 包在 DHCP offer 內傳給該 client/user。
    • 若發現資源符合,便會將
  3. DHCP Request (BCAST)
    • 當 user 收到第一筆回應時,選擇其提供的 network configuration 來做 user local 端的設定
    • 並且將 "該 user 已經選擇哪個 dhcp server" 的資訊廣播出去。 這個設計主要因為 network 當中可能不只一個 DHCP server,所以當 client 選擇某一個 DHCP server 的 offer 後,需要告知其他 DHCP server 不須等待這位 client。
  4. DHCP ACK (UCAST)
    • user 回應給已選定的 DHCP server,告知其已經選擇 server 所配置的資訊。
    • 而 server 便會開始做相關的租約計算 - DHCP IP 租約、以及處理當 DHCP client 離線時的 IP 資源回收。

擷圖 (注意: transaction ID 相同的為同一輪的 DHCP 交握~):

DHCP relay agent

當你的電腦與 DHCP server 不在同一個網段時,這時就需要依賴 DHCP relay agent 來轉發 DHCP 封包來維持 DHCP server 與 client 之間的通信。

舉公司內的網路為例,client 端為 192.168.98.x,而 DHCP server 為 192.168.99.33, 這時我們的 router 上就有 enable DHCP relay agent (也就是 192.168.98.1),將中間通信的 DHCP traffic 轉交給正確的位置上。

可以從 DHCP Offer 當中看到這個資訊!

Reference