Запись soa: Что такое SOA-запись и как ее проверить

01.06.2023 alexxlab

Содержание

Что такое SOA-запись DNS?

Хотя точное количество активных веб-сайтов постоянно меняется, в среднем, 175 новых сайтов создается каждую минуту! Это означает 252 000 новых веб-сайтов каждый день. Нет необходимости говорить о том, что пользователи должны вводить URL-адрес веб-сайта, чтобы попасть на нужную страницу; именно здесь начинается роль SOA-записи DNS.

Мы уже обсуждали, что такое запись DNS и ее типы. В этом посте вы узнаете, что такое запись DNS SOA. Продолжайте читать до конца, чтобы узнать о ее важности, структуре, процедуре и многом другом.

Что такое SOA-запись DNS?

Запись SOA или Start of Authority record — это тип записи DNS, содержащий такую важную информацию, как адрес электронной почты администратора, сроки обновления сервера, история обновления домена и т.д. Настройка SOA-записи в вашем соответствующем DNS важна для соответствия стандартам IETF (Internet and Engineering Task Force).

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

Что входит в типичную SOA-запись DNS?

Стандартная запись DNS SOA включает следующие сведения:

Первичный сервер имен домена.
Корреспонденция ответственного лица домена.
Временная метка, фиксирующая все сделанные обновления.
Количество секунд, оставшихся для обновления зоны.
Количество секунд, оставшихся для отбрасывания неудачного обновления.
Верхний предел в секундах до того, как зона будет помечена как неавторитетная.
Отрицательный результат TTL или Time-to-Live. TTL — это количество времени, в течение которого сохраняется пакет или данные.

Зачем нужна запись SOA?

Запись DNS SOA содержит подробную информацию о вашей зоне. Серверы имен DNS обычно создаются в кластерах, и база данных синхронизируется с помощью внутренней передачи зон. Любая зона без SOA-записи не соответствует протоколам IETF, и передача зоны невозможна. Таким образом, владельцы бизнеса, ориентированные на ИТ, должны знать, что такое SOA-запись DNS.

Что такое передача зоны в DNS?

Чтобы понять, как работают записи SOA, необходимо знать, что такое передача зоны в DNS.

Перенос зоны — это процесс репликации содержимого любой зоны на первичном сервере на все DNS-серверы. Это устраняет необходимость редактирования информации на нескольких серверах. Таким образом, вы можете редактировать информацию на основном сервере и копировать ее на другие, экономя время и усилия.

Как работают записи SOA?

DNS — это децентрализованная система, работающая по иерархической схеме. Так, серверы имен предоставляют информацию серверам, предназначенным для определенной зоны, путем администрирования всех файлов зоны. Это простые текстовые файлы, содержащие подробную информацию обо всех записях DNS. Эти записи содержат информацию по ряду вопросов, например, о том, был ли запрошен нужный сервер для решения той или иной задачи или нет.

Записи DNS SOA необходимы для кластеров серверов, поскольку они распределяют запросы между устройствами. Это позволяет избежать перегрузки конкретного сервера, которая может привести к сбою системы.

Передача зоны должна выполняться регулярно, чтобы файлы зон оставались активными на всех задействованных серверах. Однако ведомые серверы (серверы, расположенные ниже по иерархии) должны быть сопоставлены с ведущим сервером (единственный узел в конкретном домене, который поддерживает авторитетные карты).

Она определяет, как должна осуществляться и регулироваться передача зоны. Таким образом, запись DNS SOA получает все виды информации.

Структура записи SOA

Теперь, когда вы знаете, что такое SOA-запись DNS, пришло время немного узнать о ее структуре.

Как уже говорилось, запись DNS SOA содержит жизненно важную информацию, относящуюся к определенной зоне DNS или домену. Эта запись выстроена организованным образом, который легко воспринимается серверами и браузерами. Вот что входит в стандартную структуру записи SOA:

Серийный номер

Это номер ревизии файла зоны, который меняется при каждом изменении файла. Это значение должно быть изменено таким образом, чтобы внесенные изменения были распределены по всем DNS-серверам. В большинстве систем этот процесс происходит автоматически.

Основной сервер имен

Как следует из названия, это первичный DNS-сервер зоны. Он меняется на сервер по умолчанию, если вы вводите недопустимый первичный сервер имен.

