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

Что могло привести к прекращению распространения DNS?

Я переместил домен Godaddy (ihearthawaii.com) в каплю цифрового океана около 15 часов назад. Отслеживая распространение DNS через такие сайты, как (whatsmydns.net), я замечаю, что распространение затруднено. Он будет распространяться на определенные серверы, но примерно через час исчезнет с них. Это происходило весь день. Это почти как что-то одновременно отменяет распространение. Час назад у меня было 8 зеленых галочек, а сейчас только 5.

Кто-нибудь видел что-нибудь подобное раньше? Есть ли способ исправить это?

Я использую серверы имен digitalocean, и, похоже, они в порядке. Я также пробовал intodns и dnscheck в поисках проблем с конфигурацией, но ничего особенного.

В DNS не может распространяться по всему миру казалось, проблема исчезла сама собой. Но мне интересно, как выяснить причину таких явлений.

Файл моей зоны из Digital Ocean

$TTL    1800
@       IN  SOA NS1.DIGITALOCEAN.COM.   hostmaster.ihearthawaii.com. (
        1398835453 ; last update: 2014-04-30 05:24:13 UTC
        3600 ; refresh
        900 ; retry
        1209600 ; expire
        1800 ; ttl
        )
         IN      NS      NS1.DIGITALOCEAN.COM.
                 NS      NS2.DIGITALOCEAN.COM.
                 NS      NS3.DIGITALOCEAN.COM.
@   IN A    128.199.249.146
www CNAME   @

Изменение DNS-серверов вашим регистратором обычно занимает до 48 часов, независимо от TTL, установленного вами для записей NS в вашей зоне. 

dig +trace www.ihearthawaii.com

показывает, что для меня обновления распространяются правильно и ваш домен разрешается так, как вы ожидаете.

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> +trace www.ihearthawaii.com
;; global options: +cmd
.                       8843    IN      NS      a.root-servers.net.
.                       8843    IN      NS      b.root-servers.net.
<snip>
.                       8843    IN      NS      m.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 145 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
<snip>
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 510 bytes from 192.36.148.17#53(192.36.148.17) in 141 ms

ihearthawaii.com.       172800  IN      NS      ns1.digitalocean.com.
ihearthawaii.com.       172800  IN      NS      ns2.digitalocean.com.
ihearthawaii.com.       172800  IN      NS      ns3.digitalocean.com.
;; Received 153 bytes from 192.48.79.30#53(192.48.79.30) in 295 ms

www.ihearthawaii.com.   1800    IN      CNAME   ihearthawaii.com.
ihearthawaii.com.       1800    IN      A       128.199.249.146
;; Received 68 bytes from 198.199.120.125#53(198.199.120.125) in 94 ms

Эта опция трассировки показывает, как работает разрешение, от корневых серверов до корневых серверов домена верхнего уровня .com, где домен ihearthawaii.com делегируется ns <1-3> .digitalocean.com с TTL 48 часов , пока адрес www.ihearthawaii.com не будет разрешен.

Низкий TTL для ваших записей DNS в вашей собственной зоне может способствовать нестабильному поведению, поскольку некоторые из корневых серверов (например, a.gtld-servers.net) уже были обновлены с вашими новыми DNS-серверами и другими (например, m.gtld-servers.net) может нет.

Поэтому, когда кэширующий DNS-сервер мог использовать a.gtld-servers.net и обнаружил ns1.digitalocean.com в качестве авторитетного DNS-сервера, по истечении 30-минутного периода кеширования он мог быть направлен на m.gtld-серверы. .net и обнаружил старую NS-запись регистратора, указывающую на ваши старые серверы имен.

Ваш низкий TTL для ваших адресов приводит к тому, что ваши записи выходят из кеша задолго до обновления записей сервера имен. Ваш TTL должен быть не меньше TTL для ваших записей NS.

Если вы можете хранить свои записи на старом сервере до истечения времени ожидания NS-записей, все будет в порядке. Срок действия старых записей NS истечет в течение нескольких дней, и ваши проблемы с распространением разрешатся сами собой. Все должно проясниться через 2 дня (172800 секунд).

Перед изменением записей рекомендуется сократить время жизни записей. Я не уверен, разрешают ли ваши провайдеры изменять TTL для записей NS. По крайней мере, за два дня до изменения я бы уменьшил TTL для записей NS примерно до часа (или 1800, поскольку это то, что вы используете в своих записях).

Я следую этому процессу:

  • Уменьшите TTL при изменении записей примерно до часа до изменения. (Минимум 1 TTL.)
  • Значительно уменьшите TTL (до 5 минут или около того) по крайней мере за 1 TTL до изменения.
  • Внесите изменения и проверьте распространение. Внесите любые исправления (должно появиться через несколько минут).
  • Увеличьте TTL до часа или двух и еще раз проверьте распространение.
  • Увеличьте TTL до пары дней или более, когда все станет стабильно.

Некоторые из основных DNS-серверов будут переопределять ваш TTL, чтобы не поддерживать DNS-серверы fast-flux. Вероятно, вы захотите получить доступ по старому IP-адресу в течение дня или около того.