Запись «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 )
Поле
Вообще говоря, данное жесткое ограничение (наличие 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)).
И еще одно замечание в завершении этого материала. Мы много говорили о параметрах негативного кэширования, но вопроса о необходимости этого самого кэширования не обсудили. Мы сделаем это отдельно, т.к. кэширование отрицательных ответов вызвано не только теоретическими соображениями, но и суровой прозой жизни.
Рекомендованная литература:
- P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
- P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
- M. Andrews. RFC 2308. Negative Caching of DNS Queries (DNS NCACHE). 1998.(http://www.ietf.org/rfc/rfc2308.txt?number=2308)
- Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.
- P. Beertema. RFC 1537. Common DNS Data File Configuration Errors. 1993.(http://www.ietf.org/rfc/rfc1537.txt?number=1537)
- D. Crocker. RFC 2142. MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS. 1997.(http://www.ietf.org/rfc/rfc2142.txt?number=2142)
- Peter Koch. RIPE-203. Recommendations for DNS SOA Values. 1999. (http://www.ripe.net/docs/ripe-203.html)
- R. Elz, R. Bush. RFC 2181. Clarifications to the DNS Specification. 1997. (http://www.ietf.org/rfc/rfc2181.txt?number=2181)
- R. Elz, R. Bush. RFC 2182. Selection and Operation of Secondary DNS Servers. 1997. (http://www.ietf.org/rfc/rfc2182.txt?number=2182)
Полезные ссылки:
- http://www.isc.org/products/BIND/bind9.html — страничка BIND 9.2.1
- http://www.ludd.luth.se/~kavli/BIND-FAQ.html — DNS FAQ. Ответы на большинство вопросов, начинающих и «продвинутых» администраторов. Есть только одно большое НО! Этот материал посвящен BIND версии 4. Но все, что касается описания зоны вполне подходит и для более поздних версий BIND.
- 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.
- R. Elz, R. Bush. RFC 1982. Serial Number Arithmetic. 1996.(http://www.ietf.org/rfc/rfc1982.txt?number=1982)- этот документ для особо дотошных читателей. В нем подробно описана концепция непрерывного арифметического пространства серийного номера и приведены примеры изменения номера и сравнения номеров.
Что такое SOA-запись и как ее проверить
Запись SOA (Start of Authority) ― начальная запись зоны, которая указывает, на каком сервере хранится эталонная информация о домене. Удалить эту запись нельзя. SOA-запись и ее значения не влияют на работу домена, но они очень важны для работы всей DNS-системы.
SOA содержит административную информацию:
-
TTL – количество секунд, в течение которых информация будет кэшироваться другими DNS-серверами;
-
MNAME — указывает на DNS-серверы, которые отвечают за хранение остальных ресурсных записей домена;
-
Hostname (RNAME) — контактный адрес лица, которое отвечает за администрирование файла зоны;
-
Serial number — серийный номер файла зоны. Он увеличивается каждый раз, когда в файл зоны вносятся изменения. Увеличение серийного номера показывает вторичным серверам, что им необходимо обновить информацию;
-
Refresh — количество секунд, через которое вторичный DNS-сервер запрашивает данные у первичного DNS-сервера, чтобы узнать не изменился ли Serial number. Если изменился, то данные на вторичном сервере обновляются;
-
Retry — количество секунд, через которое сервер сделает повторную попытку обновления данных, если первая была неудачная;
-
Expire — время (в секундах), в течение которого вторичный DNS-сервер может использовать ранее полученные данные о зоне до того, как они потеряют силу. Если по истечении этого времени данные не будут обновлены, то зона на вторичном DNS-сервере перестанет обслуживать запросы об этой зоне;
-
Minimum TTL — сколько времени другие серверы могут хранить данные зоны в кэше.
Как увидеть данные SOA-записи
Увидеть данные SOA-записи можно с помощью утилиты dig. Например, на сайте REG.RU:
-
Откройте утилиту dig.
-
Введите данные интересующего вас доменного имени.
-
Выберите тип записи SOA. Нажмите Проверить:
Готово, вы увидите данные SOA-записи:
Получаем информацию из DNS: SOA
Вопрос. С помощью какой команды можно узнать 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
Замените домен 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Постовой
Совсем недавно переезжал в Москве с одной квартиры на другую. Могу с уверенностью сказать, что это был переезд стоивший мне настоящие копейки. Воспользовался услугами компании «Альянс Плюс» и совершенно не жалею.
Еще записи по теме
С DNS-сервера ****** не удается получить SOA-запись для домена ****
Если домен не может делегироваться на ns-сервера, то это либо ошибка пользователя (указанные не верные ns-сервера), либо (в 99.5% процентов случаев) это вина хостинг провайдера.Ниже привожу один из примеров обращения в службу поддержки на тему: «С DNS-сервера ****** не удается получить SOA-запись для домена ****»
По понятным причинам имя домена пользователя заменено на ****.
Домен хостинг провайдера оставлен без изменений.
Вопрос: по каким-то не изветным мне причнам домен не может обновить днски!
****.ru
ответ хотсинга:
Ваш регистратор по непонятной мне причине приписует к ns2 серверу IP
91.197.129.144
Ответ:
Здравствуйте.
Я совсем детально занялся Вашим вопросом, чтобы Вас наглядно убедить в том, что если домен не может делегироваться на ns-сервера, то это либо ошибка пользователя (указанные не верные ns-сервера), либо (в 99.5% процентов случаев) это вина хостинг провайдера.
Ваш случай не чем не отличается от остальных подобных случаев, на лицо вина хостинг провайдера, чтобы Ваш хостинг провайдер Вам в ответ не говорил, а против фактов не попрешь.
«С DNS-сервера ns2.moyhosting.com.(91.203.5.13) не удается получить SOA-запись для домена *****.RU.» По простой причине — регистратор не может получить ответ с этого самого «ns2.moyhosting.com»
Убедитесь сами:
1. На своем компьютере сделайте следующее:
Меню Пуск —> Выполнить —> cmd —> tracert ns2.moyhosting.com
2. http://host-tracker.com/ в форму вставьте ns2.moyhosting.com нажмите Проверить и дождитесь результатов
3. На любом хостинге с доступом по ssh (хостинг должен быть не moyhosting.com, а какой то другой), войдите по ssh и выполните команду: traceroute ns2.moyhosting.com.
Все очень наглядно!
Домен не может делегироваться, так как все выше описанные проверки показывают что данный ns попросту не доступен.
Варианта решения данной проблемы есть 3.
- Ждите, когда нибудь регистратор все таки сможет получить ответ от данного ns (я на это надеюсь)
- Требуйте от Вашего хостинг провайдера нормального предоставления услуг
- Если Вы уверены, что на сервере всё в порядке, поставьте галочку «Отключить проверку DNS-серверов».
1. На своем компьютере сделайте следующее:
Меню Пуск —> Выполнить —> cmd —> tracert ns2.moyhosting.com
—————————————————————
Microsoft Windows [Версия 6.0.6002]
(C) Корпорация Майкрософт, 2006. Все права защищены.
C:\Users\Asus>tracert ns2.moyhosting.com
Трассировка маршрута к ns2.moyhosting.com [91.203.5.13]
с максимальным числом прыжков 30:
1 * 35 ms 20 ms vpnbsd19.msk1.ip.di-net.ru [213.219.200.235]
2 10 ms 14 ms * 213.219.200.225
3 14 ms 20 ms 30 ms 701.ae-0.br1.msk1.ip.di-net.ru [213.248.1.97]
4 29 ms 32 ms * s-bb2-link.telia.net [80.91.254.114]
5 48 ms 47 ms 39 ms hbg-bb2-link.telia.net [80.91.249.12]
6 80 ms 99 ms 89 ms war-b1-link.telia.net [80.91.251.216]
7 89 ms 86 ms 91 ms jsc-ic-131096-war-b1.c.telia.net [213.248.92.114
]
8 * * * Превышен интервал ожидания для запроса.
9 91 ms 87 ms 84 ms 213.186.118.170.utel.net.ua [213.186.118.170]
10 * * * Превышен интервал ожидания для запроса.
11 * * * Превышен интервал ожидания для запроса.
12 * * * Превышен интервал ожидания для запроса.
13 * * * Превышен интервал ожидания для запроса.
14 * * * Превышен интервал ожидания для запроса.
15 * * * Превышен интервал ожидания для запроса.
16 * * * Превышен интервал ожидания для запроса.
17 * * * Превышен интервал ожидания для запроса.
18 * * * Превышен интервал ожидания для запроса.
19 * * * Превышен интервал ожидания для запроса.
20 * * * Превышен интервал ожидания для запроса.
21 * * * Превышен интервал ожидания для запроса.
22 * * * Превышен интервал ожидания для запроса.
23 * * * Превышен интервал ожидания для запроса.
24 * * * Превышен интервал ожидания для запроса.
25 * * * Превышен интервал ожидания для запроса.
26 * * * Превышен интервал ожидания для запроса.
27 * * * Превышен интервал ожидания для запроса.
28 * * * Превышен интервал ожидания для запроса.
29 * * * Превышен интервал ожидания для запроса.
30 * * * Превышен интервал ожидания для запроса.
Трассировка завершена.
—————————————————————
2. http://host-tracker.com/ в форму вставьте ns2.moyhosting.com нажмите Проверить и дождитесь результатов
—————————————————————
Расположение Результат Размер страницы Время ответа КБ/сек IP Партнер
Полученные результаты: 7 Ok 30 Ошибка(ок) Average: 0.84 sec 24.06
Fort Lee,NJ,US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 ProGoldHost.net
Sao Paulo, Brasil Ok 20811 1.48 сек. 13.72 91.197.129.144 Egrana Internet
Toronto, ON, CA Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 OnyxNetUa
Montreal, QC, CA Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 OTCEK
Zagreb, Croatia Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 80.51 сек. 91.203.5.13 Hosting Centar
Paris, France Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 RV89
Roubaix, France Ok 20811 0.23 сек. 86.84 91.197.129.144 XVM Hosting
Falkenstein, German Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 Hosting Hutor.com
Gunzenhausen, German Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 aBajt
Erfurt, Germany Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 Profhost Ltd.
Frankfurt, Germany Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 QBEM
WanChai, Hong Kong Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 80.51 сек. 91.203.5.13 Zolar Co Ltd
Moscow, RU Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 KubanHosting.RU
SPb, RU Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 80.50 сек. 91.203.5.13 SpaceWeb
Moscow, Russia Ok 20811 0.71 сек. 28.59 91.197.129.144 RuFox
Singapore, Singapore Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.01 сек. 91.203.5.13 RuangWeb
Kiev, UA Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 dc63.ru
Kiev, UA Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 Welcomehost
Lugansk, UA Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 39.99 сек. 91.203.5.13 One-Hosting
Odessa, UA Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 Hosting Hutor.com (Free Edition)
Los Angeles, CA, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 West Cost Hosting
Washington, DC, US Ok 20811 0.64 сек. 31.54 91.197.129.144 MyCoHost
Orlando, FL, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 81.04 сек. 91.203.5.13 PIE Hosting
Tampa, FL, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 ServMap
Atlanta, GA, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 MoonSoft Systems
Chicago, IL, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 Interactive Online
East Lansing, MI, US Ok 20811 0.84 сек. 24.25 91.197.129.144 NIMHOST
Charlotte, NC, US Ok 20811 0.71 сек. 28.57 91.197.129.144 HyperOIS
Fort Lee,NJ,US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 ProGoldHost.net
Secaucus, NJ, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 ServWebSolutions
Dallas, TX, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 80.50 сек. 91.203.5.13 XP-Hosting.com
Dallas, TX, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 Arvixe, LLC
Dallas, TX, US Ok 20811 1.29 сек. 15.72 91.197.129.144 Provisov.Net
Dallas, TX, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 Hosting-ASAP
Dallas, TX, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.00 сек. 91.203.5.13 DWS CENTER
Houston, TX, US Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 40.21 сек. 91.203.5.13 PremiumReseller
Kiev, Ukraine Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 80.51 сек. 91.203.5.13 HOSTED
Kiev, Ukraine Ошибка HTTP:Http_client.Bad_message(«Unknown reason (e.g. unexpected eof, timeout)») 80.50 сек. 91.203.5.13 HostBizUA.com
—————————————————————
3. На любом хостинге с доступом по ssh (хостинг должен быть не moyhosting.com, а какой то другой), войдите по ssh и выполните команду: traceroute ns2.moyhosting.com.
—————————————————————
root@server [~]# traceroute ns2.moyhosting.com
traceroute to ns2.moyhosting.com (91.203.5.13), 30 hops max, 38 byte packets
1 dsw-3.hc.ru (89.111.188.1) 0.849 ms 0.897 ms 1.496 ms
2 bgw-m9.hc.ru (91.189.112.1) 0.994 ms 0.935 ms 0.985 ms
3 msk-dsr13-ge1-7.rt-comm.ru (195.161.157.17) 0.980 ms 0.956 ms 0.980 ms
4 msk-bgw1-ge1-0-0-0.rt-comm.ru (217.106.0.14) 1.471 ms 0.973 ms 0.983 ms
5 unknown.Level3.net (212.113.15.177) 71.438 ms 71.411 ms 71.735 ms
6 ae-34-52.ebr2.London1.Level3.net (4.69.139.97) 72.124 ms 71.910 ms 71.950 ms
7 ae-2-2.ebr2.Amsterdam1.Level3.net (4.69.132.134) 79.421 ms 79.453 ms 79.381 ms
8 ae-1-100.ebr1.Amsterdam1.Level3.net (4.69.141.169) 79.424 ms 79.392 ms 79.442 ms
9 ae-2-2.ebr2.Dusseldorf1.Level3.net (4.69.133.90) 83.056 ms 82.533 ms 82.796 ms
10 ae-1-100.ebr1.Dusseldorf1.Level3.net (4.69.141.149) 82.473 ms 82.393 ms 82.489 ms
11 ae-2-2.ebr2.Frankfurt1.Level3.net (4.69.132.138) 85.878 ms 85.888 ms 85.885 ms
12 ae-82-82.csw3.Frankfurt1.Level3.net (4.69.140.26) 86.414 ms ae-92-92.csw4.Frankfurt1.Level3.net (4.69.140.30) 89.355 ms ae-72-72.csw2.Frankfurt1.Level3.net (4.69.140.22) 95.348 ms
13 ae-61-61.ebr1.Frankfurt1.Level3.net (4.69.140.1) 86.396 ms ae-91-91.ebr1.Frankfurt1.Level3.net (4.69.140.13) 86.396 ms ae-61-61.ebr1.Frankfurt1.Level3.net (4.69.140.1) 86.404 ms
14 ae-1-12.bar1.Budapest1.Level3.net (4.69.141.249) 130.906 ms 101.882 ms *
15 212.162.26.6 (212.162.26.6) 123.933 ms 212.162.26.14 (212.162.26.14) 133.374 ms 212.162.26.6 (212.162.26.6) 123.875 ms
16 * * *
17 213.186.118.170.utel.net.ua (213.186.118.170) 120.132 ms 122.760 ms 124.879 ms
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Задать вопрос
SOA запись домена — Заметки на полях
SOA запись домена
Январь 4th, 2013 fireflySOA запись определяет авторитетную информацию о DNS-зоне. Специфику этого типа записи необходимо знать при настройке своего NS сервера.
- MNAME (Primary Name Server) — Имя первичного DNS сервера зоны.
- RNAME (Hostmaster) — Контактный email лица ответственного за администрирование зоны. Вместо символа «@» используется «.» .
- Serial number — серийный номер файла зоны, меняется при каждом обновлении зоны.
- Refresh — время (в секундах), которое ожидает вторичный DNS сервер перед запросом SOA-записи с первичного. После того как оно истечет, вторичный DNS обращается к первичному, для получения копии текущей SOA записи. Вторичный DNS-сервер сравнивает полученный Serial number зоны с имеющимся. Если они отличаются, то осуществляется запрос к первичному DNS-серверу на трансфер зоны.
- Retry — интервал времени, по истечении которого вторичный DNS должен повторить попытку синхронизировать описание зоны с первичным, если во время предыдущей попытки первичный DNS не отвечал.
- Expire — время, в течение которого вторичный DNS будет пытаться совершить синхронизацию зоны с первичным. Если за это время синхронизация не осуществится, то вторичный DNS-сервер перестанет обслуживать запросы к этой зоне.
- Minimum TTL — Минимальное время жизни, применяемое ко всем ресурсным записям зоны. Оно говорит другим серверам, сколько времени они могут хранить данные зоны в кэше.
Рекомендованные значения 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)
Источник
Вы можете оставить комментарий, или ссылку на Ваш сайт.Установка и настройка DNS-сервера — Документация ISPmanager Lite
Поиск точной фразы
Для поиска контента, содержащего точную фразу «мел и сыр», введите:
"мел и сыр"
поиск с OR
Для поиска контента, содержащего одного из выражений «мел» или «сыр», введите:
"мел OR сыр"
поиск с AND
Для поиска контента, содержащего оба выражения «мел» и «сыр», введите:
"мел AND сыр"
поиск с NOT
Для поиска контента, который содержит «мел», но не содержит «сыр», введите:
"мел NOT сыр"
Исключение выражений из поиска
Аналогично поиску с NOT, для поиска контента, который содержит «мел» и «масло», но не содержит «сыр», введите:
мел масло -сыр
Группировка выражений поиска
Для поиска контента, который обязательно должен содержать «мел», и возможно содержит «сыр» или «масло», введите:
(сыр OR масло) AND мел
Поиск по Заголовку
Для поиска контента, в Заголовок которого входит «мел», используйте ключевое слово title:
title:мел
Одиночный символ
Для поиска контента, содержащего «лак» или «лук», можно использовать символ ? :
л?к
Для поиска контента, содержащего «хлеб» или «хлебный», можно использовать символ * :
хлеб*
Множественные символы
Для поиска «хлеб» или «хлебный»:
х*б*
Допускается комбинирование подстановочных символов, для уточнения условий. Например, поисковый запрос ниже позволит найти контент, содержащий «масло», но не «масленый»:
м*л?
Поиск меток
Используйте префикс «labelText:», чтобы искать содержимое с конкретной меткой.
labelText:шоколад
Поиск близких выражений
Следующее поисковое выражение позволяет найти все фразы, в которых указанные слова отстоят друг от друга на точно указанное количество слов.
"бутерброд сыром"~2
Фраза «будерброд с плавленым сыром» удовлетворяет условиям поиска.
Неточный поиск
Этот способ поиска позволяет искать слова, близкие по написанию. Для поиска «масленый», если есть неуверенность в написании:
масленый~
Фраза «масляный» удовлетворяет условиям поиска.
Комбинированный поиск
Возможно комбинировать поисковые выражения:
масл?н* AND хлеб~ AND ("блог" AND "пост")Файлы и записи зон DNS
Файл зоныФайл зоны — это обычный текстовый файл, который может быть изменен при помощи любого текстового редактора. Ниже приведен пример файла зоны сразу после ее создания.
;
; Database file test.fio.ru.dns for test.fio.ru zone.
; Zone version: 1;
@ IN SOA mcio-08kwa653t4.fio.ru. admin.fio.ru. (
1 ; serial number
900 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL;
; Zone NS records
;
@ NS mcio-08kwa653t4.fio.ru.
;
; Zone records
;
Файл зоны состоит из множества записей, причем одна запись обычно занимает одну строку. Строки, начинающиеся с точки с запятой, являются комментариями и не анализируются DNS-сервером.
Любой файл зоны должен содержать как минимум следующее:
- одну запись Start Of Authority (SOA), содержащую параметры зоны;
- не менее одной записи Name Server (NS), содержащей адреса DNS-серверов, ответственных за хранение и обслуживание зоны;
- не менее одной записи Host (A), содержащей информацию о соответствии имени DNS-сервера, указанного в каждой записи NS, его IP-адресу.
При создании и изменении зоны вы чаще всего будете использовать следующие типы записей:
| Тип записи | Назначение записи |
| Start Of Authority (SOA) | Описывает зону и ее параметры. В файле зоны встречается однократно и не требует редактирования вручную |
| Name Server (NS) | Описывает один DNS-сервер |
| Host (A) | Описывает соответствие имени хоста его IP-адресу. Используется часто |
| Canonical Name (CNAME) | Описывает альтернативное имя для уже существующего хоста |
| Mail Exchanger (MX) | Описывает почтовый хост, обрабатывающий электронную почту домена |
| Pointer (PTR) | Описывает соответствие IP-адреса имени хоста. Используется в зонах обратного просмотра |
| Service Location (SRV) | Описывает сервисы, предоставляемые хостами |
Для создания и изменения записей зон можно использовать как инструменты с графическим интерфейсом, так и редактировать файл зоны вручную в любом текстовом редакторе.
Внимание!
После внесения изменений в файл зоны в текстовом редакторе перезапустите службу DNS-сервера, чтобы загрузить новый файл зоны в память.
Общий синтаксис записей зонЛюбая DNS-запись имеет следующий вид:
владелец [класс] [TTL] тип данные
Описание полей DNS-записи приведено в таблице.
| Поле | Описание |
| владелец | Относительное или полное имя записи. Если значение этого поля совпадает с именем зоны, то вы можете использовать символ @ вместо полного имени зоны |
| класс | Определяет класс, к которому принадлежит запись. Например, IN указывает, что запись принадлежит к классу записей Интернет-ресурсов. Это единственный класс записей, поддерживаемых DNS-сервером, входящим в состав Windows 2000. В связи с этим в любой записи поле класса может быть опущено, хотя стандарт DNS требует обязательного указания класса записи |
| TTL | Определяет время жизни конкретной записи в кэше других DNS-серверов. Является необязательным для большинства типов записей. Если поле TTL у записи опущено, то берется соответствующее значение из параметров зоны (запись SOA). Для того, чтобы предотвратить кэширование записи указывайте значение 0 в качестве TTL |
| тип | Обязательное поле, содержащее один из стандартных текстовых идентификаторов, определяющих тип записи |
| данные | Обязательное поле, содержащее данные переменной длины. Формат данных определяется типом записи |
Поля записи разделяются любым количеством пробелов или символов табуляции.
Служебные записи (SOA и NS)Каждый файл зоны должен содержать запись SOA, которая описывает зону, параметры ее синхронизации и параметры устаревания ее записей. Кроме того, зона должна содержать не менее одной записи NS, описывающей DNS-сервер [в нотации DNS они называются серверами имен (name server)], обслуживающий зону. Если серверов два или более, то один из них является основным, а все остальные — дополнительными. Все изменения в зоне производятся на основном сервере, после чего дополнительные самостоятельно получают ее измененную копию.
Большинство организаций, регистрирующих доменные имена, требуют наличия не менее двух обслуживающих зону DNS-серверов. Кроме того, для надежности эти серверы должны быть расположены в разных IP-сетях класса C.
Синтаксис записи NS| Название | Name Server |
| Определена в | RFC 1035 |
| Описание | Запись, указывающая один из серверов, обслуживающих зону. В виде NS-записей указываются все сервера (основной и дополнительные). Тот сервер, который указан в SOA-записи, считается основным, все остальные — дополнительными. |
| Синтаксис | владелец [класс] [TTL] NS хост |
| Параметры | Полное DNS-имя сервера, который должен быть определен в DNS. Допускается определение серверов в той же зоне, которую они обслуживают. |
| Пример | @ NS mcio-08kwa653t4.fio.ru @ NS host1.test.fio.ru |
| Название | Start Of Authority |
| Определена в | RFC 1035 |
| Описание | Запись, описывающая зону ответственности. |
| Синтаксис | владелец класс SOA первичный_сервер ответственный (редакция обновление повтор устаревание TTL) |
| Параметры | Первичный сервер — полное имя сервера, содержащего основную копию зоны.Ответственный — почтовый адрес лица, ответственного за управление зоной. Символ @ в почтовом адресе заменяется на точку.Редакция — число, указывающее порядковый номер редакции зоны. При внесении любых изменений вручную необходимо увеличивать это число, т. к. дополнительные DNS-серверы определяют необходимость копирования зоны именно по этому параметру. При изменении зоны через Консоль управления это число увеличивается автоматически.Обновление — интервал в секундах, в течение которого дополнительные DNS-серверы ожидают, прежде чем отправить запрос об изменении зоны. По истечении этого интервала дополнительный DNS-сервер запрашивает запись SOA с основного, проверяет в ней поле Редакция и определяет необходимость загрузки файла зоны. По умолчанию — 900 секунд (15 минут).Повтор — интервал в секундах, в течение которого дополнительные DNS-серверы ожидают, прежде чем произвести повторную попытку обновления зоны с основного сервера в случае неудачи предыдущей попытки. По умолчанию — 600 секунд (10 минут).Устаревание — интервал в секундах, по истечении которого информация зоны считается устаревшей. Этот параметр используется дополнительными серверами, которые перестают отвечать на запросы после того, как пройдет указанное количество времени с момента последнего успешного обновления. По умолчанию — 86 400 секунд (24 часа).TTL — минимальное время жизни записей зоны, для которых не указано индивидуальное значение. Используется для указания другим DNS-серверам и DNS-клиентам, в течение какого периода времени они могут кэшировать записи зоны. По умолчанию — 3 600 секунд (1 час). |
| Пример | @ IN SOA mcio-08kwa653t4.fio.ru. admin.fio.ru. ( 1 900 600 86400 3600) |
; Database file test.fio.ru.dns for test.fio.ru zone.
; Zone version: 2541744385
;
@ IN SOA ns1.test.fio.ru. admin.fio.ru. (
2541744385 ; serial number
10800 ; refresh
3600 ; retry
604800 ; expire
86400 ) ; minimum TTL
;
; Zone NS records
;
@ NS ns1.test.fio.ru.
@ NS ns2.test.fio.ru.
@ NS ns2.fio.ru.
;
; Zone records
;
ns1 A 195.34.17.1
ns2 A 213.128.193.119
Для установления соответствия между именем хоста и его IP-адресом используется запись A, для обратного соответствия — запись PTR. Для одного и того же IP-адреса допустимо использование нескольких имен хостов, однако для одного IP-адреса рекомендуется использовать только одну запись PTR. Записи A используются в зонах прямого просмотра, PTR — в зонах обратного просмотра.
Синтаксис записи A| Название | Host Address |
| Определена в | RFC 1035 |
| Описание | Запись, устанавливающая соответствие имени определенному IP-адресу. |
| Синтаксис | владелец [класс] [TTL] A IP_адрес |
| Параметры | IP-адрес хоста. |
| Пример | host1 IN A 192.168.0.1 |
| Название | IPv6 Host Address |
| Определена в | RFC 1886 |
| Описание | Запись, устанавливающая соответствие имени определенному IP-адресу версии 6. |
| Синтаксис | владелец [класс] [TTL] AААА IP_адрес_v6 |
| Параметры | IP-адрес версии 6 хоста. |
| Пример | host2 IN AAAA 4321:0:1:2:3:4:567:89ab |
| Название | Pointer |
| Определена в | RFC 1035 |
| Описание | Запись, устанавливающая соответствие IP-адреса доменному имени. Используется в зонах обратного просмотра |
| Синтаксис | владелец [класс] [TTL] PTR имя |
| Параметры | Полное DNS-имя хоста, соответствующего указанному IP-адресу. |
| Пример | 1.0.168.192.in-addr.arpa PTR host1.test.fio.ru |
Записи A и PTR могут быть добавлены в зону следующим образом:
- можно вручную создать необходимые записи (A и PTR) для компьютеров со статическими IP-адресами;
- компьютеры, работающие под управлением Windows 2000 и использующие динамические IP-адреса, самостоятельно добавляют или изменяют необходимые записи (A и PTR) в зоне;
- для компьютеров, работающих под управлением более ранних версий Windows и использующих динамические IP-адреса, добавление или изменение необходимых записей (A и PTR) осуществляется DHCP-сервером из состава Windows 2000 Server.
Примечание
Записи A и PTR не требуются для всех компьютеров. Они необходимы только для компьютеров, предоставляющих свои ресурсы в совместное использование. Тем не менее при использовании домена Active Directory Windows 2000 создает запись A для каждого компьютера в домене.
Записи альтернативных имен (CNAME)Записи альтернативных имен позволяют использовать два или более имен для одного хоста. Использование альтернативных имен отличается от использования нескольких записей A для одного IP-адреса.
Синтаксис CNAME-записи| Название | Canonical Name |
| Определена в | RFC 1035 |
| Описание | Указывает, что владелец записи является альтернативным именем, для DNS-имени, указываемого как параметр. |
| Синтаксис | владелец [класс] [TTL] CNAME имя |
| Параметры | Полное или относительное DNS-имя хоста. |
| Пример | alias CNAME host1.test.fio.ru alias2 CNAME host2 |
Альтернативные имена используются для:
- изменения имени хоста, определенного при помощи записи A;
- задания привычных имен для хостов, предоставляющих определенные сервисы;
- распределения нагрузки между серверами, предоставляющими один и тот же сервис.
При изменении имени хоста, которое использовалось для обращения по сети, придерживайтесь следующей последовательности.
- cоздайте запись A с новым именем, указывающую на IP-адрес хоста;
- cоздайте запись CNAME со старым именем, указывающую на новое имя хоста;
- удалить запись A хоста со старым именем.
Придерживаясь этой практики, вы позволите обращаться к хосту и по старому, и по новому имени, а когда надобность в старом имени отпадет, достаточно удалить запись CNAME.
Использование записей CNAME для задания привычных имен хостов позволяет осуществлять прозрачное перемещение сервисов с одного хоста на другой, балансировку нагрузки между хостами, прозрачно для пользователей изменять IP-адреса хостов, предоставляющих сервисы.
Рассмотрим это на примере.
Изначально в сети существовал хост, предоставляющий Web- и FTP-сервисы. Соответствующие записи зоны имели следующий вид:
host-a IN A 10.0.0.20
www IN CNAME host-a
ftp IN CNAME host-a
Со временем было принято решение переместить FTP-сервер на отдельный хост. За счет использования записей CNAME это было сделано прозрачно для пользователей:
host-a IN A 10.0.0.20
host-b IN A 10.0.0.21
www IN CNAME host-a
ftp IN CNAME host-b
Со временем нагрузка на Web-сервер возросла, и было принято решение установить дополнительный Web-сервер, разделяя нагрузку между ними, что было сделано прозрачно для пользователей за счет записей CNAME:
host-a IN A 10.0.0.20
host-b IN A 10.0.0.21
host-c IN A 10.0.0.22
www IN CNAME host-a
www IN CNAME host-c
ftp IN CNAME host-b
Внимание!
Относитесь внимательно к удалению записей CNAME, которые ссылаются на уже несуществующие записи хостов. DNS-сервер не отслеживает взаимосвязи между записями, поэтому попытки разрешения записей CNAME, ссылающихся на несуществующие хосты, могут повысить нагрузку на DNS-сервер.
Записи почтовых хостов (MX)Записи почтовых хостов домена используются почтовыми серверами и программами для определения хоста, на который должна быть отправлена почта. При этом почтовый сервер пытается найти запись MX в домене, имя которого получается отсечением от почтового адреса имени пользователя и символа @. Например, при отправке почты на адрес [email protected], поиск записи MX будет проводиться в домене fio.ru. Записи почтовых хостов указывают серверы, которые занимаются обработкой входящей почты для соответствующего домена. При наличии нескольких записей MX почтовый сервер пытается сначала использовать запись с наименьшим приоритетом.
Синтаксис записи MX| Название | Mail eXchanger |
| Определена в | RFC 1035 |
| Описание | Запись, указывающая на сервер, осуществляющий обработку и доставку входящей почты. |
| Синтаксис | владелец [класс] [TTL] MX приоритет хост |
| Параметры | Приоритет — число от 0 до 65535, определяющее приоритет сервера при наличии в зоне нескольких MX записей с одним именем. Обработка начинается с сервера с наименьшим приоритетом.Хост — полное или относительное имя хоста почтового сервера, который должен быть определен в DNS. |
| Пример | test.fio.ru MX 10 host1.test.fio.ru @ MX 20 host1.test.fio.ru |
Рассмотрим пример:
@ IN MX 10 mailserver1
@ IN MX 20 mailserver2
Здесь будет сначала использован сервер mailserver1, а при невозможности отправить почту через него — mailserver2. Если и второй сервер будет недоступен, автору сообщения будет отправлено уведомление о невозможности доставки почты.
Записи сервисов (SRV)Записи сервисов — это новая возможность, не так давно используемая в DNS. Однако в Windows 2000 они используются очень активно, в основном для обеспечения работы Active Directory. Вся информация о доменах AD, контроллерах доменов, серверах глобального каталога и прочих сервисах, необходимых для ее функционирования, хранится в DNS в виде записей SRV.
Синтаксис записи SRV| Название | Service locator |
| Определена в | RFC 2052 |
| Описание | Запись, определяющая сервера, предоставляющие определенные сервисы. |
| Синтаксис | сервис.протокол.имя [класс] [TTL] SRV приоритет вес порт хост |
| Параметры | Сервис — символьное имя сервиса. Имена для стандартных сервисов (_telnet, _smtp и т. п.) определены в RFC 1700.Протокол — символьное имя протокола. Обычно используются _tcp и _udp, хотя может быть использован любой протокол, определенный в RFC 1700 .Имя — доменное имя, которое будет использовано для поиска информации о сервисах.Приоритет — число от 0 до 65535, определяющее приоритет сервера, указываемого в поле хост , при использовании нескольких записей SRV с одинаковым именем.Вес — число от 1 до 65535, которое в дополнение к приоритету используется для балансировки нагрузки между несколькими серверами. Значение этого поля учитывается при использовании нескольких записей SRV с одинаковыми приоритетами. Если балансировка нагрузки не используется, в качестве веса указывается 0.Порт — число от 0 до 65535, определяющее номер порта сервера, через который предоставляется указанный сервис. Соответствие портов стандартным сервисам определено в RFC 1700 , хотя можно использовать другие невостребованные номера портов.Хост — полное или относительное имя хоста сервера, который предоставляет указанный сервис. Хост должен быть определен в DNS. Вместо имени хоста может быть указана точка, значит указанный сервис не предоставляется в соответствующем домене |
| Пример | _ldap._tcp.ms-dcs SRV 0 0 389 host1.test.fio.ru_ldap._tcp.ms-dcs SRV 10 0 389 host1.test.fio.ru |
Так как все необходимые записи SRV создаются системой автоматически, вряд ли вам понадобится добавлять или настраивать их вручную. Для работы Active Directory используются динамически обновляемые зоны, все обновления в которые система вносит самостоятельно. Если ваша зона обслуживается сервером, не поддерживающим DDNS (допустим, старые версии DNS-серверов для платформы UNIX), можно добавить все необходимые записи SRV в зону из файла %systemroot%system32Confignetlogon.dns. Он обновляется каждый раз при внесении изменений в конфигурацию AD.
Описание записи SOA| Как выполнить проверку записи SOA (+ пример)
Записи DNS обычно состоят из нескольких полей. В них вы найдете всю необходимую информацию. По сравнению с другими типами запись SOA имеет много полей:
- <имя> : имя зоны
- <класс> : сетевой класс
- <тип> : тип записи
- <имя> : имя главного устройства
-
-
-
-
-
- <минимум> : указание времени, в течение которого информация может храниться в кэше
Первые три поля типичны для DN S записей.Имя зоны — это доменное имя в форме полного доменного имени (FQDN). Это означает, что спецификация — отличная от того, что вы можете узнать по URL — заканчивается точкой. Причина этого в том, что полное доменное имя показывает полную иерархическую структуру домена, в конце которой находится корневой каталог. Это, конечно, пусто, поэтому остается только разделительный период. Вы найдете это обозначение во всех доменных именах DNS, а также в полях MNAME и RNAME.
Поле class имеет только историческую актуальность и по этой причине во многих случаях просто опускается.При разработке DNS были также проекты Hesiod (HS) и Chaos (CH). Оба сейчас устарели, поэтому в этом поле можно использовать только Интернет с аббревиатурой IN. Тип относится к типу используемой записи DNS, в данном случае SOA.
MNAME также известен как primary master и указывает, какой сервер расположен над подчиненным. Это сделано для того, чтобы определить сервер имен, через который подчиненный сервер должен попытаться выполнить передачу зоны.При форматировании адреса электронной почты в поле RNAME необходимо учитывать некоторые особенности. В обозначении не допускается использование символа @. Вместо этого точка отделяет локальную часть (например, имя пользователя) от домена. Если в исходном адресе электронной почты стоит точка перед символом @, его необходимо обозначить обратной косой чертой (\).
Серийный номер должен постепенно увеличиваться при каждом изменении файла зоны. Установились две версии.С одной стороны, простой процесс может начинаться с 1 и с каждым изменением серийного номера увеличиваться на 1. С помощью этой опции количество уже внесенных изменений можно прочитать по серийному номеру.
Другой вариант — выбрать формат даты : ГГГГММДДВВ. Первый начинается с четырехзначного обозначения года, за которым следуют месяц и день (каждый из которых состоит из двух позиций), и заканчивается спецификация, в свою очередь, двузначным номером версии. Таким образом, в этом формате можно определить дату создания версии.С каждым изменением, внесенным в один и тот же день, номер версии увеличивается на единицу. В новый день серийный номер переходит в соответствующее место, а номер версии сбрасывается на 00.
Запись SOA заканчивается тремя или четырьмя временными спецификациями — каждое в секундах. В первом поле (« Refresh ») указывается время задержки, пока ведомое устройство снова не запросит у ведущего текущую версию файла зоны. Если этот запрос останется без ответа, поле «Retry» определяет, когда должна быть выполнена новая попытка.Важно, чтобы эта спецификация была меньше предыдущей.
Если сервер, расположенный ниже в иерархии, не получает дальнейших ответов, третья спецификация времени (« Expire ») определяет, как долго файл зоны может еще использоваться, прежде чем сервер откажется от доставки информации DNS. Если сервер продолжит посылать старые данные файла зоны клиентам, отправляющим запросы, они могут стать недействительными. Это может привести к проблемам с подключением и угрозам безопасности.
Поле « минимум » завершает запись. Это соответствует времени жизни, о котором вы, возможно, знаете по другим типам записей DNS. Он определяет, как долго клиент может хранить запрошенную информацию в кэше, прежде чем должен быть отправлен новый запрос. Однако в большинстве случаев TTL устанавливается для всей зоны с помощью директивы $ TTL. Как только это будет сделано, нет необходимости выполнять его отдельно для каждой записи. Имя зоны также можно определить уже в начале файла, а затем присвоить ему директиву $ ORIGIN.
Запись всегда появляется в начале файла зоны.
Что такое запись SOA (Start of Authority)?
SOA означает начало полномочий. Запись SOA определяет начало авторитетной зоны DNS и задает глобальные параметры для этой зоны. Эти параметры включают в себя первичный сервер имен, адрес электронной почты администратора домена, серийный номер домена и несколько таймеров, относящихся к обновлению зоны.
Каждая зона DNS, зарегистрированная в ClouDNS, должна иметь запись SOA (начало авторизации).На каждую зону приходится одна запись SOA.
Пример записи SOA можно увидеть ниже:
$ dig SOA cloudns.net + короткий
pns1.cloudns.net. support.cloudns.net. 2020080526 7200 3600 1209600 60
Зачем вам нужна запись SOA?
Запись SOA содержит основную информацию о вашей зоне. Без этой информации ваша зона не сможет работать. Следовательно, обязательно иметь запись SOA для каждой из ваших зон.
Как создать запись SOA DNS?
SOA добавляется автоматически для каждой зоны DNS, размещенной на ClouDNS.Вы можете настроить значения SOA с помощью кнопки «Настройки SOA» для каждой из ваших Зон.
Примечание. Управление записями SOA недоступно для бесплатных пользователей.
Запись SOA имеет следующую структуру:
- Серийный номер — номер версии этого файла зоны. Увеличивайте это число при каждом изменении файла зоны. Важно увеличивать это значение каждый раз при внесении изменений, чтобы изменения распространялись на любые вторичные DNS-серверы.В нашей системе серийный номер автоматически увеличивается при каждом изменении зоны DNS.
- Первичный сервер имен (NS) — Имя хоста для первичного DNS-сервера для зоны. Основной NS, установленный по умолчанию, — ns11.cloudns.net. Если вы введете неверный первичный сервер имен, он будет изменен обратно на ns11.cloudns.net .
- Адрес электронной почты администратора DNS — адрес электронной почты лица, ответственного за администрирование файла зоны домена. Если вы введете неверный адрес электронной почты администратора DNS, он будет снова изменен на support @ cloudns.сеть.
- Частота обновления — Время в секундах, в течение которого вторичный DNS-сервер ожидает перед запросом записи SOA первичного DNS-сервера для проверки изменений. Частота обновления варьируется от 1200 до 43200 секунд.
- Retry Rate — Время в секундах, в течение которого вторичный сервер ожидает перед повторной попыткой неудачной передачи зоны. Обычно частота повторных попыток меньше частоты обновления. Значение по умолчанию — 1800 секунд. Частота повторных попыток варьируется от 180 до 2419200 секунд.
- Срок действия — время в секундах, в течение которого вторичный сервер будет продолжать попытки завершить передачу зоны. Если это время истечет до успешной передачи зоны, у вторичного сервера истечет срок действия файла зоны. Вторичный перестанет отвечать на запросы, так как считает свои данные слишком старыми, чтобы быть надежными. Значение по умолчанию — 1209600 секунд.
- TTL по умолчанию — минимальное значение времени жизни применяется ко всем записям ресурсов в файле зоны. Это значение предоставляется в ответах на запросы, чтобы сообщить другим серверам, как долго им следует хранить данные в кэше.Значение по умолчанию — 3600 секунд (1 час).
Как добавить запись SOA — Пошаговое видео:
запись SOA VS запись NS
Несмотря на то, что обе записи являются обязательными для нормальной работы ваших зон, их роли существенно различаются.
ЗаписьSOA — это своего рода документальная запись, автоматически генерируемая при первоначальном создании вашей зоны DNS. Он содержит ценную и обязательную информацию, такую как адрес электронной почты администратора DNS, первичный сервер имен, серийный номер зоны DNS и некоторые другие значения.
Записи NS идентифицируют серверы имен, отвечающие за вашу зону DNS. Другими словами, записи NS сообщают, с какими серверами можно заключить контракт для получения записей, относящихся к домену.
Как начать управлять записями SOA с помощью ClouDNS?
- Откройте бесплатную пробную учетную запись отсюда — бесплатно в течение 30 дней, обычная цена $ 2,95 / месяц (Premium S)
- Подтвердите свой адрес электронной почты
- Войдите в свою панель управления
- Создайте новый главный DNS с помощью кнопки [добавить новый] — подробнее здесь
- Щелкните значок настроек SOA и настройте его так, как вам нужно.
Поддержка записей SOA
ClouDNS обеспечивает полную поддержку записей SOA.Каждая зона DNS имеет запись SOA, но основные настройки — почта администратора, первичный сервер имен и т. Д. Могут быть изменены только клиентами с активной платной подпиской. Все планы хостинга DNS включают управление записями SOA:
FAQ
Вопрос: Почему я не вижу запись SOA вместе с другими записями на странице управления зоной DNS?
Ответ: Запись SOA не указана в стеке других ваших записей на странице управления зоной DNS. Его значения можно изменить с помощью кнопки «Настройки SOA» для каждой из ваших зон.
Вопрос: Я ваш бесплатный пользователь и хочу управлять своими данными SOA. Что мне нужно сделать?
Ответ: Настройки SOA доступны только для премиум-аккаунта. Вы должны выполнить обновление, чтобы управлять настройками SOA.
Вопрос: Онлайн-средства проверки тревожат меня сообщением «Первичный сервер имен не указан в родительском списке». Как исправить это предупреждение.
Ответ: Мы рекомендуем вам проверить настройки SOA и убедиться, что один из серверов имен вашего домена указан как первичный NS в записи SOA.Это обычное предупреждение, когда клиенты используют настраиваемые серверы имен, но для основного NS в записи SOA оставлено значение по умолчанию.
Проверка серийного номера в записи SOA
Вы можете использовать монитор DNS для проверки серийного номера, сообщенного сервером имен для домена. Серийный номер — это особое свойство доменного имени, которое сервер имен хранит в записи SOA (начало авторизации). Сервер имен увеличивает серийный номер каждый раз, когда изменяются настройки DNS для домена, и, наблюдая за серийным номером, вы будете знать момент изменения вашей записи DNS и получать предупреждения о возможном вмешательстве.В этой статье мы расскажем, как получить серийный номер и как настроить DNS-монитор для проверки значения.
Сначала вам нужно получить текущий серийный номер
Чтобы получить текущий серийный номер, необходимо выполнить запрос SOA.
- Открыть командное окно.
- Введите
nslookupи нажмите [Enter]. - Переключитесь на запрос записей SOA, набрав
set type = soaи нажмите [Enter]. - Введите имя домена, о котором идет речь, и нажмите [Enter].
Если текущий сервер имен может ответить на этот запрос, он предоставит вам содержимое записей SOA. Одно из возвращаемых значений — серийный номер. В приведенном ниже примере серийный номер 162337499.
Настройка монитора DNS для проверки записи SOA
Теперь, когда вы знаете серийный номер, вам нужно настроить монитор DNS для проверки записи SOA. Если вам нужна помощь в настройке монитора DNS, посетите нашу Академию.
- Откройте существующий монитор DNS или создайте новый монитор DNS
- Выберите SOA Record из раскрывающегося списка DNS Query
- Укажите IP-адрес или доменное имя для сервера имен, который вы хотите протестировать, в поле DNS-сервер .Оставьте это поле пустым, чтобы использовать локальный сервер имен на контрольной точке.
- Введите доменное имя, для которого вы хотите проверить запись SOA, в поле Test Value .
- Введите серийный номер, который вы хотите проверить, в поле Ожидаемый результат .
Примечание : Если сервер имен возвращает результат, результат содержит все значения записи SOA, а не только значение серийного номера. Есть уловка, позволяющая получить для справки все содержимое записи SOA.Хитрость заключается в том, чтобы заставить монитор выйти из строя, используя неверный ожидаемый результат. Например, введите «фиктивное значение теста» в поле Ожидаемый результат . При ошибках монитора вы получите все содержимое записи SOA в отчете об ошибках Check Detail (см. Пример ниже).
Рекомендациидля значений DNS SOA — Сетевой координационный центр RIPE
Дата публикации: 07 июня 1999 г.
Аннотация
Конфигурация и обслуживание зон DNS предлагают множество степеней свободы и, следовательно, несколько возможностей для совершения ошибок.Большинство DNS-зон сегодня небольшие, и их приходится настраивать и обслуживать неспециалистам. В этом документе даются рекомендации относительно того, какие значения использовать для записи ресурса SOA небольших стабильных зон DNS, чтобы помочь начинающим администраторам и способствовать стабильности и эффективности DNS.
1. Условные обозначения, используемые в этом документе
Доменные имена, используемые в этом документе, используются только в пояснительных целях, и не следует ожидать, что они приведут к полезной информации в реальной жизни [RFC 2606].
2.Справочная информация
Различные исследования DNS показывают, что подавляющее большинство сегодняшних DNS-зон занято очень небольшим количеством хостов. В большинстве случаев существует только HTTP-сервер, объявленный под общим именем «www», иногда сопровождаемый отдельными почтовыми или DNS-серверами или хостом-бастионом. Для многих из этих зон конфигурация затрагивается один раз при ее настройке, а затем остается без изменений на долгое время. Эти рекомендации нацелены на небольшие и стабильные зоны DNS. Есть много законных причин использовать разные значения, например.грамм. предлагаемые изменения или специальные приложения. Администраторам этих зон следует обратиться к одному из различных более подробных руководств или книг по DNS. Существует несколько других рекомендаций для значений SOA [RFC 1535, RFC 1912], которые не устарели в этом документе, но имеют другую направленность. На момент написания DNS-зоны обычно были более густонаселенными, и предполагалось, что их целевая аудитория будет больше интересоваться DNS. Интернет-провайдерам и поставщикам DNS-серверов рекомендуется использовать эту информацию для своих клиентов в инструментах настройки или в качестве значений по умолчанию.Дополнительные советы по начальной настройке сервера имен и конфигурации этого типа зоны можно найти в [DNSGUIDE1], [DNSGUIDE2].
3. Рекомендуемые значения SOA
example.com. 3600 SOA dns.example.com. hostmaster.example.com. (
19901; серийный YYYYMMDDnn
86400; обновить (24 часа)
7200; повторить попытку (2 часа)
3600000; истечь (1000 часов)
172800); минимум (2 дня)
4. Замечания и пояснения
Значения, представленные в примере.com SOA RR подробно рассмотрены. Одна из основных целей заключалась в обеспечении по возможности фиксированных значений вырезания и вставки вместо интервалов, чтобы снизить вероятность операционных проблем, вызванных неудачными комбинациями. Другие значения или наборы значений также будут работать, это один набор значений, который отражает успешную текущую практику в отношении масштабируемости и стабильности.
4.1 Значение MNAME
В спецификации DNS явно указано, что здесь должен быть указан первичный главный сервер.Значение необходимо определить и использовать. Особенно ошибочно повторять здесь имя зоны, если только это не приводит к действительному адресу первичного мастера.
4.2 Значение RNAME
RNAME предназначен для публикации адреса электронной почты человека или ролевой учетной записи, имеющей дело с этой зоной, с преобразованием «@» в «.». Лучшая практика — определить (и поддерживать) выделенный почтовый псевдоним hostmaster [RFC 2142] для операций DNS.
4.3. Серийный номер
Самая важная проблема заключается в том, чтобы это значение увеличивалось после любого изменения данных зоны.В целях отладки оказалось полезным закодировать дату модификации в серийном номере. Значение «199
01″ является примером схемы ГГГГММДДнн и должно быть заменено соответствующими значениями года (ГГГГ, четыре цифры), месяца (ММ, две цифры), дня месяца (ДД, две цифры) и версии на день (nn, две цифры). Первая версия дня должна иметь значение «01». Важно сохранить порядок год — месяц — день. Однако люди, использующие это как средство отладки, не должны полагаться на информацию о дате, поскольку опыт показывает, что после первоначальной настройки сохранение этого значения часто предоставляется функции автоматического увеличения, которую иногда предоставляет программное обеспечение.Существуют и другие схемы, документация по которым выходит за рамки этого документа.
4.4. Значения Refresh и Retry
Значения обновления и повтора в первую очередь влияют на специалиста по обслуживанию зоны и дополнительных поставщиков услуг и могут быть согласованы между ними. Выбранные здесь значения нацелены на масштабируемость. Современное программное обеспечение DNS реализует NOTIFY [RFC 1996] и снижает потребность в частых проверках SOA, как и предположение о стабильности зоны. Хотя более низкие значения лишь немного увеличивают использование полосы пропускания, они увеличивают нагрузку на серверы, которые являются подчиненными для тысяч зон.
4.5. Срок действия
Основная цель — обеспечить стабильность данных зоны, даже если ошибка, сделавшая зону недействительной (неавторизованной), или отключение сети длилось несколько дней. Значение в одну или две недели оказалось слишком коротким, поэтому необходимо использовать более длительное время. Конкретное значение было выбрано по эстетическим и историческим причинам, а также для устранения неоднозначности между различными предлагаемыми значениями «long».
4.6. Минимальное значение TTL
У этого значения есть два значения, имеющих практическое значение.Во-первых, он служит значением по умолчанию для TTL всех RR без заданного значения. Для удобства кеширования это значение было выбрано равным двум дням, что также соответствует предположению о стабильности. Второе значение — отрицательный TTL по умолчанию [RFC 2308], который требует более низкого значения. Сейчас мы находимся в фазе перехода с программным обеспечением, реализующим любое из обоих значений, поэтому для самой SOA рекомендуется TTL в один час, что приведет почти к такому же эффекту.
5. Соображения безопасности
Заполнение рекомендуемых значений не повлияет напрямую на безопасность серверов имен для конкретной зоны, любой системы с именем в этой зоне или любой другой системы в Интернете.Однако следование этим рекомендациям, вероятно, будет способствовать стабильности DNS и, следовательно, доступности. Сохранение правильной контактной информации в поле SOA RNAME помогает людям сообщать о проблемах, хотя распространенный там адрес не рекомендуется в качестве основного контакта для обеспечения безопасности.
6. Благодарности
Эта работа является продуктом рабочей группы RIPE DNS.
7. Список литературы
[RFC 1034] Mockapetris, P., «Доменные имена - концепции и средства»,
RFC 1034, STD 13, ноябрь 1987 г.
[RFC 1035] Mockapetris, P., «Имена доменов - реализация и спецификация
», RFC 1035, STD 13, ноябрь 1987 г.
[RFC 1123] Брейден, Р., «Требования к хостам Интернета - приложение
и поддержка», RFC 1123, STD 3, октябрь 1989
[RFC 1537] Бертема, П., «Общие ошибки конфигурации файлов данных DNS»,
RFC 1537, октябрь 1993 г.
[RFC 1912] Барр, Д., «Общие ошибки эксплуатации и конфигурации DNS
», RFC 1912, Февраль 1996 г.
[RFC 1996] Викси П., «Механизм быстрого уведомления об изменениях зоны
(DNS NOTIFY)», RFC 1996, август 1996 г.
[RFC 2142] Crocker, D., «ИМЕНА ПОЧТОВЫХ ЯЩИКОВ ДЛЯ ОБЩИХ УСЛУГ, РОЛЕЙ И ФУНКЦИЙ
», RFC 2142, май 1997 г.
[RFC 2308] Эндрюс, М., «Отрицательное кэширование запросов DNS (DNS
NCACHE)», RFC 2308, март 1998 г.
[RFC 2606] Истлейк Д., Паниц А., «Зарезервированные DNS-имена верхнего уровня»,
RFC 2606, BCP 32, июнь 1999 г.
[DNSGUIDE1] Лиман, Л., «ПРИМЕР ПРОСТОЙ КОНФИГУРАЦИИ DNS», работа
, прогресс
[DNSGUIDE2] Кох, П., «Руководство RIPE по настройке DNS-сервера», работа
, прогресс
8.Адрес автора
Peter Koch
Universitaet Bielefeld
Technische Fakultaet
Postfach 10 01 31
D-33501 Bielefeld
Germany
+49 521 106 2902
Проверить записи DNS SOA | Проверка DNS
Запись SOA - это запись DNS, которая определяет глобальные параметры для файла зоны (домена). Каждый файл зоны имеет ровно одну запись SOA.
Записи SOAтакже называются «Начальными авторитетными записями» и определены в RFC 1035.
На этой странице представлен краткий обзор записей SOA. Более подробное обсуждение находится в нашей записи блога о мониторинге записи SOA.
DNS Check может отслеживать ваши записи SOA и уведомлять вас, если они становятся неразрешимыми или имеют какие-либо изменения параметров.
Поля
Запись SOA обычно является самой сложной записью в файле зоны. Вот поля, из которых состоит запись SOA:
Поле Описание Пример Имя Полное доменное имя (FQDN) файла зоны. dnscheck.co. Тип Тип записи DNS. Всегда установлен на SOA. SOA Сервер имен Авторитетный сервер имен для домена. В списке должен быть только один сервер имен, даже если в домене есть несколько авторитетных серверов имен. chan.ns.cloudflare.com. Эл. Почта Электронный адрес администратора домена.Знак @ следует заменить точкой (.). dns.cloudflare.com. Серийный номер Действует как «номер версии» для записи SOA. Он увеличивается каждый раз, когда обновляется файл зоны, в котором находится запись SOA. Допустимые значения: от 1 до 4 294 967 295. 2019756054 Обновить Время в секундах, в течение которого подчиненный сервер имен должен ожидать перед обновлением файла зоны от главного. 10000 Повторить Время в секундах, в течение которого подчиненный сервер имен должен ждать перед повторной попыткой установить соединение с главным сервером после ошибки связи. 2400 Срок действия Время в секундах, которое может пройти до того, как файл зоны перестанет считаться авторитетным. 604800 Минимум Время в секундах для кэширования результатов NXDOMAIN в DNS. 3600 Примеры файлов зоны DNS
Вот пример того, как запись SOA, в которой используются примеры значений из раздела полей этой страницы, выглядит в файле зоны DNS:
; Имя Тип Имя сервер Электронная почта Последовательное обновление Повторная попытка Срок действия Минимум dnscheck.co. SOA chan.ns.cloudflare.com. dns.cloudflare.com. 2019756054 10000 2400 604800 3600Поля «Имя», «Сервер имен» и «Электронная почта» в приведенном выше примере заканчиваются точкой, поэтому они используют полностью определенные доменные имена.
В качестве альтернативы вы можете создать запись SOA относительно $ ORIGIN файла зоны. Вот пример того, как это сделать, используя примеры значений из раздела Поля этой страницы:
$ ORIGIN dnscheck.co. ; Имя Тип Имя сервер Электронная почта Последовательное обновление Повторная попытка Срок действия Минимум @ SOA chan.ns.cloudflare.com. днс 2019756054 10000 2400 604800 3600Дополнительные ресурсы
- Check Your DNS MX Records - сообщение в блоге, в котором подробно описывается, для чего используются записи SOA, их поля и способы их отслеживания.
- RFC 1035 - раздел 3.3.13 (формат SOA RDATA) определяет формат, которому следуют записи SOA.
Зарегистрируйтесь, чтобы получить бесплатную учетную запись
Анатомия файла зоны DNS: запись SOA
Часть ПЕРВАЯ Что такое начальная запись (SOA) и для чего она нужна? Первой записью ресурса в любом файле зоны системы доменных имен (DNS) является запись ресурса начала полномочий (SOA). Запись ресурса SOA является важной частью файла зоны DNS, она указывает основные свойства сервера доменных имен и зону, в которой находится домен.Каждый файл зоны может содержать только одну запись SOA. Запись SOA разбита на следующие поля. (См. Пример ниже: каждый раздел имеет цветовую кодировку, чтобы соответствовать определению соответствующего поля)
;; РАЗДЕЛ ВОПРОСОВ:; no-ip.com. В SOA;; РАЗДЕЛ ОТВЕТОВ: no-ip.com. 565 В SOA ns2.no-ip.com. hostmaster.no-ip.com. 2036909809 600 300 604800 600
- имя - корневое имя зоны.
- TTL- Time-to-Live, это период времени, в течение которого для файла зоны установлен срок действия.Обычно это выражается в секундах.
- class - определяет класс записи. IN означает Интернет.
- name-server : Имя первичного сервера имён для зоны
.- email-addr : адрес электронной почты человека, ответственного за домен. Это человек, которому следует направлять электронные письма, чтобы сообщить об ошибках или проблемах с доменом.
- sn = серийный номер : Серийный номер зоны.Этот номер помогает отслеживать изменения, внесенные в файл зоны DNS. При внесении изменений число должно увеличиваться. Стандартное соглашение - ГГГГММДДнн, где ГГГГММДД - это дата ревизии, а nn - номер ревизии (в случае, если есть несколько ревизий за день). Итак, сегодняшняя первая редакция будет 2011030200, а вторая - 2011030201.
- обновление : время ожидания вторичным DNS-сервером перед проверкой наличия изменений в зоне.
- retry : Время, в течение которого вторичный DNS-сервер должен ждать перед повторной попыткой проверить, были ли изменения в зоне (если первое обновление не удалось).
- expiry : Время в секундах до того, как вторичный DNS-сервер перестанет отвечать на запросы зоны.
- мин = минимум : минимальное время жизни (TTL). Это значение предоставляется в ответах на запросы серверов для зоны, чтобы сообщить другим, как долго они должны кэшировать запись ресурса, предоставленную в ответе.
Правильно оптимизированная и обновленная запись SOA может уменьшить полосу пропускания между серверами имен, увеличить скорость доступа к веб-сайту и обеспечить его работоспособность, даже если основной DNS-сервер не работает. Пожалуйста, оставьте любые вопросы или комментарии ниже ... Ознакомьтесь с Частью 2 и Частью 3 этой серии:
, часть вторая: что такое записи NS и почему они важны для DNS
Анатомия файла зоны DNS, часть третья: записи MX
запись SOA | Управляемая служба DNS
Что такое запись SOA?
Запись SOA означает начало авторитетной записи и определяет, как ваша зона распространяется на вторичные серверы имен.Каждая зона DNS должна иметь одну запись SOA, и это первая запись в зоне. Провайдер хостинга DNS обычно создает запись SOA по умолчанию для каждого домена, добавляемого в их систему, и обычно вам не нужно вносить изменения в эту запись.Запись SOA хранит информацию об имени сервера, который предоставил данные для зоны; администратор зоны; текущая версия файла данных; количество секунд, в течение которых вторичный сервер имен должен ждать перед проверкой обновлений; количество секунд, в течение которых вторичный сервер имен должен ждать перед повторной попыткой неудачной передачи зоны; максимальное количество секунд, в течение которых вторичный сервер имен может использовать данные, прежде чем они должны быть обновлены или истекли; и количество секунд по умолчанию для файла времени жизни в записях ресурсов, для которых он не указан.
Формат записи SOA
Типичная запись SOA в стандартном формате BIND выглядит следующим образом:TTL 1800 ; $ TTL используется для всех записей DNS без явного значения TTL $ ORIGIN example.com. ; обозначает начало этого файла зоны в пространстве имен @ 86400 В SOA ns1.dynu.com. administrator.dynu.com. ( 25101 ; серийный 1800 ; обновить 300 ; повторить попытку 86400 ; истекает 300 ; nxdomain TTL )Анатомия записи SOA выглядит так:
Метка хоста TTL Класс записи Тип записи Имя Мастера Ответственное имя пример.com. 86400 В SOA ns1.dynu.com. administrator.dynu.com. Метка хоста
Серийный номер Интервал обновления Интервал повтора Срок действия TTL для отрицательного кэширования 25101 1800 300 86400 300
Он определяет имя хоста записи и то, будет ли имя хоста добавлено к метке.Полные имена хостов, заканчивающиеся точкой, не добавляют источник.TTL
Время жизни в секундах. Он указывает, как долго распознаватель должен кэшировать или запоминать DNS-запрос перед срок действия запроса истекает, и необходимо выполнить новый.Класс записи
В основном существует 3 класса DNS-записей:Тип записи
- IN (Интернет) - по умолчанию и обычно то, что использует Интернет.
- CH (Chaosnet) - используется для запроса версий DNS-сервера.
- HS (Hesiod) - использует функции DNS для обеспечения доступа к базам данных с нечасто изменяющейся информацией.
Формат записи определяется с помощью этого поля. Общие типы записей: A, AAAA, CNAME, CAA, TXT и т. Д.В случае записи SOA тип записи - SOA.Имя Мастера
Имя хоста для основного DNS-сервера для зоны.Ответственное имя
Адрес электронной почты человека, ответственного за администрирование файла зоны домена. Символ @ в адресе электронной почты заменяется точкой.'. Итак, administrator.dynu.com - это [email protected].Серийный номер
Серийный номер для этой зоны - это временная метка, которая меняется всякий раз, когда что-то меняется в зоне. Если вторичный сервер имен, подчиненный этой главной зоне, наблюдает увеличение этого числа, ведомое устройство предположит, что зона была обновлена, и инициирует передачу зоны.Интервал обновления
Время в секундах, в течение которого вторичный DNS-сервер ожидает перед запросом записи SOA первичного DNS-сервера для проверки изменений.Интервал повтора
Количество секунд до повторной попытки неудачного обновления.Срок действия
Время в секундах до того, как зона больше не считается авторитетной. Если это время истечет до успешной передачи зоны, у вторичного сервера истечет срок действия файла зоны.Вторичный перестанет отвечать на запросы, так как считает свои данные слишком старыми, чтобы быть надежными.TTL для отрицательного кэширования
Глоссарий записей SOA
Отрицательный результат TTL. Например, если преобразователь DNS выполняет запрос DNS к поддомену и получает отрицательный результат. Отрицательный TTL кэширования сообщает преобразователю, как долго ждать перед повторной попыткой запроса.
Зона DNS
Зона DNS относится к определенной части или административному пространству в глобальной системе доменных имен (DNS) и содержит записи ресурсов для всех имен в конкретной зоне.. Все записи в зоне домена, например субдомены (sub.domain.com), или запись MX находятся в этой зоне.Мастер / основная зона
И главный, и подчиненный серверы являются полномочными для зон, которые они обрабатывают. Когда дело доходит до ответов на запросы DNS, ведущее устройство не имеет большей власти над зонами, чем ведомое устройство. Единственная разница между главным и подчиненным серверами заключается в том, откуда они читают свои файлы зон.Главный сервер считывает файлы своей зоны из файлов на системном диске. Обычно здесь администратор зоны создает, редактирует или передает исходные файлы зоны.Подчиненная / вторичная зона
Подчиненный сервер получает зоны, для которых он является полномочным, посредством передачи зоны от одного из главных серверов для зоны.Кеширование DNS
Кэширование DNS работает путем временного хранения результатов DNS-запросов недавно посещенных веб-сайтов, или другие полные доменные имена в локальном файле для более быстрого поиска. Кэш DNS - это временное хранилище информации о предыдущих результатах поиска DNS в операционной системе компьютера или в веб-браузере. Записи DNS хранятся в кеше в основном для повышения производительности DNS-запросов.