Получаем информацию из DNS: SOA
Рубрика: Shell
Метки: dns | Linux | команды Linux
Пятница, 27 марта 2009 г.
Просмотров: 16092
Подписаться на комментарии по RSS
Вопрос. С помощью какой команды можно узнать SOA запись в DNS для любого домена из шелла UNIX / Linux shell?
Ответ. получить SOA (start of authority record) — запись о сервере, хранящем эталонную конфигурацию в DNS, можно с помощью команд dig или host в UNIX или Linux.
Получаем SOA используя команду host
<code>$ host -t soa {domain.com}
$ host -t soa ya.ru</code>Результат:
ya.ru has SOA record ns1.yandex.ru. sysadmin.yandex.ru. 2009031101 10800 900 2592000 900
Получаем SOA используя команду dig
<code>$ dig SOA {domain.com}
$ dig SOA ya.ru</code>Результат:
; <<>> DiG 9.3.4-P1 <<>> SOA ya.ru ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23933 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 9 ;; QUESTION SECTION: ;ya.ru. IN SOA ;; ANSWER SECTION: <span>ya.ru. 6546 IN SOA ns1.yandex.ru. sysadmin.yandex.ru. 2009031101 10800 900 2592000 900</span> ;; AUTHORITY SECTION: ru. 165718 IN NS E.DNS.RIPN.NET. ru. 165718 IN NS NS.RIPN.NET. ru. 165718 IN NS NS2.NIC.FR. ru. 165718 IN NS NS2.RIPN.NET. ru. 165718 IN NS NS5.MSK-IX.NET. ru. 165718 IN NS NS9.RIPN.NET. ru. 165718 IN NS SUNIC.SUNET.SE. ;; ADDITIONAL SECTION: E.DNS.RIPN.NET. 108935 IN A 193.232.142.17 NS.RIPN.NET. 108935 IN A 194.85.105.17 NS2.NIC.FR. 103861 IN A 192.93.0.4 NS2.NIC.FR. 103860 IN AAAA 2001:660:3005:1::1:2 NS2.
RIPN.NET. 108935 IN A 194.226.96.30 NS5.MSK-IX.NET. 108935 IN A 193.232.128.6 NS9.RIPN.NET. 108935 IN A 194.85.252.62 SUNIC.SUNET.SE. 97662 IN A 192.36.125.2 SUNIC.SUNET.SE. 97662 IN AAAA 2001:6b0:7::2 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Mar 27 14:17:30 2009 ;; MSG SIZE rcvd: 405
ru. IN SOA
;; ANSWER SECTION:
<span>ya.ru. 6546 IN SOA ns1.yandex.ru. sysadmin.yandex.ru. 2009031101 10800 900 2592000 900</span>
;; AUTHORITY SECTION:
ru. 165718 IN NS E.DNS.RIPN.NET.
ru. 165718 IN NS NS.RIPN.NET.
ru. 165718 IN NS NS2.NIC.FR.
ru. 165718 IN NS NS2.RIPN.NET.
ru. 165718 IN NS NS5.MSK-IX.NET.
ru. 165718 IN NS NS9.RIPN.NET.
ru. 165718 IN NS SUNIC.SUNET.SE.
;; ADDITIONAL SECTION:
E.DNS.RIPN.NET. 108935 IN A 193.232.142.17
NS.RIPN.NET. 108935 IN A 194.85.105.17
NS2.NIC.FR. 103861 IN A 192.93.0.4
NS2.NIC.FR. 103860 IN AAAA 2001:660:3005:1::1:2
NS2.
Замените домен ya.ru на нужный вам.
Получаем SOA используя команду nslookup
nslookup -type=SOA ya.ru
Результат:
Non-authoritative answer:
ya.ru
origin = ns1.yandex.ru
mail addr = sysadmin.yandex.ru
serial = 2009031101
refresh = 10800
retry = 900
expire = 2592000
minimum = 900
Authoritative answers can be found from:
ru nameserver = NS5.MSK-IX.NET.
ru nameserver = NS9.RIPN.NET.
ru nameserver = SUNIC. SUNET.SE.
ru nameserver = E.DNS.RIPN.NET.
ru nameserver = NS.RIPN.NET.
ru nameserver = NS2.NIC.FR.
ru nameserver = NS2.RIPN.NET.
E.DNS.RIPN.NET internet address = 193.232.142.17
NS.RIPN.NET internet address = 194.85.105.17
NS2.NIC.FR internet address = 192.93.0.4
NS2.NIC.FR has AAAA address 2001:660:3005:1::1:2
NS2.RIPN.NET internet address = 194.226.96.30
NS5.MSK-IX.NET internet address = 193.232.128.6
NS9.RIPN.NET internet address = 194.85.252.62
SUNIC.SUNET.SE internet address = 192.36.125.2
SUNIC.SUNET.SE has AAAA address 2001:6b0:7::2
Постовой
Совсем недавно переезжал в Москве с одной квартиры на другую. Могу с уверенностью сказать, что это был переезд стоивший мне настоящие копейки. Воспользовался услугами компании «Альянс Плюс» и совершенно не жалею.
Еще записи по теме
- Отправка почты с помощью командлета Send-MailMessage…
- Добавление DNS серверов с помощью DNS-add
- Как найти файлы с определенным содержимым в Unix
- Удаленное добавление службы SNMP в Windows 7
- Как использовать команду DsQuery для поиска контроллеров домена?
- Linux: запускаем необходимые команды после перезагрузки системы
- Alias — создаем алиасы для ваших команд
az network dns record-set soa
Обратная связь
Twitter LinkedIn Facebook Адрес электронной почты
- Ссылка
Управление записью SOA DNS.
Команды
| az network dns record-set soa show | Получение сведений о записи SOA. |
| az network dns record-set soa update | Обновление свойств записи SOA. |
az network dns record-set soa show
Изменить
Получение сведений о записи SOA.
az network dns record-set soa show --resource-group
--zone-nameПримеры
Получение сведений о записи SOA.
az network dns record-set soa show -g MyResourceGroup -z www.mysite.com
Получение сведений о записи SOA (автоматически созданной)
az network dns record-set soa show --resource-group MyResourceGroup --subscription MySubscription --zone-name www.mysite.com
Обязательные параметры
—resource-group -g
Имя группы ресурсов. Вы можете настроить расположение по умолчанию с помощью az configure --defaults group=<name>.
—zone-name -z
Имя зоны.
Глобальные параметры
—debug
Повышение уровня детализации журнала для включения всех журналов отладки.
—help -h
Отображение этого справочного сообщения и выход.
—only-show-errors
Показывать только ошибки, блокируя предупреждения.
—output -o
Формат вывода.
—query
Строка запроса JMESPath. Дополнительные сведения и примеры см. на сайте http://jmespath.org/.
—subscription
Имя или идентификатор подписки Подписку по умолчанию можно настроить с помощью az account set -s NAME_OR_ID.
—verbose
Повышение уровня детализации журнала. Чтобы включить полные журналы отладки, используйте параметр —debug.
az network dns record-set soa update
Изменить
Обновление свойств записи SOA.
az network dns record-set soa update --resource-group
--zone-name
[--email]
[--expire-time]
[--host]
[--if-none-match]
[--minimum-ttl]
[--refresh-time]
[--retry-time]
[--serial-number]Примеры
Обновление свойств записи SOA.
az network dns record-set soa update -g MyResourceGroup -z www.mysite.com \ -e myhostmaster.mysite.com
Обновление свойств записи SOA. (автоматически создано)
az network dns record-set soa update --email myhostmaster.mysite.com --only-show-errors --resource-group MyResourceGroup --subscription MySubscription --zone-name www.mysite.com
Обязательные параметры
—resource-group -g
Имя группы ресурсов. Вы можете настроить расположение по умолчанию с помощью az configure --defaults group=<name>.
—zone-name -z
Имя зоны.
Необязательные параметры
—email -e
Электронная почта.
—expire-time -x
Истекает время (в секундах).
—host -t
Имя узла.
—if-none-match
Создайте набор записей, только если он еще не существует.
—minimum-ttl -m
—refresh-time -f
Значение обновления (в секундах).
—retry-time -r
Время повтора (в секундах).
—serial-number -s
Порядковый номер.
Глобальные параметры
—debug
Повышение уровня детализации журнала для включения всех журналов отладки.
—help -h
Отображение этого справочного сообщения и выход.
—only-show-errors
Показывать только ошибки, блокируя предупреждения.
—output -o
Формат вывода.
—query
Строка запроса JMESPath. Дополнительные сведения и примеры см. на сайте http://jmespath.org/.
—subscription
Имя или идентификатор подписки Подписку по умолчанию можно настроить с помощью az account set -s NAME_OR_ID.
—verbose
Повышение уровня детализации журнала. Чтобы включить полные журналы отладки, используйте параметр —debug.
Обратная связь
Отправить и просмотреть отзыв по
Эта страница
Просмотреть все отзывы по странице
Запись SOA — изучение NsLookup
Типы записей DNSСкопировать ссылку на статью
765Z» title=»Written March 3, 2022″> Обновлено 29 сентября 2022 г. Все зоны 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-серверами. Фото Annie SprattЗаписи NS и окончание полномочий
Запись SOA запускает полномочия для зоны. Наряду с записью SOA существование зоны также определяется набором записей сервера имен (NS) в корне зоны. Комбинация ровно одной записи SOA и еще одной записи NS (обычно около 4) определяет вершину или корень зоны, где начинаются полномочия зоны.
Полномочия также могут заканчиваться в определенных точках дерева DNS ниже корня зоны в процессе, называемом делегированием. Мы подробно обсуждаем это в нашей статье о делегировании зоны, но в целом делегирование — это набор записей сервера имен (NS) с именем ниже корня зоны.
Сбивает с толку тот факт, что записи NS используются как в корне зоны для идентификации DNS-серверов зоны, так и в точках ниже корня зоны в рамках делегирования.
На данный момент важно только помнить, что записи 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
Формат и поля записи SOA
[TTL записи SOA] SOA [MNAME] [RNAME] ( [Серийный номер] [Время обновления в секундах] [Время повтора в секундах] [Время истечения в секундах] [Минимальный TTL (TTL кэша отрицательных ответов)] )
Пример записи DNS SOA выглядит примерно так:
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, включая вторичные серверы имен, если они существуют. Часто имена хостов серверов имен будут 9.0060 ns1.ohmcar.org
ns2.ohmcar.orgи т. д., но они могут быть любым допустимым именем хоста DNS. Их имена хостов могут быть внутри или вне зоны. - Ответственное лицо (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.
Вместо этого следует использовать другие решения этой проблемы.
Поиск записи SOA для зоны
Запись SOA зоны можно запросить с помощью инструментов командной строки dig или nslookup. Чтобы найти запись SOA для wikipedia.org, используйте следующую команду:
dig SOA wikipedia.org
В операционных системах, поддерживающих nslookup, вы можете использовать следующее:
nslookup -type=soa wikipedia.org
Вы можете также проверьте запись SOA любого доменного имени в нашем инструменте поиска SOA или введите его здесь:
Имя домена
Что такое запись SOA в DNS?
Записи DNS представляют собой набор инструкций, хранящихся на DNS-серверах. Они содержат информацию о домене и сообщают серверам, как выполнять для него DNS-запросы.
Мы обсудили несколько типов записей DNS, включая запись A, запись NS, запись DNS MX, запись TXT и запись CNAME. В этом посте мы познакомим вас с записями SOA в DNS.
Начнем с одного вопроса: Что такое запись SOA ?
Что такое запись SOA и зачем она нужна?
SOA — это аббревиатура от Start of Authority, это тип записи DNS, который содержит важную информацию о зоне DNS, включая адрес электронной почты администратора, период обновления сервера и время последнего обновления домена.
Вам необходимо правильно настроить запись SOA в DNS, чтобы она соответствовала стандартам IETF (Internet and Engineering Task Force). Эти записи также необходимы при переносе зон. При переносе зон вам необходимо отправить записи DNS с основного сервера на дополнительный сервер. Во время этого процесса первой записью, которую вы должны отправить, является запись SOA. Ваш домен не будет работать должным образом, и поиск DNS не может выполняться без DNS 9.0204 Записи SOA .
Что такое серийный номер зоны?
Зона DNS — это особый сегмент пространства имен DNS. Это может быть один домен, один домен и несколько поддоменов или несколько доменных имен.
Серийный номер зоны — это номер версии вашего домена DNS. Серийный номер зоны в сегменте SERIAL указан в структуре ниже. Когда серийный номер изменится, вторичный сервер узнает об изменениях и запросит перенос зоны.
Структура записи SOA
Запись DNS SOA содержит важную информацию о конкретной зоне или домене DNS. Эта запись имеет структуру, понятную как серверам, так и браузерам. Ниже приведен пример записи SOA.
| имя | mywebsite.com |
| тип записи | СОА |
| МИМЯ | ns.primaryserver.com |
| ИМЯ | admin.mywebsite.com |
| СЕРИЙНЫЙ НОМЕР | 121222321 |
| ОБНОВЛЕНИЕ | 46800 |
| ПОВТОР | 6200 |
| ИСЧЕЗ | 3000000 |
| ТТЛ | 36000 |
Давайте объясним формат в приведенной выше структуре записи SOA.
- Имя: Это имя вашего домена. В приведенном выше примере это mywebsite.com 9.0036
- Тип записи: В этом разделе определяется тип записи 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.