Электронная почта администратора DNS

Это адрес электронной почты лица, ответственного за администрирование конкретных файлов DNS и зон. Если вы введете неправильный адрес электронной почты, он изменится на адрес по умолчанию.

Частота обновления

Частота обновления — это время в секундах, в течение которого вторичный сервер ждет, прежде чем запросить обновления у первичной записи DNS SOA. Частота обновления варьируется от 1200 до 43 200 секунд.

Скорость повтора

Частота повторных попыток — это время в секундах, в течение которого вторичный сервер ждет, прежде чем повторить попытку неудачной передачи зоны. Как правило, частота обновления больше частоты повторных попыток, и по умолчанию она составляет 1800 секунд. Однако он может варьироваться от 180 до 2 419 200 секунд.

Срок действия

Это время в секундах, в течение которого вторичный сервер пытается завершить передачу зоны. Если это время истекает до завершения передачи зоны, то срок действия файлов зоны также истекает. Вторичный сервер не будет отвечать на запросы, так как считает, что данные устарели. По умолчанию время истечения составляет 1 209 600 секунд.

TTL по умолчанию

TTL означает Time-to-Live, то есть период времени, в течение которого живет пакет или данные. Другие серверы используют это значение, чтобы узнать, как долго им следует хранить данные в кэше. Значение по умолчанию составляет 3 600 секунд или 1 час.

Проверка SOA-записей

Вы можете использовать специальные инструменты или веб-службы для проверки SOA-записи DNS вашего сайта. Для этого достаточно ввести соответствующий домен, и на следующей странице будет отображена запись ‘A’. Вы можете выбрать ‘SOA’ в соответствующем поле для проверки записей.

Публичный DNS позволяет даже установить дополнительные эффективные соединения с DNS; однако лишь ограниченные ресурсы предлагают это. Информация, получаемая через DNS, поступает от отправителя, а протоколами безопасности теоретически невозможно манипулировать.

Этот тип запроса на проверку SOA-записей выполняется в формате «вопрос-ответ». Вы можете запросить главный сервер, адрес электронной почты администратора и временные характеристики.

Вы можете проверить свою запись SOA с помощью нашего инструмента поиска записи SOA при регистрации на платформе PowerDMARC. Этот процесс является мгновенным и точным, а результаты выделяют ошибки в вашей записи, помогая вам быстрее устранить неполадки!

Заключительные размышления

Запись DNS SOA содержит конфиденциальную информацию, такую как адрес электронной почты администратора, сроки обновления сервера, историю обновления домена и т. д. Эти записи помогают в передаче зоны — процессе копирования содержимого любой зоны на все вторичные DNS-серверы. Это экономит время и усилия на ручную репликацию содержимого. Записи SOA распределяют запросы между различными серверами, чтобы избежать перегрузок и сбоев.

Предприятия, работающие в сфере инфотехнологий, должны соблюдать политика DMARC которая работает на основе протоколов SPF и DKIM. Вы должны опубликовать запись DMARC в DNS, чтобы проинструктировать почтовые ящики получателей о том, как обращаться с вашими письмами в соответствии с установленной политикой. Вы можете использовать анализатор DMARC чтобы получить представление о нескольких связанных с ним вопросах.

О сайте
Последние сообщения

Ахона Рудра

Менеджер по цифровому маркетингу и написанию контента в PowerDMARC

Ахона работает менеджером по цифровому маркетингу и контент-писателем в PowerDMARC. Она страстный писатель, блогер и специалист по маркетингу в области кибербезопасности и информационных технологий.

Последние сообщения Ахона Рудра (см. все)

Изменение начальной записи зоны

В начальной записи зоны объявляется полномочный сервер имен зоны и устанавливаются общие свойства зоны, например, интервалы повторов и обновлений.

Чтобы изменить параметры начальной записи зоны, выполните следующие действия:

1. В консоли Диспетчер DNS (DNS Manager) щелкните правой кнопкой зону, которую хотите обновить, и в контекстном меню выберите Свойства (Properties).

2. Перейдите на вкладку Начальная запись зоны (SOA) (Start Of Authority (SOA)) и обновите параметры.

На вкладке Начальная запись зоны (SOA) (Start Of Authority (SOA)) доступны следующие параметры:

