調查自行建置EdgeDNS服務

4 min

conohadnsnginxhttp雑記vps
language: ja bn en es hi pt ru zh-cn zh-tw

大家好，我是無能。

最近ConoHa當然發生了故障，而且後端伺服器在不知不覺中掛掉（順帶一提，透過主機遷移已解決），這令人煩惱，因此我正在嘗試如何自行建置Edge DNS。

在CNAME中註冊的記錄上註冊兩個A記錄

做法如下

$ dig www.soulminingrig.com

; <<>> DiG 9.20.16 <<>> www.soulminingrig.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33051
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.soulminingrig.com.         IN      A

;; ANSWER SECTION:
www.soulminingrig.com.  300     IN      CNAME   edge.soulminingrig.com.
edge.soulminingrig.com. 300     IN      A       91.98.169.80
edge.soulminingrig.com. 300     IN      A       163.44.113.145

;; Query time: 94 msec
;; SERVER: 192.168.1.1#53(192.168.1.1) (UDP)
;; WHEN: Mon Apr 06 20:40:33 JST 2026
;; MSG SIZE  rcvd: 101

根據RFC規定，根網域只能註冊一個 CNAME，因此實際上無法註冊。因此，我們註冊 www.soulmingrig.com 的 CNAME，內容為 edge.soulminingrig.com.，並註冊兩個 edge.soulminingrig.com. 的A記錄。

或許會有人問，為什麼不直接為根網域指定多個A記錄呢？這是為了未來的擴展性而註冊在 CNAME 中。

我嘗試了這樣做會發生什麼，我懷疑ConoHa的DNS是不是使用了PowerDNS？並驗證了以下內容。

  • 停止伺服器 91.98.169.80

  • 只讓 163.44.113.145 運行

如果只是單純的循環負載均衡，我以為流量會流向 91.98.169.80，但流量卻完全只流向 163.44.113.145。這讓我懷疑PowerDNS是否可能使用了健康檢查功能。

※官方只說是循環負載均衡，請勿完全相信此推測

GeoDNS，很困難

這是為了從最適合的區域向客戶端分發內容，但越想越覺得輕鬆實現很困難。

即使在FreeBSD上，套件也太少，甚至 GeoIP.bat 檔案的資料庫似乎也不再分發了，但或許在某處仍在分發？

https://gist.github.com/denji/9487759

從現實角度來看，在Nginx端進行分發在個人環境中似乎變得相當實際。那麼，如何輕鬆地在Nginx端進行分發呢？

那麼各區域的速度差異...

這次新增的是位於德國的閒置伺服器。

就是 91.98.169.80 這個。因此從日本來看，響應延遲相當嚴重。

因此我會修改核心參數設定，盡可能地掙扎一下。並新增包含 TCP Fast Open 在內的以下設定。

TCP BBR 原本在設定時就已啟用，但即使如此，我感覺在正確加入 KeepAlive 後情況有所改善。

net.ipv4.tcp_congestion_control=bbr
net.core.default_qdisc=fq
net.ipv4.tcp_keepalive_time=60
net.ipv4.tcp_keepalive_intvl=10
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_no_metrics_save=1
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_fastopen=3

如果能好好測量，就不會有錯了...

現在 GeoIP 的路程似乎還很遙遠，這只是暫時的應對措施。

向具有多個A記錄的HTTP伺服器分發憑證

這件事啊，讓我傷透了腦筋。

原因是我正在使用 certbot 進行更新，我原以為如果使用 certbot 進行DNS驗證，就可以在兩個A記錄的伺服器上都進行更新，但事情並沒有那麼簡單。

結論是我採取了相當強硬的手段，從專用使用者那裡 rsync 憑證。

0 0 1,15 * * /usr/local/bin/certbot renew --nginx --deploy-hook "/usr/local/bin/rsync -azL --no-perms --no-owner --no-group --omit-dir-times --no-times /usr/local/etc/letsencrypt/live/ certsync@10.1.0.999:/usr/local/etc/letsencrypt/live/"

我其實不想這樣做，但似乎可以使用 --deploy-hook 在更新後執行類似子shell的命令。

原因是當 certbot 在具有多個A記錄的伺服器上進行ACME挑戰以獲取憑證時，我原以為流量會分散到其中一個，導致一個成功一個失敗，但不知為何，它只在最初發行憑證的伺服器上成功？(這在規範上有些說不通，我感覺有些蹊蹺) 而預設的 certbot 在檔案驗證時，會暫時放置檔案，一旦ACME挑戰通過，就會立即刪除臨時檔案，因此在循環負載均衡的環境中，實際上應該會分配到其中一個伺服器。

至於DNS 驗證，我放棄了，因為不能使用 --nginx 選項來自動動態添加 nginx 端的憑證檔案，但實際上憑證路徑並不會改變，現在回想起來，覺得 DNS 驗證會更好，這完全是我當時糊塗了...

因為可以透過ConoHa API進行DNS記錄的變更通知，所以實際上這樣就可以解決了...

Related Posts