Разное

Soa начальная запись зоны – Страница не найдена | REG.RU

20.11.2018

Запись «Start Of Authority» | http://info.nic.ru

В данном материале мы обсудим одну из самых важных записей описания ресурсов «Start of Authority»(SOA). Именно эта запись определяет ту зону, к которой относятся все описания ресурсов — прочие Resource Records.

Описание зоны по традиции начинают с записи SOA (Start Of Authority). На самом деле, после 1998 года, когда появился документ RFC 2308, описание зоны начинают с директивы управления $TTL, которая задает время хранения соответствий в кэше resolver или сервера доменных имен.

Запись SOA отмечает начало описания зоны. Обычно, это первая запись описания ресурсов (Resource Record — RR). Настоятельно рекомендуется наличие одной и только одной записи типа SOA в каждом файле описания зоны, который указан в записи primary файла named.boot или в директиве zone файла named.conf.

Формат записи SOA можно представить как:

[zone] [ttl] IN SOA origin contact (serial refresh retry expire minimum)

В этой записи каждое из полей обозначает следующее:

Поле zone — имя зоны. Если речь идет о зоне, описанной в записи primary файла named.boot, то в качестве имени употребляется символ коммерческого эт — «@». В этом случае в качестве имени текущей зоны берется имя, указанное в качестве первого аргумента команды primary из файла named.boot, или имя зоны, указанное в директиве zone файла named.conf.

Поле зоны обязательно должно быть указано, иначе named не сможет привязать следующие за данной записью описания ресурсов к имени зоны. Пустое имя зоны не является допустимым.

Можно, конечно, указывать и полное имя зоны, не забывая при этом ставить на конце имени «.»:

kyky.ru. IN SOA ns.kyky.ru adm.kyky.ru ( 2 8h 30m 2w 2h )

Поле

ttl в записи SOA всегда пустое. Дело в том, что время кэширования для записей описания зоны задается либо последним аргументом данных записи SOA (версии BIND до 8.2.), либо директивой управления $TTL. Запрет на кэширование SOA определен в RFC 1035.

Вообще говоря, данное жесткое ограничение (наличие 0 в поле ttl) было снято в 1997 году (RFC 2181). Связано это было с тем, что реально требование наличия нуля в поле ttl записи SOA нигде не использовалось и не проверялось. С тех пор записи SOA могут содержать значения в поле ttl.

Поле origin — это доменное имя primary master сервера зоны. В случае описания зоны kyky.ru в качестве сервера используется машина ns.kyky.ru. Данное доменное имя и должно быть указано в поле origin.

Очень часто в этом поле можно встретить имена, которые начинаются с «ns», например, ns.kiae.su или ns.relarn.ru. В данном случае это означает только то, что primary master сервер зоны размещен на машине с таким именем. Никого специального зарезервированного имени для указания в поле origin нет. Использование, указанных выше имен обосновано тем, что их просто легче запомнить, т.к. «ns» означает «name server».

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

Elz и Bush в RFC-2181 отмечали, что это требование повсеместно нарушается и практически является бесполезным. Кроме того, существует документ (ripe-203), в котором написано, что данное требование (отличие имени primary master сервера от имени зоны в SOA) справедливо, за исключением случая, когда доменное имя зоны связано адресной записью с IP-адресом primary master этой зоны. Для небольших зон это случается сплошь и рядом, т.к. и primary master зоны и почтовый транспортный агент и прочие сервисы в мелких организациях устанавливаются на одной и той же машине.

Требование, однако, справедливо при заполнении интерактивных форм регистрации домена, т.к. система в момент регистрации не имеет ни малейшего понятия о том, что администратор зоны напишет в файле описания зоны, т.е. гарантии того, что имя зоны и имя primary master сервера совпадают, в момент регистрации домена нет.

Поле contact определяет почтовый адрес лица, осуществляющего администрирование зоны. Данный адрес должен совпадать со значением адреса указанным в заявке на домен. Есть, однако, одна особенность при указании этого адреса. Так как символ «@» имеет особый смысл при описании зоны, то вместо этого символа в почтовом адресе используется символ «.».