• Серийный номер (Serial Number) Серийный номер отражает версию файлов БД DNS. Номер обновляется автоматически при внесении изменений в файлы зоны, но вы можете обновить его и вручную. По этому номеру дополнительные серверы определяют, изменилась ли зона. Если серийный номер основного сервера превышает серийный номер дополнительного сервера, записи изменились, и дополнительный сервер может запросить DNS-записи зоны. Кроме того, вы можете настроить DNS на уведомление дополнительных серверов об изменениях (что ускоряет процесс обновления).

• Основной сервер (Primary Server) Полное доменное имя сервера, в конце которого стоит точка. Точка обозначает конец имени и гарантирует, что к записи не будет добавлена информация о домене.

• Ответственное лицо (Responsible Person) Адрес электронной почты лица, ответственного за домен. По умолчанию здесь стоит имя hostmaster, за которым следует точка. Это обозначает адрес hostmaster@Ваш_домен.com. Если вы введете здесь другой адрес, замените точкой символ @ в адресе электронной почты и в конце адреса также поставьте точку.

• Интервал обновления (Refresh Interval) Интервал, через который дополнительный сервер проводит проверку обновлений зоны. Уменьшив его значение, вы сокращаете сетевой трафик. С другой стороны, его нельзя делать слишком большим, так как изменения NS-записей должны своевременно распространяться на дополнительный сервер.

• Интервал повтора (Retry Interval) Время после сбоя, в течение которого дополнительный сервер нс загружает БД зоны. Если задан интервал 10 минут, после сбоя передачи БД зоны дополнительный сервер ждет 10 минут, прежде чем отправить новый запрос.

• Срок жизни истекает после (Expires After) Период времени, в течение которого информация зоны на дополнительном сервере считается достоверной. Если дополнительный сервер в течение этого времени нс может загрузить данные с основного сервера, данные в кеше дополнительного сервера устаревают, и дополнительный сервер перестает отвечать на DNS-запросы.

• Мин. срокжизниТТL(по умолчанию) (Minimum (Default) TTL) Минимальное время жизни квитированных записей на дополнительном сервере. Когда это время заканчивается, дополнительный сервер считает срок действия соответствующей записи истекшим и сбрасывает ее. После этого необходимо отправлять очередной запрос на основной сервер. Делайте минимальный срок жизни относительно большим, скажем, 24 часа. Это сократит сетевой трафик и повысит производительность. С другой стороны, нужно помните, что высокое значение замедляет распространение обновлений через Интернет.

• Срок жизни (TTL) записи (TTL For This Record) Время жизни конкретной SOA-записи в формате: ДД: ЧЧ: ММ: СС. Как правило, оно должно совпадать с минимальным временем жизни всех записей.

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

Что такое запись SOA и зачем она нужна?
SOA — это аббревиатура от Start of Authority, это тип записи DNS, которая содержит важную информацию о зоне DNS, включая адрес электронной почты администратора, период обновления сервера и время последнего обновления домена.
Вам необходимо правильно настроить запись SOA в DNS, чтобы она соответствовала стандартам IETF (Internet and Engineering Task Force). Эти записи также необходимы при переносе зон. При переносе зон вам необходимо отправить записи DNS с основного сервера на дополнительный сервер. Во время этого процесса первой записью, которую вы должны отправить, является запись SOA. Ваш домен не будет работать должным образом, и поиск DNS не может выполняться без DNS 9.0007 Записи SOA .
Что такое серийный номер зоны?
Зона DNS — это определенный сегмент пространства имен DNS. Это может быть один домен, один домен и несколько поддоменов или несколько доменных имен.
Серийный номер зоны — это номер версии вашего домена DNS. Серийный номер зоны в сегменте SERIAL указан в структуре ниже. Когда серийный номер изменится, вторичный сервер узнает об изменениях и запросит перенос зоны.
Структура записи SOA
Запись SOA DNS содержит важную информацию о конкретной зоне или домене DNS. Эта запись имеет структуру, понятную как серверам, так и браузерам. Ниже приведен пример записи SOA.

имя mywebsite.com
тип записи СОА
МИМЯ ns.primaryserver.com
ИМЯ admin.mywebsite.com
СЕРИЙНЫЙ НОМЕР 121222321
ОБНОВЛЕНИЕ 46800
ПОВТОР 6200
Истечение срока действия 3000000
ТТЛ 36000
Давайте объясним формат в приведенной выше структуре записи SOA.
Имя: Это имя вашего домена. В приведенном выше примере это mywebsite.com 9.0100

