☰

名稱伺服器的更改似乎沒有傳播

tag-icon • tag-icon domain-name-system domain-name nameserver
名稱伺服器的更改似乎沒有傳播

所以我只是更改了網頁伺服器，然後更改了受影響網域的名稱伺服器。我在新伺服器上複製了所有 DNS 記錄，以便轉換更容易，然後更改了名稱伺服器。但是，更改似乎沒有傳播 - 我可以看到它們現在指向新的名稱伺服器，但網站無法解析。

我使用他們的嚮導在 Plesk for Linux 中設定了這些 - 有什麼我應該或不應該做的事情嗎？

TIA。

編輯：

我運行了 DNSStuff.com 檢查，由於某種原因，我的新名稱伺服器指向我的舊名稱伺服器，如下所示：
ns0.hostedsupportal.com [64.128.190.5] ns1.dreamhost.com. ns2.dreamhost.com. ns3.dreamhost.com. 39ms

奇怪的。

答案1

hostedsupportal.com
        primary name server = ns1.dreamhost.com
        responsible mail addr = hostmaster.dreamhost.com
        serial  = 2009071403
        refresh = 15182 (4 hours 13 mins 2 secs)
        retry   = 1800 (30 mins)
        expire  = 1814400 (21 days)
        default TTL = 14400 (4 hours)

刷新設定為4h 13m 2s，等待傳播完成。耐心是一種美德 ：）

答案2

使用 dig（dig @<權威網域名稱伺服器> <主機或網域> 將是一個開始）來查看該網域的權威網域伺服器的目前設定。他們可能還沒有註意到這些變化（對於與託管網域關聯的網域伺服器，您可以編輯的記錄通常不是公共網域伺服器上的記錄，而是在託管公司擁有的流程驗證後複製到那裡；這與當然，在某些情況下或名稱伺服器實際上是您的機器）。即使該網域的主名稱伺服器具有新訊息，最近解析該網域並收到舊資訊的任何其他DNS 伺服器也會在TTL 時間內快取該訊息，並且在該時間到期之前不會再次解析該網域（這是如果您可以控制該記錄，那麼在進行 DNS 變更之前減少 TTL 時間的原因（舊版的 BIND 在 SOA 記錄中設定 TTL；TTL 也可以在單一資源記錄上設定）。

您可以使用 dig ( dig <主機或網域 > )來查看您的用戶端正在使用的名稱伺服器傳回的記錄，這應該表明它正在使用哪個版本以及剩餘的 TTL。

（我指的是上面的 dig，假設您使用的是 GNU/LINUX/BSD 用戶端，但我認為其他平台上也有該工具的版本）

（我也在閱讀你的編輯之前開始寫這篇文章——它最初是這樣設置的嗎？——如果是這樣，它仍然可能是一個緩存問題，TTL時間應該很好地表明這一點。不幸的是我不熟悉DNSStuff 是或其輸出，因此無法提供協助）

答案3

DNS 快取可能需要長達 48 小時才會逾時。你等了一兩天嗎？

相關內容