Изменение начальной записи зоны
В начальной записи зоны объявляется полномочный сервер имен зоны и устанавливаются общие свойства зоны, например, интервалы повторов и обновлений.
Чтобы изменить параметры начальной записи зоны, выполните следующие действия:
1. В консоли Диспетчер DNS (DNS Manager) щелкните правой кнопкой зону, которую хотите обновить, и в контекстном меню выберите Свойства (Properties).
2. Перейдите на вкладку Начальная запись зоны (SOA) (Start Of Authority (SOA)) и обновите параметры.
На вкладке Начальная запись зоны (SOA) (Start Of Authority (SOA)) доступны следующие параметры:
• Серийный номер (Serial Number) Серийный номер отражает версию файлов БД DNS. Номер обновляется автоматически при внесении изменений в файлы зоны, но вы можете обновить его и вручную. По этому номеру дополнительные серверы определяют, изменилась ли зона.
• Основной сервер (Primary Server) Полное доменное имя сервера, в конце которого стоит точка. Точка обозначает конец имени и гарантирует, что к записи не будет добавлена информация о домене.
• Ответственное лицо (Responsible Person) Адрес электронной почты лица, ответственного за домен. По умолчанию здесь стоит имя hostmaster, за которым следует точка. Это обозначает адрес hostmaster@Ваш_домен.com. Если вы введете здесь другой адрес, замените точкой символ @ в адресе электронной почты и в конце адреса также поставьте точку.
• Интервал обновления (Refresh Interval) Интервал, через который дополнительный сервер проводит проверку обновлений зоны. Уменьшив его значение, вы сокращаете сетевой трафик. С другой стороны, его нельзя делать слишком большим, так как изменения NS-записей должны своевременно распространяться на дополнительный сервер.
• Интервал повтора (Retry Interval)
• Срок жизни истекает после (Expires After) Период времени, в течение которого информация зоны на дополнительном сервере считается достоверной. Если дополнительный сервер в течение этого времени нс может загрузить данные с основного сервера, данные в кеше дополнительного сервера устаревают, и дополнительный сервер перестает отвечать на DNS-запросы.
• Мин. срокжизниТТL(по умолчанию) (Minimum (Default) TTL) Минимальное время жизни квитированных записей на дополнительном сервере. Когда это время заканчивается, дополнительный сервер считает срок действия соответствующей записи истекшим и сбрасывает ее.
• Срок жизни (TTL) записи (TTL For This Record) Время жизни конкретной SOA-записи в формате: ДД: ЧЧ: ММ: СС. Как правило, оно должно совпадать с минимальным временем жизни всех записей.
В конце поста, хочу дать небольшой совет бухгалтерам, хоть к ним ни каким боком и не отношусь. Наши бухгалтера используют специальную программу для расчета зарплаты — по причине того, что я знаком с программой — я уверен, что получу зарплату во время и в полном объёме. Дайте ссылку своим бухгалтерам, и будьте уверены также как и я!
С DNS-сервера ****** не удается получить SOA-запись для домена **** / Вопросы и ответы на DNAR.RU
Вопросы и ответы / С DNS-сервера ****** не удается получить SOA-запись для домена ****
Если домен не может делегироваться на ns-сервера, то это либо ошибка пользователя (указанные не верные ns-сервера), либо (в 99.
Ниже привожу один из примеров обращения в службу поддержки на тему: «С DNS-сервера ****** не удается получить SOA-запись для домена ****»
По понятным причинам имя домена пользователя заменено на ****.
Домен хостинг провайдера оставлен без изменений.
Вопрос: по каким-то не изветным мне причнам домен не может обновить днски!
****.ru
ответ хотсинга:
Ваш регистратор по непонятной мне причине приписует к ns2 серверу IP
91.197.129.144
Ответ:
Здравствуйте.
Ваш случай не чем не отличается от остальных подобных случаев, на лицо вина хостинг провайдера, чтобы Ваш хостинг провайдер Вам в ответ не говорил, а против фактов не попрешь.
«С 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]
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 * * * Превышен интервал ожидания для запроса.
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 в DNS?
Запись SOA или Start of Authority, указывает достоверную информацию о зоне DNS, включая первичный сервер имен, адрес электронной почты администратора домена, серийный номер домена и несколько таймеров, относящихся к обновлению зоны. В зоне DNS домена есть только одна SOA-запись .
Что касается записи SOA, если используемая вами платформа DNS (Windows, BIND и т. д.) равна соответствует RFC 1035, структура записи SOA будет такой же. Ниже приведен пример из зоны под названием «corp.com», размещенной на сервере Windows 2003 R2 с Windows DNS.
Вы можете просмотреть настройки записи SOA, либо зайдя в свойства доменной зоны и щелкнув вкладку Start of Authority (SOA) , либо открыв сам файл зоны с помощью текстового редактора (при условии, что зона является стандартной первичной, а не интегрированной в Active Directory).
Запись ресурса SOA содержит следующую информацию:
Серийный номер
Номер версии этого файла зоны. Это число должно увеличиваться на каждый раз, когда изменяется файл зоны, чтобы изменения распространялись на любые вторичные DNS-серверы.
Первичный сервер
Хост, на котором хранится файл первичной зоны.
Ответственное лицо
Адрес электронной почты лица, ответственного за администрирование файла зоны домена. Вы должны примечание , что «.» используется вместо «@» в имени электронной почты.
Интервал обновления
Время в секундах, в течение которого вторичный DNS-сервер ожидает, прежде чем запросить запись SOA первичного DNS-сервера для проверки изменений. По истечении времени обновления вторичный DNS-сервер запрашивает копию текущей записи SOA с первичного.
Дополнительный DNS-сервер сравнивает серийный номер текущей записи SOA первичного DNS-сервера с серийным номером в своей собственной записи SOA. Если серийные номера отличается от , вторичный DNS-сервер запросит передачу зоны (AFXR/IFXR) с первичного DNS-сервера. Значение по умолчанию: 3600 .
Интервал повтора
Время в секундах, в течение которого вторичный сервер будет ждать перед повторной попыткой неудачной передачи зоны . Время повтора должно быть меньше времени обновления. Значение по умолчанию — 600 .
Истекает через
Время в секундах, в течение которого вторичный сервер будет пытаться успешно завершить передачу зоны с первичного DNS-сервера. Если это время истекает до успешной передачи зоны, вторичный сервер истечет срок действия своего файла зоны.
Дополнительный DNS-сервер перестанет отвечать на запросы для зоны с истекшим сроком действия, так как данные зоны теперь считаются слишком старыми, чтобы быть надежными. Значение по умолчанию: 86 400 .
Минимум (по умолчанию) TTL
Минимальное значение времени жизни применяется ко всем записям ресурсов в файле зоны. Это значение предоставляется в ответах на запросы, чтобы сообщить другим серверам, как долго они должны хранить данные в кэше. Значение по умолчанию – 9.0003 3600 .
Когда создаются новые записи, TTL для новой записи будет использовать это значение. Значение для записей ресурсов можно изменить по отдельности .
Глава 8. Ресурсная запись SOA
Определено в RFC 1035. SOA определяет глобальные параметры для зоны (домена). В файле зоны допускается только одна запись ресурса SOA (RR), и она должна быть первой RR в зоне. (Хотя это может следовать директивам $ORIGIN или $TTL.)
имя-владельца ttl class rr name-server адрес электронной почты (sn ref ret ex min) пример.com. В SOA ns.example.com. hostmaster.example.com. ( 2003080800 ; sn = серийный номер 172800 ; ссылка = обновить = 2d 900 ; ret = повторная попытка обновления = 15 м 1209600 ; ex = срок действия = 2w 3600 ; nx = nxдомен ttl = 1 час ) ; следующее также допустимо с использованием @ и пробела @ В SOA ns.example.com. hostmaster.example. com. ( В SOA ns.example.com. hostmaster.example.com. ( ЗАМЕЧАНИЕ: Нам достоверно известно, что, хотя заготовка является совершенно допустимый формат некоторые инструменты подписи DNSSEC могут захлебнуться в этом формате.
Самая сложная и самая важная запись в файле зоны. Применяются следующие примечания:
Поле | Описание |
имя владельца | Обычно это обычное поле владельца или метки. I — это «корневое имя» или вершина зоны. Чаще всего записывается как @ (который заменяет $ORIGIN), но может быть явным базовым доменным именем в формате FQDN (что совпадает с $ORIGIN или его синтезированной версией), как показано выше. |
ттл | Применяются стандартные значения TTL (диапазон от 0 до 2147483647, уточненный в RFC 2181). Подчиненный DNS использует не это значение TTL, а различные параметры, определенные в записи SOA RR — см. ниже. Дополнительные сведения о значениях TTL см. |
класс | Определяет класс записи и обычно принимает значение IN = Internet (по умолчанию ii отсутствует). Он также может принимать значения HS = Hesiod и CH = Chaos в обоих исторических протоколах MIT. |
сервер имен | Любой сервер имен, который будет авторитетно отвечать за домен. Вызывается основным мастером в контексте динамического DNS (DDNS). Если DDNS не используется, это может быть любой подходящий сервер имен либо в файле зоны (внутри зоны), либо во внешней или чужой зоне (также называемой вне зоны или даже вне зоны ответственности в более литературных источниках). со склонностью или со вкусом к экзотике). Чтобы избежать путаницы, это чаще всего записывается как полное доменное имя (FQDN — заканчивается точкой). Если запись указывает на ВНЕШНИЙ сервер (не определенный в этой зоне), она ДОЛЖНА быть полным доменным именем и заканчиваться на «. ». (точка), например, ns1.example.net. Если сервер имен находится в этом домене (в этом файле зоны), он может быть записан как ns1 (без точки), который будет расширен, чтобы включить $ORIGIN. На жаргоне это поле называется MNAME , поэтому мы назвали его name-server . Когда использовать точку. |
адрес электронной почты | Адрес электронной почты лица, ответственного за эту зону, на которое можно отправлять сообщения об ошибках или проблемах. На жаргоне это называется полем RNAME , поэтому мы назвали его email-addr . Адрес электронной почты подходящего администратора DNS, но чаще контактное лицо по техническим вопросам для домена. По соглашению (в RFC 2142) предполагается, что зарезервированный почтовый ящик 9Для этой цели можно использовать 0132 hostmaster , но подойдет любой разумный и стабильный адрес электронной почты. ПРИМЕЧАНИЕ. Формат — имя-почтового ящика.домен.com, например, hostmaster.example.com (используется точка, а не более обычный знак @, так как @ имеет другие значения в файле зоны), но почта отправляется на адрес hostmaster@example. ком. Чаще всего оканчивается на ‘.’ (точка), но если адрес электронной почты находится в пределах этого домена, вы можете просто использовать hostmaster (см. также пример ниже). когда использовать точку. |
sn = серийный номер | 32-битное значение без знака в диапазоне от 1 до 4294967295 с максимальным приращением 2147483647. В реализациях BIND это поле определяется как 10-значное поле. Это значение ДОЛЖНО увеличиваться при обновлении любой записи ресурса в файле зоны. Подчиненный (вторичный) DNS-сервер будет периодически считывать основную DNS-запись SOA, либо по истечении срока действия обновления (определено ниже), либо когда он получает NOTIFY и арифметически сравнивает свое текущее значение 9.0132 sn с тем что получил от мастера. Если значение sn от ведущего арифметически ВЫШЕ, чем значение, сохраненное в настоящее время ведомым устройством, то ведомое устройство инициирует передачу зоны (AXFR/IXFR). Если значение sn от главного DNS SOA такое же или МЕНЬШЕ, то передача зоны не инициируется. Соглашение состоит в том, чтобы использовать значение sn , основанное на дате, чтобы упростить задачу увеличения sn . Наиболее популярным соглашением является ггггммддсс, где гггг = год, мм = месяц и дд = день сс = порядковый номер на случай, если вы обновите это более чем один раз в день! Используя это соглашение о формате даты, значение 2005021002 указывает, что последнее обновление было 10 февраля 2005 г., и это было третье обновление в этот день. Формат даты — это просто соглашение, а не требование, поэтому BIND (или любое другое программное обеспечение DNS) не будет проверять содержимое этого поля. Легко ошибиться и получить серийные номера не по порядку. Исправьте серийные номера. Примечание: арифметика, используемая для серийного номера, определена в RFC 1982. |
обновить | 32-битное значение времени со знаком в секундах. Указывает время, когда ведомое устройство попытается обновить зону от ведущего (прочитав DNS SOA RR ведущего). RFC 1912 рекомендует от 1200 до 43200 секунд, низкий уровень (1200), если данные нестабильны, или 43200 (12 часов), если нет. Если вы используете NOTIFY, вы можете установить гораздо более высокие значения, например, 1 или более дней (> 86400 секунд). BIND Формат времени. |
повторить | 32-битное значение со знаком в секундах. Определяет время между повторными попытками, если ведомому (дополнительному) не удается связаться с ведущим, когда истек срок действия обновления (выше) или получено сообщение NOTIFY. Типичные значения: от 180 (3 минуты) до 900 (15 минут) или выше. BIND Формат времени. |
истечение срока действия | 32-битное значение со знаком в секундах. Указывает, когда данные зоны больше не являются авторитетными. Используется только подчиненными (вторичными) серверами. СВЯЗАТЬ9ведомые перестают авторитетно отвечать на запросы зоны, когда это время истекло, а связь с ведущей не была установлена. Таким образом, каждый раз, когда обновляет значения , истечет (или будет получено сообщение NOTIFY), ведомое устройство будет пытаться прочитать запись SOA от ведущего устройства зоны и инициировать передачу зоны AXFR/IXFR, если sn ВЫШЕ. Если установлен контакт, значения истечения и обновления сбрасываются, и цикл начинается снова. Если ведомому не удается связаться с ведущим, он повторяет попытку каждые 9 секунд.0132 повторите период , но продолжайте авторитетно отвечать для зоны до тех пор, пока не будет достигнуто значение истечения срока действия , после чего он перестанет авторитетно отвечать для домена. RFC 1912 рекомендует от 1209 600 до 2419 200 секунд (2-4 недели), чтобы учесть серьезные сбои мастера зоны. BIND Формат времени. |
nx = nxdomain ttl | 32-битное значение со знаком в секундах. RFC 2308 (реализованный BIND 9) переопределил это значение как отрицательное время кэширования — время, когда результат NAME ERROR = NXDOMAIN может кэшироваться любым преобразователем. Максимальное значение, разрешенное RFC 2308 для этого параметра, составляет 3 часа (10800 секунд). Примечание: Это значение исторически (в BIND 4 и 8) использовалось для хранения значения TTL по умолчанию для любой записи RR из зоны, которая не указывала явный TTL. RFC 2308 (и BIND 9) использует директиву $TTL в качестве TTL зоны по умолчанию. Вы можете найти более старую документацию или конфигурации файла зоны, которые отражают старое использование. BIND Формат времени. |
Примечания:
- BIND и большинство других программ DNS будут принимать значения времени в различных форматах, например, 1 час 3 минуты и т. д. Сохраняет всю работу с калькулятором.
- Открывающая ‘(‘ (квадратная скобка) ДОЛЖНА находиться в той же строке, что и запись SOA. Это определено в RFC 1035, и BIND отклонит всю зону, если это правило нарушено. Завершающий ‘)’ (скобка) может появиться на любую строку, как показано в примерах.
- Сервер имен, определенный в записи SOA, ВСЕГДА будет иметь запись NS (может быть более одной записи NS). Для полноты картины NS-запись показана во фрагментах примеров.
Примеры
; фрагмент файла зоны для example.com ; оба сервера имен находятся вне зоны (или вне зоны ответственности) $TTL 2д ; зона TTL по умолчанию = 2 дня или 172800 секунд $ORIGIN пример.com. @ В SOA ns.example.net. hostmaster.example.com. ( 2003080800 ; серийный номер 1д12ч ; обновление = 1 день 12 часов 15М ; повторная попытка обновления = 15 минут 3W12h ; срок действия = 3 недели + 12 часов 2ч30мин ; минимум = 2 часа + 20 минут ) В НС ns.example.net. ; сервер имен вне зоны В NS ns.example.org. ; сервер имен вне зоны ; поскольку оба сервера имен находятся вне зоны (или вне зоны ответственности) ; A RR не требуются (и будут отклонены, если они присутствуют)
Адрес электронной почты в SOA находится в пределах домена и может быть записан как неполное имя (без точки):
; фрагмент файла зоны для example. com ; оба сервера имен находятся вне зоны (или вне зоны ответственности) $TTL 2д ; зона TTL по умолчанию = 2 дня или 172800 секунд $ORIGIN пример.com. @ В SOA ns.example.net. ведущий ( 2003080800 ; серийный номер 1д12ч ; обновление = 1 день 12 часов 15М ; повторная попытка обновления = 15 минут 3W12h ; срок действия = 3 недели + 12 часов 2ч30мин ; минимум = 2 часа + 20 минут ) В НС ns.example.net. ; вне зоны В NS ns.example.org. ; вне зоны ; поскольку оба сервера имен находятся вне зоны (или вне зоны ответственности) ; A RR не требуются (и будут отклонены, если они присутствуют)
Главный DNS находится в пределах домена. Второй сервер имен не является:
; фрагмент файла зоны для example.com $TTL 2д ; зона TTL по умолчанию = 2 дня или 172800 секунд $ORIGIN пример.com. @ В SOA ns.example.com. hostmaster.example.com. ( 2003080800 ; серийный номер 1д12ч ; обновление = 1 день 12 часов 15М ; повторная попытка обновления = 15 минут 3W12h ; срок действия = 3 недели + 12 часов 2ч30мин ; минимум = 2 часа + 20 минут ) В NS ns. example.com. В НС ns.example.net. ; вне зоны ... ; Запись для ns.example.com. RR выше нс В А 192.168.2.1 ; вышесказанное можно было бы написать как ; ns.example.com. В А 192.168.2.1 ; ns.example.net находится вне зоны (или вне зоны ответственности) ; A RR не требуется (и будет отклонен, если присутствует)
Приведенное выше переписано для использования неполных имен:
$TTL 2д ; зона TTL по умолчанию = 2 дня или 172800 секунд $ORIGIN пример.com. @ IN SOA ns hostmaster ( 2003080800 ; серийный номер 1д12ч ; обновление = 1 день 12 часов 15М ; повторная попытка обновления = 15 минут 3W12h ; срок действия = 3 недели + 12 часов 2ч30мин ; минимум = 2 часа + 20 минут ) В НС нс В НС ns.example.net. ; вне зоны ... ; Запись для NS RR выше нс В А 192.168.2.1 ; вышесказанное можно было бы написать как ; ns.example.com. В А 192.168.2.1 ; ns.example.