"Dns"
- ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑
在 Ubuntu 的 ufw 主機上用 Docker 發佈連接埠、想只放行 Cloudflare 的位址、或想限制容器送出的 DNS 查詢時，查 ufw 規則對發佈連接埠的效果、DOCKER-USER 規則在 reload 與重開機之後還在不在、IPv6 那一份發佈由誰接收，以及 compose 容器的 DNS 封包從哪裡送出
- 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序
一台主機上的服務要暫停一段時間再恢復：只停服務、停止主機、終止主機保留設定、全部刪除靠 repo 重建各自保留什麼與付出什麼，怎麼依保留的月費、重建的成本與漂移量選擇，暫停期間仍在計費的資源（含在作業系統裡 shutdown 不停止計費），仍被 DNS 與 CDN 指向的結果（Cloudflare 521、522，釋放 IP 之後的懸空 DNS），恢復前要重新確認的漂移，以及依元件依賴排出的恢復順序與驗證
- 流量入口層 — 請求怎麼從使用者到達應用
自管環境要決定請求從使用者到應用經過哪幾層入口、每層承擔什麼——TLS 終結的位置、動靜分離、單機 reverse proxy 與雲端負載平衡器的選擇
- 域名與 HTTPS 怎麼接上
服務跑在一個 IP 上了、但不知道買的域名怎麼指過去、網址前面的鎖頭（HTTPS）憑證從哪來時回來讀 — 域名解析與 TLS 的最小認識
- 安裝期套件與網路故障排除：pacman / DNS / mirror / keyring
剛裝好系統第一次抓套件就失敗（pacman 報錯、DNS 解不出、mirror 逾時、簽章過期、db lock）、要判斷是網路層還是套件管理器狀態時回來讀
- 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS
服務結束時網域與名稱的去向，以及它們決定外部引用是失效還是易手：網域的續約與出售、交給中立方的技術控制、套件與雲端資源名稱釋出後被重新申請與佔位、雲端資源刪除後的懸空 DNS 與子網域接管，以及綁在可過期網域上的帳號身分
- ACM 憑證、DNS 與 HTTPS 設定
從 Route 53 hosted zone 到 ACM 憑證申請、DNS 驗證、ALB HTTPS listener 與 HTTP 重導的完整設定流程
- 斷網環境的基礎服務：DNS、NTP、CA 與 Secret Management
斷網環境裡其他所有服務的前提——內部 DNS 做名稱解析、NTP 做時間同步、內部 CA 簽發 TLS 憑證、Vault 管理機密值。這四個服務先部署、其他才能跟上。
- 本機 DNS proxy 插在第一順位時，VPN 的短暫失聯會放大成全機解析故障
git / curl 回 Could not resolve host 而直連 IP 通、或同一個域名時好時壞時，用來定位是整條網路斷了、還是解析路徑上多了一個會單獨失效的本機 DNS proxy