Например, если ваш администратор домена имеет почтовый адрес [email protected], то в поле contact следует писать не [email protected], а adm.kyky.ru.

Если в имени пользователя есть какие-либо особые символы, имеющие специальные значения при описании зоны, то они должны маскироваться символом обратного слэша — «\».

Типичный пример — почтовый адрес типа [email protected]. В этом случае точку следует замаскировать и написать в поле contact: user.name.kuku.ru. Поступая таким образом, мы исключили особое значение точки как разделителя поддоменов и обеспечили интерпретацию имени как единой символьной строки.

Вообще говоря, почтовые адреса приведенного выше типа не являются редкостью, но у администраторов компьютерных систем встречаются очень редко. Кроме того, если следовать рекомендациям (RFC 2142), то лучше всего, чтобы администратор DNS сервера имел адрес [email protected].

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

Атрибут serial — определяет серийный номер файла зоны. Если говорить проще, то в этом поле ведется учет изменений файла описания зоны. Serial — это 32-битное целое число, и ограничение по числу цифр, которое можно встретить в руководствах по BIND, на самом деле условно.

В принципе это могут быть любые числа, но чаще всего администраторы используют в качестве серийного номера год (4 позиции), месяц (две позиции), день (две позиции) и версию внесения изменений в файл описания зоны (две позиции). Таким образом эта нотация будет выглядеть как:

ГГГГММДДВВ

Итого получается 10 символов. В старых руководствах по BIND указывают максимальное значение длины этого поля 8 символов.

Важность серийного номера определяется тем, что когда вторичный(secondary) сервер обращается к первичному(primary) серверу для обновления информации о зоне, то он сравнивает серийный номер из своего кэша с серийным номером из базы данных первичного сервера. Если серийный номер из primary сервер больше, то secondary сервер обращается к primary и копирует описание всей зоны целиком, если нет, то он не вносит изменений в свою базу данных. Таким образом, когда производятся изменения в базе данных primary сервера, то значение атрибута serial в поле данных записи SOA для зоны, описание которой было изменено, должно быть увеличено. Неизменение номера — это типичная ошибка, которую совершают администраторы зон. По этой причине лучше пользоваться средствами автоматического обновления зоны.

А что делать при достижении максимально возможного порядкового номера? Вопрос гипотетический, т.к., если даже использовать в качестве серийного номера приведенную выше нотацию, то мы достигнем предельных значений серийного номера только в 4294 году (цитируем по man named для FreeBSD 4.2 -RELEASE), но все же?

На самом деле все просто: нужно начинать сначала. До BIND 9 можно было просто указать 0-ую версию описания зоны в любой момент, и потом снова начать ее увеличивать.

Любителям математики следует прочитать раздел «Цикл порядкового номера» в книге Пола Альбитца и Крикета Ли «DNS и BIND» на странице 194 (Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.). Там подробно объяснена концепция непрерывного арифметического пространства и способ перехода к младшим целым номерам от старших за два шага изменения серийного номера описания зоны. Кроме того, арифметике серийного номера посвящен отдельный документ — RFC 1982.

Атрибут refresh определяет интервал времени, после которого slave сервер обязан обратиться к master серверу с запросом на верификацию своего описания зоны. Как уже было сказано в разделе «Типы серверов доменных имен», при этом проверяется серийный номер описания зоны.

Описание зоны загружается slave сервером каждый раз, когда он стартует или перегружается. Однако, при стабильной работе может пройти достаточно большой интервал времени, пока эти события не произойдут в действительности. Кроме того, большинство систем, которые поддерживают сервис доменных имен, работают круглосуточно. Следовательно, необходим механизм синхронизации баз данных master и slave серверов.

Поле refresh задает интервал, после которого эта синхронизация автоматически выполняется. Длительность интервала указывается в секундах. В поле refresh можно указать любое целое 32-битное число. Указание маленького значения приведет к неоправданной загрузке сети, ведь в большинстве случаев описание зон довольно стабильно, но иногда, когда зона только создается, можно указать и небольшой интервал.

