Comments 10
  1. В статье написано всё верно, но я не понял цель и смысл её публикования (да ещё и предварительного перевода). Или нам ждать от mail.ru в следующей статье информацию с доказательствами теоремы Пифагора ?
  2. Если же уж опубликовали, то в конце статьи уже от собственного лица дали бы рекомендации вебмастерам в разрезе dns — как то: a) не размещать DNS-records на ns-серверах хостера б) пользоваться специализированными DNS-хостингами (с кучей anycast серверов) причём их (dns-хостингов) должно быть как минимум два разных — связанных связкой: Primary/Secondary — тогда и ns-сервера менять часто не придётся (при смене хостинга) да и вероятность проблем с доступностью сайта из-за dns сведётся практически к нулю.
  1. Первая причина понятна из статьи — решите Вы хостинг поменять — придётся и ns-сервера менять а это долго !
  2. Как правило у хостеров (даже больших) ns-сервера расположены максимум на двух физических серверах. Соответственно вероятность сбоя существена (например за полгода два раза уже сайты размещённые на Бегете были недоступны именно из-за падения ns-серверов).
  3. Этот пункт не особо важен, но как правило ns-сервера хостеров поддерживают исключительно только самые распростанённые dns-records (к примеру dnssec, tlsa и srv — не поддерживают). Но повторюсь что этот пункт не так уж важен.

Часто один из днс серверов физически расположен там же где и ваш сайт.
Спрашивается, в случае его падения, вам будет легче от того что днс работает, но сам сайт нет? В большинстве случаев без разницы, упал ли сайт с днс или только сайт, а днс нормально работает… направляя посетителей на нерабочий ip.
Исключение может быть лишь если у вас на уровне днс реализовано какое-то жонглирование хостингами какраз на случай падения одного из них. Или же если MX направлена куда-то в другое место, тогда да, даже если сайт упадет, хотелось бы чтоб почта продолжала работать.


Но не забываем за минусы стороннего днс хостинга:
а) Это всеж дополнительное звено цепи и потенциальная point of failure. Даже у великолепных cloudflare с гуглами случаются проблемы.
б) Масштабы несоизмеримы. Прикиньте количество доменов у днс хостинга и хостинга вашего сайта. Скорость ответа наверняка будет достаточно заметна.
в) В случае ЧП или просто какой-то технической необходимости хостер сможет оперативно сменить ip вашего сайта без вашего участия. В противном случае вы сами себе увеличиваете время даунтайма если вдруг будет необходимость смены ip сайта — сервер упал/заддосен и всех быстро переключили на другой ip… кроме вас потому что вы самый умный и пользуетесь чужими ns. :)

  1. а) Есть разница по времени простоя когда оно состоит только из разворачивания бекапа у стороннего хостера или из разворачивиния бекапа ПЛЮС время пока новые ns поменяются?
    б) Вот в последних двух сбоях у Бегета сами сервера с сайтами работали а падали только ns-ки


  2. Я же писал в первом сообщении:


    причём их (dns-хостингов) должно быть как минимум два разных — связанных связкой: Primary/Secondary


Уж всяко надёжнее чем у "обычных" хостеров!
3.
Куча anycast серверов по всему миру у нормальных dns-хостеров даст "скорость" всяко лучше чем стандартные два сервера у "обычных" хостеров отведённые под ns.

Вот отлично, изучили принципы работы DNS по выводу команды dig! А если бы был nslookup, так и не судьба? Остались бы мы жить непросвещёнными?


Без описания записи SOA и её полей serial, refresh, retry, expire и ttl эта статья в значительной степени бесполезна, а в некоторых аспектах и вредна.


Кратенький совет: если вы видите, что после обновления какой-либо записи в DNS зоне вашего домена, serial значение не изменилось, то меняйте DNS провайдера — их уровень компетенции ниже плинтуса.

Почему-то «We’ve forgotten something important though! TTLs!» переведено как «Но мы забыли кое-что важное. Это пакеты TTL». Откуда тут взялись пакеты? Ну то есть, у IP-пакета есть поле TTL, но это совсем другой TTL, который никакого отношения к TTL записей DNS не имеет. Поправьте, что ли…
Что происходит, когда вы обновляете свой DNS


Происходит полный треш! Так и надо было написать.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
team.mail.ru
Employees
5,001–10,000 employees
Registered

Habr blog