Тип записи: Этот раздел определяет тип записи DNS; в данном случае это запись SOA.
MNAME: MNAME в приведенном выше формате представляет собой имя основного сервера домена.
RNAME: Содержит адрес электронной почты администратора без знака @. Таким образом, admin.mywebsite соответствует [email protected]
.
СЕРИЙНЫЙ НОМЕР: Это номер зоны DNS Увеличивайте значение серийного номера каждый раз, когда вы вносите изменения в файл зоны, чтобы обеспечить их распространение на все вторичные DNS-серверы.
ОБНОВЛЕНИЕ: Это временной интервал в секундах, в течение которого вторичный сервер ожидает отправки запроса на запись SOA первичного сервера для любых новых изменений.

ПОВТОР: Это время, в течение которого сервер должен ждать после неудачного обновления перед отправкой нового запроса.
EXPIRE: Период в секундах, в течение которого вторичный сервер будет продолжать запрашивать у первичного сервера обновления. По истечении этого времени срок действия файлов зоны вторичного сервера истекает, и он перестает отвечать на запросы.
TTL: Это время жизни, и оно применяется ко всем записям в зоне DNS.
Что такое передача зоны?
Это процесс, при котором файлы зоны DNS на первичном сервере копируются на вторичный сервер. Запись SOA в зоне DNS всегда передается первой. Передача зон обеспечивает отказоустойчивость за счет синхронизации файлов зон на первичном сервере с файлами зон на вторичном сервере.

Перенос зоны требуется в следующих случаях:
Если первичный DNS-сервер не работает, вторичный сервер будет иметь актуальную копию файлов зоны DNS и сможет успешно обрабатывать запросы разрешения DNS от DNS-клиентов в Интернете.
Если несколько DNS-клиентов в Интернете одновременно отправляют запросы, можно сбалансировать запросы между первичным и вторичным DNS-серверами.
Если первичный сервер имен находится в конце сети WAN слота, передача зоны позволяет вторичным серверам имен обрабатывать запросы разрешения локально, тем самым уменьшая сетевой трафик.
Дополнительный сервер инициирует передачу зоны, запрашивая у основного сервера, есть ли изменения в файлах зоны основного DNS-сервера.
Если существуют какие-либо изменения, он запрашивает перенос зоны. По истечении времени обновления сервера на вторичном DNS-сервере происходит следующее:
Второстепенный DNS-сервер получает запись Start of Authority (SOA) с первичного сервера.
Дополнительный DNS-сервер сравнивает серийный номер версии вновь полученной записи SOA с ее текущей версией. Если есть изменение, то он запрашивает перенос зоны.

