Назад | Перейти на главную страницу

сайт показывает неверный сервер в некоторых браузерах после смены DNS

Недавно Ive передал домен новому регистратору и указал его на новый сервер в записях A. Некоторые компьютеры показывают правильный сервер, но пугающе некоторые из них показывают старый. Я не думаю, что это проблема кеширования браузера, поскольку даже компьютеры, которые никогда раньше не посещали сайт, показывают старую страницу.

Я проверил распространение DNS с помощью нескольких онлайн-чекеров, и они, похоже, показывают правильный IP.

Что может вызвать такое поведение? и что я могу сделать, чтобы исправить это?

«Недавно» - термин нечеткий. Если TTL для старых записей был 86400, то можно ожидать, что DNS-преобразователям потребуется до 24 часов, чтобы истечь эту запись. Если «недавно» означает «в течение последнего дня», то, вероятно, все работает, как ожидалось.

Поскольку вы также сменили регистратора, есть записи, отличные от записи A, которые могут быть кэшированы, такие как ваши NS-записи и связующее звено в родительском. Эти записи часто имеют даже более длительный TTL - два дня, неделю или даже 10 дней.

Некоторые DNS-преобразователи кэшируют записи дольше, чем позволяет TTL. Все, что использует Baidu Spider, является примером этого. Я видел, как они обращались к старым IP-адресам через три недели после истечения срока действия TTL. Если DNS-преобразователь, который вы используете, делает это, вы можете застрять в использовании старого сайта на долгое время, если вы не измените DNS-преобразователь, который вы используете.

Вы можете проверить, какие записи кэшируются и сколько времени осталось до истечения срока их действия на определенном преобразователе DNS, используя dig. Это пример проверки общедоступных DNS-преобразователей Google:

$ dig @8.8.8.8 example.com

; <<>> DiG 9.6-ESV-R4-P3 <<>> @8.8.8.8 example.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21902
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.           IN  A

;; ANSWER SECTION:
example.com.        18820   IN  A   93.184.216.119

;; Query time: 8 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Oct  3 12:45:19 2013
;; MSG SIZE  rcvd: 45

Число в разделе ответов после имени домена показывает, как долго этот преобразователь будет продолжать кэшировать этот результат. Вы также можете проверить записи NS:

$ dig @8.8.4.4 example.com NS

; <<>> DiG 9.6-ESV-R4-P3 <<>> @8.8.4.4 example.com NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60519
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com.           IN  NS

;; ANSWER SECTION:
example.com.        6121    IN  NS  b.iana-servers.net.
example.com.        6121    IN  NS  a.iana-servers.net.

;; Query time: 7 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Oct  3 12:48:19 2013
;; MSG SIZE  rcvd: 77

Кеширование DNS. Плохое программирование - поэтому некоторые браузеры кэшируют старую страницу намного дольше, чем вы планировали. Новый сервер является «плохим» в том смысле, что он не обрабатывает запросы IMS (If Modified SInce) должным образом, хотя браузер запрашивает правильно.

В основном это так. Вы должны проверить эти машины, но либо некоторые DNS по пути все еще кэшируют (некоторые делают это дольше, чем ваш TTL), либо браузер не запрашивает сервер. Или сервер сообщает, что страница не изменилась из-за неправильных отметок времени в файловой системе.