Атрибут retry начинает играть роль тогда, когда master сервер по какой-либо причине не способен удовлетворить запрос slave сервера за время определенное атрибутом refresh. А если говорить точнее, то в момент наступления времени синхронизации описания зоны master сервер по какой-либо причине не отвечает на запросы slave сервера.

Атрибут retry определяет интервал времени, после которого slave сервер должен повторить попытку синхронизовать описание зоны с master сервером. Ограничения на значение этого атрибута те же, что и для атрибута refresh.

При установке этого значения во внимание следует принимать несколько факторов. Во-первых, если master сервер не отвечает, то, скорее всего, произошло что-то серьезное (отделочники вырезали часть сети, т.к. мешала красить стены, экскаватор перекопал магистраль или отключили питание в сети). Такая причина не может быть быстро устранена, поэтому установка слишком малого времени опроса просто зря нагружает сеть.

Во-вторых, если на master сервере прописано много зон, и он обслуживает большое количество запросов, то сервер может просто не успеть ответить на запрос, а очень частые запросы от slave сервера просто «подливают масло в огонь», ухудшая и без того медленную работу сервера.

Атрибут expire определяет интервал времени, после которого slave должен прекратить обслуживание запросов к зоне, если он не смог в течение этого времени верифицировать описание зоны, используя информацию с master сервера.

Обычно это интервал делают достаточно большим. Если сделать маленький интервал, то какой смысл в slave сервере? Он просто скоропостижно скончается после отключения master сервера.

В течение всего этого времени, т.е. до достижения конца интервала expire, slave сервер будет пытаться установить контакт c master сервером и обслуживать запросы к зоне.

Правда все эти соображения хороши для случая, когда просто отключится или ломается машина, на которой стоит master сервер. Если же отключится вся сеть, которая описана в зоне, а для большинства организаций так оно и есть, то slave сервер становится подобным космическому аппарату «Пионер», который путешествует во Вселенной, давно потеряв всякую связь с Землей.

Тем не менее, существует несколько причин, по которым его наличие полезно. Во-первых, различные приложения по разному реагируют на ситуацию отсутствия соединения или невозможности найти соответствие доменному имени. Во-вторых, если зона доступна, а хост в ней недоступен, то приложение гораздо быстрее прерывает свою работу. В-третьих, время положительно кэширования гораздо больше времени негативного кэширования, а это ускоряет процесс прекращения попыток соединения с неработающим хостом, т.к. не нужно находить его адрес. В-четвертых, в отключенной сети все хосты не доступны, а они принадлежат, как правило, к одному домену, а адрес его slave сервера доменных имен закэширован и сам сервер доступен, что ускоряет, по крайней мере не замедляет, проверку доступности хостов домена (подробнее см. RFC 2182).

Последний атрибут из поля данных записи SOA — minimum. В разных версиях BIND он определяет совершенно разные понятия. До 8.2 этот параметр определял время кэширования по умолчанию ответов на запросы к DNS. Еще раньше он определял время кэширования по умолчанию только положительных ответов, т.е. тех, которые устанавливали наличие соответствия между IP-адресом и доменным именем. Теперь этот параметр обозначает время негативного кэширования (negative caching), т.е. время кэширования ответов, которые утверждают, что установить соответствие между доменным именем и IP-адресом нельзя.

Последнее обстоятельство заставило ввести в описание зоны новую директиву управления $TTL, которая и определяет время кэширования по умолчанию положительных ответов от системы DNS.

Существуют рекомендации по установки параметров записи SOA. Например, RFC 1537 рекомендует следующие установки для серверов, отличных от тех, которые поддерживают домены верхнего уровня:

28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800; Expire 7 days
86400 ; Minimum TTL 1 day

На самом деле установить в современных серверах minimum больше 3 часов нельзя (в том смысле, что написать-то можно, работать параметр не будет). Это максимальное время негативного кэширования, согласно документации на BIND 9.

Для TLD в том же документе рекомендованы:

86400 ; Refresh 24 hours
7200 ; Retry 2 hours
2592000; Expire 30 days
345600 ; Minimum TTL 4 days