В этом процессе все файлы зон DNS переносятся с первичных серверов на вторичные.
Резюме
В этой статье мы рассмотрели значение записей SOA и почему их необходимо включать в свой домен DNS. Записи SOA или Start of Authority DNS являются жизненно важной информацией, которая позволяет вашему домену функционировать должным образом.
Без этой записи передача зон невозможна. Запись SOA определяет скорость передачи обновлений зоны с главных серверов на подчиненные серверы.
Теперь, когда вы понимаете, что означает запись SOA, убедитесь, что вы настроили ее для всех своих доменов. Следите за новостями в блогах о типах записей DNS и используйте наш бесплатный инструмент поиска записей DNS для поиска записей DNS вашего домена.
Запись SOA — обучение NsLookup
Все зоны DNS начинаются с записи Start Of Authority (SOA). В записи SOA указано, что полномочия для зоны начинаются с определенной точки в глобальном дереве имен DNS.
Например, при создании новой зоны DNS для ohmcar.org (вымышленной компании по производству электромобилей) процесс создания зоны будет включать создание записи SOA на ohmcar.org.
Мы обсуждаем регистрацию домена в другой статье, а сейчас важно понимать, что создание зоны выполняется до регистрации домена, и что запись SOA является частью создаваемой новой зоны.
Обслуживание и создание записи SOA является задачей администратора DNS-сервера зоны. Обычно веб-мастеру домена не нужно добавлять или изменять запись SOA.
Запись SOA на ohmcar.org указывает, что зона DNS начинается с ohmcar.org и простирается вниз по дереву DNS, охватывая все DNS-имена, которые являются дочерними элементами ohmcar.org. Имена www.ohmcar.org и apps.backend.ohmcar.org будут частью этой зоны, как и само название ohmcar.org.
Запись SOA не просто указывает на существование зоны. Он также предоставляет некоторую важную информацию о зоне и управляет отрицательным кэшированием несуществующих имен в зоне. Подробнее об этом позже.
Записи DNS реплицированы (клонированы) между DNS-серверами с использованием конфигурации записи SOA. Автор: NsLookup.io. Под лицензией CC By 4.0.
Записи NS и окончание полномочий
Запись SOA запускает полномочия для зоны. Наряду с записью SOA существование зоны также определяется набором записей сервера имен (NS) в корне зоны. Комбинация ровно одной записи SOA и еще одной записи NS (обычно около 4) определяет вершину или корень зоны, где начинаются полномочия зоны.
Полномочия также могут заканчиваться в определенных точках дерева DNS ниже корня зоны в процессе, называемом делегированием. Мы подробно обсуждаем это в нашей статье о делегировании зоны, но в целом делегирование — это набор записей сервера имен (NS) с именем ниже корня зоны.
Сбивает с толку тот факт, что записи NS используются как в корне зоны для идентификации серверов имен для зоны, так и в точках ниже корня зоны в рамках делегирования. На данный момент важно только помнить, что записи NS в корне каждой зоны перечисляют серверы имен, которые являются полномочными для зоны, и вместе с записью SOA формируют базовую идентичность зоны.
Зоны и домены
Возможно, вы заметили, что в этой статье обсуждаются зоны DNS, а не домены DNS. Эти слова часто используются взаимозаменяемо.
Обычно слово домен используется для обозначения одной зоны или нескольких связанных зон. В последнем определении домен иногда описывает набор зон, принадлежащих одному объекту. Это скорее бизнес-определение, чем техническое определение DNS.
DNS работает только с зонами. Когда несколько зон делегируются одним контролирующим объектом, DNS по-прежнему рассматривает каждую зону отдельно. DNS не важно, кто контролирует каждую отдельную зону в дереве DNS-имен.
Какие поля данных SOA важны?
Запись SOA содержит несколько полей данных. Некоторые из этих полей относятся только к переносу зоны. Передача зоны — это DNS-протокол для копирования зоны DNS с одного DNS-сервера на другой, не связанный с владением зоной.
Передача зоны иногда используется, когда DNS-серверы нескольких хостинг-провайдеров являются авторитетными для зоны DNS, но передача зоны DNS сегодня менее актуальна, чем в прошлом.
Многие популярные поставщики облачных DNS, такие как Google, AWS, NS1 и Azure, вообще не используют передачу зоны. Вместо этого они используют проприетарные механизмы репликации базы данных, которые, как правило, превосходят перенос зоны. Если передача зоны не выполняется для определенной зоны, то время обновления, время повтора, время истечения срока действия и серийный номер будут игнорироваться.
Вообще говоря, для зоны, которая не будет использовать перенос зоны, важными полями являются:
Первичный сервер имен
Ответственное лицо
Минимальный TTL (для отрицательного кэширования)
TTL самой записи SOA
9013 3
Формат и поля записи SOA
Записи SOA имеют следующий формат:
[Имя владельца] [TTL записи SOA] SOA [MNAME] [RNAME] ( [Серийный номер] [Время обновления в секундах] [Время повтора в секундах] [Время истечения в секундах] [Минимальный TTL (TTL кэша отрицательных ответов)] )
Пример записи SOA DNS выглядит примерно так:
ohmcar.org 900 SOA ns1.ohmcar.org. admin.ohmcar.org. ( 17 7200 3600 86400 300 )
Имя владельца этой записи SOA — это имя зоны и, следовательно, точка, с которой начинаются полномочия зоны в дереве DNS.

