沒有子網域 (www) 的網站寄存的 DNS 設定

Question

我一直在嘗試尋找一種更優雅的解決方案，以便為我的網站伺服器和我在其上託管的少數網站提供更好的 DNS 更新。

因此，您在 VPS 供應商處有一個網頁伺服器，例如帶有網域名稱apache1.vpshost.com。如果我希望我的網站有一個網域www.example.com託管在該網站伺服器上，我可以簡單地在其中放入 CNAME 記錄，其中表示www.example.com為apache1.vpshost.com。這樣做的好處是，如果網站伺服器的 IP 位址發生變化，您只需在一個地方進行更新，該網站託管的所有網站都會正常。

刪除www.來自網址的運動日益盛行，但據我所知，這樣做的唯一方法是將根 A 記錄設定為相同的 IP 位址，因為apache1.vpshost.com您無法將根 dns 設為 CNAME。我認為這樣做的主要缺點是，如果網頁伺服器的 IP 位址發生變化，那麼您將無法更新所有託管網址上的所有 dns 設定。

我已經多次嘗試用谷歌搜尋這個問題，但如果有更好的解決方案，我會迷失在雜草中，因為我的搜尋字詞非常常見。

Answer 1

目前對於“CNAME at apex”用例沒有好的解決方案。如果網頁瀏覽器確實支援 DNS 記錄，那不會有問題，SRV但它們從來沒有也永遠不會

各種 DNS 提供者都提供各種拼湊的東西，有時稱為「或」ANAME或APEXCNAME「ALIAS或」。重要的一點是這裡沒有什麼是標準的。它將以某種方式出現在他們的UI/API 上，它不能按原樣複製到另一個提供者（如果您更改），當然它根本不會出現在DNS 解析端，因為它們會以某種方式（或者當請求到來時動態地，或者透過預先填充的一些快取）根據配置為頂點生成A並回复。AAAA

從技術上講，它確實涉及擁有一個基本上具有遞歸性的權威名稱伺服器，因為在某些時候它確實需要將您在「假」中使用的名稱解析CNAME為某個 IP 位址。

這就是為什麼未來的 DNS 記錄稱為SVCB或HTTPS最終解決這個問題。由於 IETF RFC 仍在編寫中，它們尚未完全標準化，但它們已經存在於 DNS 中並分配了資源記錄類型，並且各種公司（Apple、Google、CloudFlare 等）已經在使用它們。

無論如何，我建議只在這個未來萬無一失的標準解決方案上投入時間（因此找到支持它們的DNS 提供商，並觀察瀏覽器如何/何時使用它們，他們“都”說他們會這樣做），而不是把時間投入到當前的混亂中，因為它們低劣的、不標準的，並且必然會在上述新 DNS 記錄的出現中消失。