Конечно, это не догма. В этом легко убедиться, посмотрев соответствующие параметры в SOA для зоны ru программой nslookup:

> set type=soa
> ru.
Server: ns.ripn.net
Address: 194.85.119.1

ru
origin = ns.ripn.net
mail addr = hostmaster.ripn.net
serial = 4005176
refresh = 7200 (2H)
retry = 900 (15M)
expire = 2592000 (4w2d)
minimum ttl = 345600 (4D)
ru nameserver = ns.ripn.net
ru nameserver = ns1.relcom.ru
ru nameserver = ns.uu.net
ru nameserver = sunic.sunet.se
ru nameserver = ns2.nic.fr
ru nameserver = ns2.ripn.net
ns.ripn.net internet address = 194.85.119.1
ns1.relcom.ru internet address = 193.125.152.3
ns2.ripn.net internet address = 194.226.96.30
>

Для зоны com информация несколько иная:

> com.
Server: [192.5.6.30]
Address: 192.5.6.30

com
origin = A.GTLD-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.com
serial = 2002092401
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)

Для полноты картины укажем и на более поздние рекомендации. Так, например, для небольших стабильных зон в 1999 году (ripe-203) рекомендовались следующие параметры SOA:

example.com. 3600 SOA dns.example.com. hostmaster.example.com. (
1999022301 ; serial YYYYMMDDnn
86400 ; refresh ( 24 hours)
7200 ; retry ( 2 hours)
3600000 ; expire (1000 hours)
172800 ) ; minimum ( 2 days)

При этом автор (Peter Koch) подробно описывает причины, по которым установлены эти значения.

Например, для refresh интервал в сутки выставлен потому, что существует динамическое обновление зоны и оповещение slave серверов о произошедших изменениях. По этой причине нет смысла ставить маленький интервал обновления базы данных slave сервера. Если оповещение отключено или используются старые версии BIND, то, видимо, нужно спуститься с небес на землю и поставить интервал поменьше, скажем часов 8 (RFC 1537) или еще меньше.

Для атрибута expire обычно указывают одну или две недели. Однако считается, что за это время серьезные проблемы с primary master не решить, следовательно, период должен быть большим, что-то порядка месяца-двух.

Peter Koch написал в 2001 году более свежие рекомендации по установке значений в записи SOA (RIPE DNS GUIDE). По факту (значениям, перечисленным в примере записи SOA) они ничем не отличаются от приведенного выше примера.

В новых рекомендациях существует важное замечание относительно значения параметра minimum. Интерпретация его значения зависит от того, поддерживает ли конкретная реализация BIND негативное кэширование. Если поддерживает и mininum — это время негативного кэширования, то следует указывать значение 3600, если не поддерживает, то — 172800.

Обратите внимание на то, что все атрибуты записи SOA определяют порядок взаимодействия master сервера и slave серверов. Исключение составляет только атрибут minimum. В данном случае речь идет о кэшировании адресов не только сервером, но системой «умного» resolver.

Дело в том, что в качестве resolver на локальной вычислительной установке выступают функции из стандартной библиотеки, которые направляют рекурсивные запросы к локальному серверу доменных имен и сами не осуществляют кэширования соответствий между именами и IP-адресами. В этом случае кэширование осуществляется локальным сервером доменных имен.

Если на машине запускается свой кэширующий сервер, который не описывает никакой зоны, а используется только для обслуживания запросов к сервису доменных имен, то именно он и является той частью resolver, которая кэширует соответствия.

Таким образом, когда речь идет об атрибуте minimum, то чаще всего его описывают в контексте программы named, которая может использоваться не только как master или slave сервер, но и как кэширующий сервер. В этом случае поле ttl записи описания ресурса, директива управления $TTL и атрибут minimum задают время хранения записи описания ресурса в кэше.

Приведем еще один пример записи типа SOA:

example.com. 3600 SOA dns.example.com. hostmaster.example.com. (
1999022301 ; serial YYYYMMDDnn
1d ; refresh
2h ; retry
30d ; expire
1H ) ; minimum