В приведенном выше примере TTL записи SOA для ohmcar.org составляет 15 минут (900 секунд). Поля данных записи SOA объясняются ниже:
Первичный сервер имен (MNAME) для зоны, в данном примере ns1.ohmcar.org. Большинство зон имеют несколько серверов имен. В этом поле необходимо указать один из них. Неважно, какой сервер имен используется в этом поле: можно использовать любой из серверов имен, уполномоченных для этой зоны DNS, включая вторичные серверы имен, если они существуют.
Часто имена хостов серверов имен будут
ns1.ohmcar.org , ns2.ohmcar.org и т. д., но они могут быть любым допустимым именем хоста DNS. Их имена хостов могут быть внутри или вне зоны.
Ответственное лицо (RNAME) для зоны. Это адрес электронной почты, по которому можно сообщить о потенциальных проблемах с зоной.
Например, если спам или DDoS-атака исходили от ohmcar.org, то инженеры других организаций, расследующие эти инциденты, вероятно, отправят электронное письмо на адрес RNAME.
Это поле никогда не содержит символ
@ . Вместо этого первый период интерпретируется как @ . В этом примере значение ответственного лица admin.ohmcar.org будет означать адрес электронной почты [email protected] . Этот формат сложен для адресов электронной почты, которые включают точку перед символом @ , но DNS разрешает это с экранированием обратной косой черты, например, john\.smith.ohmcar.org будет интерпретироваться как [email protected] .
Текущий серийный номер зоны. Это поле используется во время переноса зоны для идентификации и различения различных версий зоны. Когда перенос зоны не используется, это поле в значительной степени игнорируется и часто не поддерживается администратором зоны.
При ведении серийных номеров они обычно имеют форму ГГГГММДДНН , где NN — порядковый номер, начинающийся с нуля и увеличивающийся при каждом изменении в течение дня. В качестве альтернативы серийный номер может быть просто целым числом, начинающимся с единицы, которое увеличивается при каждом обновлении зоны. Сохранение серийного номера зоны необязательно, если передача зоны не используется.
Время обновления в секундах. Это используется для передачи зоны и указывает, как часто вторичные серверы будут пытаться обновить свою копию зоны. Это поле не используется вне передачи зоны.

Время повтора в секундах. Это также используется для передачи зоны. Он указывает, как часто вторичные серверы должны повторять передачу зоны после сбоя. Это поле не используется вне передачи зоны.
Срок действия в секундах. Еще одно поле для передачи зоны. Если зона не может быть передана в течение этого времени, вторичные серверы должны отказаться от своей последней копии зоны и предположить, что зона находится в автономном режиме. Это поле не используется вне передачи зоны.
Минимальный TTL для зоны.

