Comments 10
- В статье написано всё верно, но я не понял цель и смысл её публикования (да ещё и предварительного перевода). Или нам ждать от mail.ru в следующей статье информацию с доказательствами теоремы Пифагора ?
- Если же уж опубликовали, то в конце статьи уже от собственного лица дали бы рекомендации вебмастерам в разрезе dns — как то: a) не размещать DNS-records на ns-серверах хостера б) пользоваться специализированными DNS-хостингами (с кучей anycast серверов) причём их (dns-хостингов) должно быть как минимум два разных — связанных связкой: Primary/Secondary — тогда и ns-сервера менять часто не придётся (при смене хостинга) да и вероятность проблем с доступностью сайта из-за dns сведётся практически к нулю.
- Первая причина понятна из статьи — решите Вы хостинг поменять — придётся и ns-сервера менять а это долго !
- Как правило у хостеров (даже больших) ns-сервера расположены максимум на двух физических серверах. Соответственно вероятность сбоя существена (например за полгода два раза уже сайты размещённые на Бегете были недоступны именно из-за падения ns-серверов).
- Этот пункт не особо важен, но как правило ns-сервера хостеров поддерживают исключительно только самые распростанённые dns-records (к примеру dnssec, tlsa и srv — не поддерживают). Но повторюсь что этот пункт не так уж важен.
Часто один из днс серверов физически расположен там же где и ваш сайт.
Спрашивается, в случае его падения, вам будет легче от того что днс работает, но сам сайт нет? В большинстве случаев без разницы, упал ли сайт с днс или только сайт, а днс нормально работает… направляя посетителей на нерабочий ip.
Исключение может быть лишь если у вас на уровне днс реализовано какое-то жонглирование хостингами какраз на случай падения одного из них. Или же если MX направлена куда-то в другое место, тогда да, даже если сайт упадет, хотелось бы чтоб почта продолжала работать.
Но не забываем за минусы стороннего днс хостинга:
а) Это всеж дополнительное звено цепи и потенциальная point of failure. Даже у великолепных cloudflare с гуглами случаются проблемы.
б) Масштабы несоизмеримы. Прикиньте количество доменов у днс хостинга и хостинга вашего сайта. Скорость ответа наверняка будет достаточно заметна.
в) В случае ЧП или просто какой-то технической необходимости хостер сможет оперативно сменить ip вашего сайта без вашего участия. В противном случае вы сами себе увеличиваете время даунтайма если вдруг будет необходимость смены ip сайта — сервер упал/заддосен и всех быстро переключили на другой ip… кроме вас потому что вы самый умный и пользуетесь чужими ns. :)
а) Есть разница по времени простоя когда оно состоит только из разворачивания бекапа у стороннего хостера или из разворачивиния бекапа ПЛЮС время пока новые ns поменяются?
б) Вот в последних двух сбоях у Бегета сами сервера с сайтами работали а падали только ns-ки
Я же писал в первом сообщении:
причём их (dns-хостингов) должно быть как минимум два разных — связанных связкой: Primary/Secondary
Уж всяко надёжнее чем у "обычных" хостеров!
3.
Куча anycast серверов по всему миру у нормальных dns-хостеров даст "скорость" всяко лучше чем стандартные два сервера у "обычных" хостеров отведённые под ns.
Вот отлично, изучили принципы работы DNS по выводу команды dig! А если бы был nslookup, так и не судьба? Остались бы мы жить непросвещёнными?
Без описания записи SOA и её полей serial, refresh, retry, expire и ttl эта статья в значительной степени бесполезна, а в некоторых аспектах и вредна.
Кратенький совет: если вы видите, что после обновления какой-либо записи в DNS зоне вашего домена, serial значение не изменилось, то меняйте DNS провайдера — их уровень компетенции ниже плинтуса.
Что происходит, когда вы обновляете свой DNS
Происходит полный треш! Так и надо было написать.
Что происходит, когда вы обновляете свой DNS