Что такое SOA-запись DNS и как ее проверить
Одной из наиболее важных считается SOA запись DNS, в которой указаны базовые сведения о домене. И хотя они никак не сказываются на работе домена, они необходимы для функционирования системы. Чтобы сайт работал корректно, его владельцу приходится учитывать множество специфических параметров, настроек. Однако в случае SOA всё довольно просто.
Что такое SOA записи и зачем они нужны
SOA record или в переводе SOA запись расшифровывается как «Start Of Authority» и означает «Начало Зоны».
Дело в том, что доменные серверы объединены в кластеры. Их базы данных синхронизируются за счет передачи зон.
Зона – это логическое пространство, совокупность ресурсных записей домена. То есть она объединяет доменные имена нескольких ваших ресурсов и хранит сведения о них.
SOA – начальная запись зоны. В ней прописаны сведения, необходимые для полноценного обмена: ее идентификаторы, время кэширования информации, контакты администратора и т.
д. То есть без нее обмен невозможен.
Особенности типа записи SOA
У этого параметра есть 3 ключевые особенности:
- Запись формируется автоматически. Это сильно облегчает процесс настройки в случае запуска сайта.
- Стереть ее невозможно. Она удаляется автоматически при удалении зоны.
- Если в зоне не прописана SOA, она не соответствует стандарту RFC 1035, поэтому не может использоваться для различных IP-узлов.
Для корректной работы системы важно не только присутствие записи, но и правильный синтаксис. Например, время обычно указано в секундах, а в e-mail нужно писать точку вместо привычного символа @.
Указанный в SOA сервер считается приоритетным для динамического DNS. Сначала изменения происходят на нем, а потом передаются на другие серверы.
Какую информацию содержит DNS SOA запись
Здесь отображены параметры, необходимые для обеспечения стабильной связи DNS-серверов.
- SOA TTL – это промежуток времени, в рамках которого кэшируется информация, предназначенная для передачи через DNS-серверы.
- MNAME — это отсылка к DNS-серверам, где хранятся другие ресурсные записи.
- Hostname или RNAME — электронная почта администратора зоны.
- Serial number — серийный номер файла зоны. При любых изменений его значение повышается. Это сигнал вторичным серверам о том, что пора обновлять данные.
- Refresh — время, отведённое под запрос данных от вторичного DNS-сервера к первичному. Если получен ответ, что Serial number изменён, сведения на вторичном сервере в обязательном порядке обновляются.
- Retry — время, отведённое под обновление данных, если в первый раз этого не произошло.
- Expire — промежуток времени, когда сведения о зоне могут применяться на вторичном сервере. Когда время заканчивается, но данные при этом не успевают обновиться, запросы о данной зоне перестают обрабатываться.
- Minimum TTL — время хранения в кэше информации о зоне.
Выглядит запись так:
Другие сведения располагаются в таких типах записей, как CNAME, A, NS, TXT и т.
д. Это оптимальное разделение, поскольку упрощает считывание данных, за счет чего сокращается вероятность сбоев или ошибок.
Как проверить SOA запись
Посмотреть сведения в SOA записи можно в веб-интерфейсе хостинга. Для этого нужно ввести адрес сайта и выбрать из списка выбрать пункт «SOA и TTL».
Так как посмотреть DNS-записи домена иногда нужно более подробно, стоит выбрать пункт «С трассировкой», в выдаче появятся запрашиваемые адреса с ответами серверов. Так можно определить, через какие серверы и за какой промежуток времени проходят запросы.
Дополнительно можно поставить галку в пункте «Текстовый ответ». В этом случае под активной формой отобразятся все параметры записи.
При необходимости записи можно редактировать. Чтобы внести изменения, заполните форму и нажмите кнопку «Применить». Для изменения доступны все поля кроме «host». Он указывает на первичный сервер доменных имён.
Если все верно, можно сделать выгрузку.
Иногда при тестировании других записей хостинг всплывают предупреждения.
Например, сообщения «soa serial number format is invalid» или «soa expire value out of recommended range». В этом случае запись нужно привести к стандарту, для этого лучше обратиться в техподдержку хостинга.
Подводим итоги
SOA содержит простую, структурированную информацию для корректного обмена между DNS-серверами. Запись формируется автоматически, и арендаторам хостинга нет необходимости ее настраивать. Но в случае возникновения вопросов или сбоев в работе сайта вы всегда можете проверить запись и обратиться в сервис техподдержки.
1 февраля 2019 года ваш сайт может перестать работать / Хабр
Cisco является одним из крупнейших DNS-провайдеров в мире, предоставляя услугу безопасного DNS на базе Cisco Umbrella (ранее OpenDNS), но речь сегодня пойдет не о ней и даже не о безопасности. Дело в том, что 1-го февраля наступит так называемый DNS Flag Day, после которого ваш сайт может быть недоступен пользователям в Интернет.
О чем идет речь? Протокол DNS был разработан в начале 80-х годов. С тех пор много воды утекло и в протокол DNS понадобилось добавить новые функции и возможности. Такая работа была начала в 1999 году, когда в виде RFC 2671 была опубликована первая версия расширений под названий EDNS0 (Extension Mechanism for DNS). Данная версия позволила снять некоторые ограчения, например, на размер некоторых полей флагов, кодов возврата и т.п. Текущая версия расширенного протокола EDNS описана в RFC 6891. При этом в Интернет продолжали существовать DNS-сервера, которые не поддерживали и не поддерживают EDNS, создавая тем самым определенные сложности при взаимодействии, необходимости обеспечивать обратную совместимость, что в свою очередь приводит как к замедлению работу всей системы DNS, так и к невозможности в полной мере реализовать все новые возможности EDNS.
Но этой вакханалии пришел конец — с 1-го февраля неподдерживающие стандарт EDNS сервера будут недоступны и попасть на них будет невозможно.
Будут внесены изменения в самое популярное ПО, отвечающее за работу DNS — Bind, Knot Resolver, PowerDNS и Unbound, которое будет принимать только соответствующий стандарту EDNS трафик. Трафик со старых и необновленных серверов будет рассматриваться как нелегитимный и эти сервера обслуживаться не будут, что может привести к недоступности доменов, которые «висят» на этих серверах.
Для большинства компаний DNS Flag Day пройдет незамеченным, так как многие DNS-провайдеры уже обновляют или обновили свое ПО до необходимых версий. Сложности могут возникнуть у тех компаний, кто самостоятельно поддерживает собственные DNS-сервера, а также многих госорганов, которые не слишком оперативно обновляют ПО в своей инфраструктуре, не имея на это либо средств, либо квалифицированных специалистов. В результате с 1-го февраля сайты многих ведомств могут стать недоступны или столкнуться с проблемами с доступом.
Проверить перспективы доступа к своему сайту в феврале 2019-го года достаточно просто — надо всего лишь зайти на сайт dnsflagday.
net, ввести там имя своего домена и получить результат, который будет иметь разные значения. В идеале вы должны увидеть картинку, аналогичную той, которая показана ниже для сайта cisco.ru:
Если вы видите картинку, аналогичную той, которая выдается, например, для сайта АНО «Цифровая экономика», то это означает, что сайт работать будет, но он не поддерживает последний стандарт DNS и не сможет в полном объеме реализовать необходимые функции безопасности и может стать мишенью для хакеров, которые могут (а вдруг) атаковать этот сайт.
Первые две картинки из этой заметки с красными знаками дорожного движения — это самое плохое, что вы можете увидеть. Лучше поскорее обновить ПО, обеспечивающее работу вашего DNS. На сайте dnsflagday.net вы можете получить все необходимые инструкции и ссылки для того, что актуализировать свое ПО. Там же есть ссылки и на различные утилиты для администраторов, которые позволяют сканировать свою DNS-инфраструктуру в поисках слабых мест.
В завершение заметки я не могу не коснуться вопросов безопасности. Дело в том, что некоторые межсетевые экраны могут блокировать DNS-пакеты длиной более 512 байт (с расширениями EDNS), что может приводить к реализации DoS-атак (например, МСЭ может блокировать DNS cookies, которые являются частью EDNS и предназначены как раз для защиты от DoS-атак) и снижению скорости в Интернет. Поэтому стоит обратить внимание на правила ваших МСЭ, так как раньше это было достаточно распространено и многие уже просто забыли, когда и зачем добавлялись правила в свои средства сетевой периметровой безопасности.
До наступления DNS Flag Day остается меньше двух недель — еще достаточно времени на то, чтобы начать соответствовать стандарту и не снижать лояльность клиентов и граждан, которые, столкнувшись с недоступностью или замедленной работой вашего сайта, начнут нелицеприятно высказываться об этом в соцсетях.
Разумеется, говорить о глобальном апокалипсисе не стоит. Более того, для многих этот день, как я написал выше, пройдет и вовсе незамеченным.
Но настройки DNS в этот день будут менять многие провайдеры, что может сказаться на доступности некоторых сайтов. Это риск, о котором стоит знать и к которому надо быть готовым.
— предупреждение «Неверный формат серийного номера SOA» от mxtoolbox.com — почему?
спросил
Изменено 9 месяцев назад
Просмотрено 46 тысяч раз
При тестировании параметра SOA для примера-domain.org на http://mxtoolbox.com/ он говорит, что
Неверный формат серийного номера SOA
Запись:
ns-885.awsdns-46.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
Это именно то, что Amazon предлагает в своей документации Route 53 на http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/SOA-NSrecords.
mxtoolbox выдает предупреждение — почему? Они также считают ошибкой отсутствие настроек DMARC.
Пожалуйста, потерпите меня — я не системный администратор. Любая подсказка, использующая язык, понятный разработчику, приветствуется.
- система доменных имен
- amazon-route53
- soa-record
Рекомендуется, чтобы серийный номер SOA использовал формат, состоящий из четырех цифр года, двух цифр месяца, двух цифр дня и две цифры количества изменений в тот же день. Этот формат является распространенным, но далеко не универсальным (посмотрите на
2
Поле SOA SERIAL указано как целочисленное значение без знака, которое имеет специальные правила для того, как оно обертывается, и, следовательно, как сравниваются серийные номера и т.
д.
RFC1035 определяет это поле как:
СЕРИЙНЫЙ НОМЕР
Беззнаковый 32-битный номер версии оригинальной копии зона. Передача зоны сохраняет это значение. Это значение обертывания и должны сравниваться с использованием пространства последовательностей арифметика.
Арифметика серийных номеров подробно описана в RFC1982.
Во всяком случае, популярный «формат» ГГГГММДДnn — это просто соглашение для выбора целочисленных значений, которые при записи в десятичном виде передают некоторую значимую информацию людям (может быть полезной при устранении неполадок). Использование таких значений не имеет особого значения в самой системе, и использование значений, не соответствующих этому соглашению, не является ошибкой.
mxtoolbox выдает предупреждение, если ваш серийный номер не соответствует XXXXMMDDnn 
Повторите попытку через несколько часов, не касаясь серийного номера, и предупреждение исчезнет.
Просто для тех, кто не понимает, о какой части записи идет речь, это «1». Итак, это…
ns-885.awsdns-46.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400
можно заменить на это (скажем, для первого изменения сегодня)…
ns-885.awsdns-46.net. awsdns-hostmaster.amazon.com. 2022080201 7200 900 1209600 86400
То есть ГГГГММДДнн равно комбинации года, месяца, дня и количества изменений, сделанных сегодня, начиная с 01. Надеюсь, это поможет прояснить ситуацию для нетехнических людей. 🙂
Зарегистрируйтесь или войдите в систему
Зарегистрируйтесь с помощью Google
Зарегистрироваться через Facebook
Опубликовать как гость
Электронная почта
Требуется, но не отображается
Опубликовать как гость
Электронная почта
Требуется, но не отображается
Нажимая «Опубликовать свой ответ», вы соглашаетесь с нашими условиями обслуживания, политикой конфиденциальности и политикой использования файлов cookie
.
— изменение серийного номера DNS SOA для зоны
Задавать вопрос
спросил
Изменено 8 лет, 7 месяцев назад
Просмотрено 6к раз
Недавно я стал владельцем DNS в нашей среде. Все, что я знаю о DNS, это только то, что я исследовал в Google. Это, как говорится, вот мое текущее затруднительное положение:
У нас есть 5 DNS-серверов MS в нашей среде. Рассматриваемая зона, скажем, abc.com, настроена как первичная/дополнительная в Windows 2008.
Пытаясь понять, почему люди думают, что первичный сервер «умирает», я заметил, что обновления в первичном не реплицируются на вторичные.
Все 5 серверов перечислены на вкладке Name Servers. Флажок «Разрешить передачу зон» установлен с установленным флажком «Только на серверы, перечисленные на вкладке «Серверы имен».
Основываясь на том, что я прочитал, я думаю, что проблема в том, что серийные номера SOA не совпадают между первичным сервером и вторичными серверами:
Сервер 1 - основной - 992473
Сервер 2 - вторичный - 992475
Сервер 3 - вторичный - 992544
Сервер 4 - вторичный - 992542
Сервер 5 - вторичный - 992549
Я прав в этом предположении? Если да, то могу ли я просто вручную изменить серийный номер SOA в основной зоне на что-то вроде 2476. Если я это сделаю, то все вторичные серверы должны автоматически обновляться с основного?
- система доменных имен
1
Действительно, если ваша главная зона имеет больший серийный номер, чем все ваши подчиненные, ваши подчиненные должны синхронизироваться с ней.