В данном примере имя зоны указано непосредственно — example.com. Время ttl для самой записи указано равным часу, хотя записи SOA и не хранятся в кэше. Primary master зоны указан как dns.example.com, и его имя отличается от имени домена. Адрес электронной почты администратора соответствует всем существующим рекомендациям — [email protected]. Серийный номер версии описания зоны занимает 10 позиций и соответствует шаблону даты. Время обновления базы данных описания зоны на slave серверах установлено равным 1 суткам, время повторения попыток обновления установлено равным 2 часам, период «умирания» зоны равен одному месяцу, а время негативного кэширования установлен равным одному часу.

Обратите внимание, что интервалы заданы не в секундах, а в более понятной нотации (минутах (m), часах (h), днях (d), неделях (w)).

И еще одно замечание в завершении этого материала. Мы много говорили о параметрах негативного кэширования, но вопроса о необходимости этого самого кэширования не обсудили. Мы сделаем это отдельно, т.к. кэширование отрицательных ответов вызвано не только теоретическими соображениями, но и суровой прозой жизни.

 

Рекомендованная литература:

 

  1. P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
  2. P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
  3. M. Andrews. RFC 2308. Negative Caching of DNS Queries (DNS NCACHE). 1998.(http://www.ietf.org/rfc/rfc2308.txt?number=2308)
  4. Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.
  5. P. Beertema. RFC 1537. Common DNS Data File Configuration Errors. 1993.(http://www.ietf.org/rfc/rfc1537.txt?number=1537)
  6. D. Crocker. RFC 2142. MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS. 1997.(http://www.ietf.org/rfc/rfc2142.txt?number=2142)
  7. Peter Koch. RIPE-203. Recommendations for DNS SOA Values. 1999. (http://www.ripe.net/docs/ripe-203.html)
  8. R. Elz, R. Bush. RFC 2181. Clarifications to the DNS Specification. 1997. (http://www.ietf.org/rfc/rfc2181.txt?number=2181)
  9. R. Elz, R. Bush. RFC 2182. Selection and Operation of Secondary DNS Servers. 1997. (http://www.ietf.org/rfc/rfc2182.txt?number=2182)

 

Полезные ссылки:

 

  1. http://www.isc.org/products/BIND/bind9.html — страничка BIND 9.2.1
  2. http://www.ludd.luth.se/~kavli/BIND-FAQ.html — DNS FAQ. Ответы на большинство вопросов, начинающих и «продвинутых» администраторов. Есть только одно большое НО! Этот материал посвящен BIND версии 4. Но все, что касается описания зоны вполне подходит и для более поздних версий BIND.
  3. Peter Koch. INTERNET-DRAFT. RIPE DNS WG Guide To Setting Up a DNS Server. 2001. (http://www.techfak.uni-bielefeld.de/~pk/dns/draft-koch-ripe-dns-setup-guide-01.txt.gz)- это рекомендации по установке параметров записи SOA и описание применения других записей RR.
  4. R. Elz, R. Bush. RFC 1982. Serial Number Arithmetic. 1996.(http://www.ietf.org/rfc/rfc1982.txt?number=1982)- этот документ для особо дотошных читателей. В нем подробно описана концепция непрерывного арифметического пространства серийного номера и приведены примеры изменения номера и сравнения номеров.

info.nic.ru

soa записи | Wiki — PeterHost

Категория:Виртуальный хостинг -> Домены
Категория:Виртуальный хостинг -> DNS

Содержание


SOA

SOA-запись DNS , которая определяет авторитетную информацию о DNS-зоне.

Формат

SOA запись содержит следующие параметры:

Primary Name Server

Имя первичного DNS-сервера зоны

Hostmaster

Контактный адрес лица, ответственного за администрирование файла зоны. Обратите внимание на то, что вместо «@» используется «.»

Serial number

Серийный номер файла зоны. 32-разрядное целое число, меняющееся при каждом обновлении зоны.

Refresh

Время (в секундах) ожидания вторичного DNS перед запросом SOA-записи с первичного. По истечении данного времени, вторичный DNS обращается к первичному, для получения копии текущей SOA-записи. Первичный DNS-сервер выполняет этот запрос. Вторичный DNS-сервер сравнивает полученный серийный номер зоны с имеющимся. Если они отличаются, то осуществляется запрос к первичному DNS-серверу на трансфер зоны.

Retry

Время в секундах, вступает в действие тогда, когда первичный DNS-сервер недоступен. Интервал времени, по истечении которого вторичный DNS должен повторить попытку синхронизировать описание зоны с первичным.

Expire

Время (в секундах), в течение которого вторичный DNS будет пытаться завершить синхронизацию зоны с первичным. Если это время истечет до того, как синхронизация осуществится, зона на вторичном DNS-сервере истечет, и он перестанет обслуживать запросы об этой зоне.

Minimum TTL

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

Как посмотреть?

nslookup

С помощью команды nslookup(Доступна в операционных системах Windows и UNIX-подобных)

$ nslookup
> set type=SOA 
> peterhost.ru
Server:        192.168.192.168
Address:    192.168.192.168#53
Non-authoritative answer:
peterhost.ru
    origin = ns1.peterhost.ru
    mail addr = dnsmaster.peterhost.ru
    serial = 1264777100
    refresh = 10800
    retry = 1800
    expire = 3600000
    minimum = 3600
Authoritative answers can be found from:
dig

Команда dig доступна в UNIX-подобных операционных системах.

Необходимо выполнить команду:
dig имя_домена SOA

dig peterhost.ru SOA
; <<>> DiG 9.6.1-P1 <<>> peterhost.ru SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26854
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;peterhost.ru.            IN    SOA
;; ANSWER SECTION:
peterhost.ru.        86400    IN    SOA    ns1.peterhost.ru. dnsmaster.peterhost.ru. 1264777100 10800 1800 3600000 3600
;; Query time: 62 msec
;; SERVER: 192.168.192.168#53(192.168.192.168)
;; WHEN: Fri Jan 29 18:54:23 2010
;; MSG SIZE  rcvd: 80

Категории:

peterhost.ru

DNS SOA запись

DNS SOA запись — Start of Authority — зона DNS, характеризующая как информация о доменном имени распространяется на вторичные DNS сервера. Данная запись и ее значение фактически не влияют на работу домена (как А-записи или PTR), SOA содержит административную информацию.

 

 

  • TTL – количество секунд в течение которых информация будет кэшироваться другими DNS серверами
  • Computer – FQDN — полностью определенное доменное имя (с точкой на конце), являющееся первичным источником информации для зоны
  • Email – адрес администратора доменной зоны
  • Starting Serial – версия доменной зоны с которой начнется отсчет, число будет инкрементироваться при каждом изменении
  • Refresh – количество секунд через которое значение будет обновлено после изменения, часто это 86400 (24 Hours)
  • Retry – количество секунд по прошествии которого будет предпринята повторная попытка обновления информации если первая не удалась, обычно это 7200 (2 Hours)
  • Expire – The time internal (in seconds) that specifies the upper limit on the time internal that can elapse before the zone is no longer authoritative. This is when the secondary name servers will expire if they are unable to refresh. Recommended value – up to 2419200 (672 Hours)
  • Negative Cache – количество секунд по прошествии которых кэшируется пустое значение записи, выставляется, как правило, в 180 — 172800 секунд (3 минуты – 2 дня)

 

Просмотреть значение записи можно, например, при помощи утилиты dig

dig example.com SOA

; <<>> DiG 9.10.3-P4-Ubuntu <<>> example.com SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38193
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com. IN SOA

;; ANSWER SECTION:
example.com. 300 IN SOA ns1.examplehost.com. hostmaster.examplehost.com. 1505669677 300 600 86400 300

;; Query time: 88 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Sat Nov 18 16:59:35 +05 2017
;; MSG SIZE rcvd: 86

 

Запись не является обязательной — если ее нет, будут применяться параметры обновления зоны, указанные для всего сервера.

 

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

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

server-gu.ru

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


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


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

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-записи в формате: ДД: ЧЧ: ММ: СС. Как правило, оно должно совпадать с минимальным временем жизни всех записей.

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