У этого поля интересная история. Сегодня он используется для отрицательного кэширования. Мы обсудим это более подробно ниже.
История
Запись SOA была введена в RFC 1034 и RFC 1035 еще в 1987 году как часть распределенной DNS первого поколения. Некоторые важные пояснения были добавлены в RFC 2181. В RFC 2308 было добавлено отрицательное поведение кэширования. RFC 8499 содержит более подробные и точные определения SOA. Многие другие RFC также упоминают запись SOA. Это один из самых основных типов записей в DNS.
Отрицательное кэширование
DNS использует ответ NXDOMAIN, чтобы указать, что DNS-имя в запросе не существует. Это будет использоваться, например, если пользователь делает опечатку в своем веб-браузере или каждый раз, когда запрашивается DNS-имя, которое не существует в зоне DNS. Преобразователи DNS кэшируют ответы NXDOMAIN, чтобы свести к минимуму количество запросов, которые они должны отправить. Это называется «негативным кэшированием».
Поле Minimum TTL было определено в RFC 1035 как минимальное значение TTL для всех записей в зоне, но это значение никогда не применялось на практике. RFC 2308 официально объявил устаревшим такое использование поля и переназначил его для отрицательного кэширования.
RFC 2308 «Отрицательное кэширование DNS-запросов (DNS NCACHE)» определяет, как отрицательное кэширование должно выполняться преобразователями DNS. Этот стандарт позволяет администратору каждой зоны DNS указать, как долго должны кэшироваться ответы NXDOMAIN для зоны.
Стоит отметить, что резолверы DNS-кэширования могут не следовать этому точно. Они могут изменить свое поведение в зависимости от политики или реализации, чтобы свести к минимуму размер кэша или попытаться уменьшить проблемы, вызванные временными ответами NXDOMAIN.
Резолверы DNS, которые следуют разделу 5 RFC 2308, должны кэшировать отрицательные ответы, или NXDOMAIN, в течение этого количества секунд:
мин (TTL записи SOA, минимальное значение TTL записи SOA)
Другими словами, кэширование NXDOMAIN время — это наименьшее значение собственного TTL записи SOA и минимального значения TTL внутри записи SOA. Например, если TTL SOA для ohmcar.org составляет 15 минут (900 секунд), а минимальное значение TTL внутри SOA составляет 5 минут (300 секунд), то преобразователи DNS должны кэшировать все отрицательные ответы ohmcar.org на 300 секунд.
Выбор отрицательного TTL кэша
Владельцу зоны DNS важно правильно установить отрицательное значение TTL кэша. Если ответы NXDOMAIN кэшируются в течение слишком короткого времени, количество запросов к серверам имен для зоны может быть больше, чем хотелось бы. С другой стороны, если ответы NXDOMAIN кэшируются слишком долго, это может вызвать проблемы.
В качестве примера предположим, что рабочий процесс для ohmcar.org включает создание новой записи DNS в зоне и последующий немедленный запрос ее. Если бы запрос поступил до того, как запись будет полностью реплицирована, то распознаватели могли бы ошибочно кэшировать NXDOMAIN для нового имени. Это может привести к тому, что клиенты не смогут получить доступ к новому ресурсу в течение отрицательного интервала кэширования.
Этот тип проблемы может привести к спорадическим, непредсказуемым сбоям, которые могут быть неприятными и трудными для отслеживания. Чтобы свести к минимуму это, выберите умеренно короткий отрицательный TTL кэширования, например 60 секунд, и будьте осторожны, чтобы не создавать рабочие процессы, в которых клиенты могут запрашивать новую запись DNS до того, как она будет полностью подготовлена и реплицирована.
Помните, что отрицательный TTL кэширования — это минимальное значение TTL записи SOA и минимальное значение TTL внутри SOA. Если вы выберете короткий TTL записи SOA, вы можете случайно указать более короткий отрицательный TTL кэширования, чем предполагалось!
Например, если для зоны минимальное значение TTL составляет 60 секунд, но значение TTL для самой записи SOA составляет всего 5 секунд, то преобразователи DNS будут использовать 5 секунд в качестве отрицательного TTL кэша для всех отрицательных ответов в этой зоне.
Предлагаемые значения
Для типичной зоны DNS, размещенной без передачи зоны, безопасными отправными точками являются следующие значения:
TTL самой записи SOA : 15 минут (900 секунд).
Первичный сервер имен : Любой из уполномоченных серверов имен для зоны.
Ответственное лицо : хорошо отслеживаемый адрес электронной почты для зоны, где @ заменен точкой.
Серийный номер : Дополнительно. Хорошим значением является значение, когда перенос зоны не используется.
Время обновления : Игнорируется. В целях безопасности установите значение один час (3600 секунд).
Время повтора : Игнорируется. В целях безопасности установите значение один час (3600 секунд).
Срок действия : Игнорируется. В целях безопасности установите один день (86400 секунд).
Минимальный TTL : 60 секунд для обеспечения баланса между сокращением количества ответов NXDOMAIN за счет кэширования и своевременным истечением срока действия нежелательных ответов NXDOMAIN.
Другие записи DNS в корне зоны
Запись SOA никогда не является единственной записью в корне зоны. В дополнение к ровно одной записи SOA в корне зоны должен быть набор записей сервера имен. В большинстве зон имеется около 4 записей сервера имен. Записи SOA и NS вместе образуют базовую идентификацию и определение зоны DNS.
Также обычно в корне зоны находятся другие записи DNS. Записи MX для включения доставки почты, записи TXT для безопасной доставки почты, записи CAA для указания сертификатов, DNSKEY и другие записи, если зона подписана безопасным образом, и потенциально многие другие. Мы рассмотрим эти типы записей в следующих статьях.

Существует один тип записи, который никогда не может существовать в корне зоны: CNAME. Записям CNAME запрещается сосуществовать с любыми другими типами записей под любым именем в глобальном дереве DNS. В прошлом некоторые реализации нарушали это правило, но сегодня большинство реализаций DNS корректно запрещают это. Может возникнуть соблазн попытаться внедрить CNAME в корень зоны, чтобы ohmcar.org и www.ohmcar.org разрешались одинаково, но это категорически запрещено в DNS.