Soa dns что это: Страница не найдена | REG.RU

Содержание

Проверка DNS-записей домена — утилита dig | Проверка PTR, MX, A, NS, TXT, SOA, CNAME | Check DNS

Купить Корзина

ПодобратьWhois

Регистрация      Вход
  • Все услуги
    •  
    • Домены
      • Регистрация Зарегистрировать домен Перенос доменов в REG.
        RU Освобождающиеся домены Регистрация доменов списком Премиум-домены Освобождённые домены Новые доменные зоны REG.RU Энциклопедия доменных зон Географические домены Подбор по ключевому слову
      • Купить-продать Магазин доменов Доменный брокер Гарант сделки Бесплатный подбор домена Экспертная оценка домена Специальное Условия и цены для Партнёров Юридическое сопровождение Нотариальное заверениесайтаnew
      • Операции Продление регистрации Смена администратора Изменение данных Перенос доменов между аккаунтами Смена регистратора Договоры и письма Онлайн-операции с доменами
      • Мои домены
    • Конструктор и CMS
      • Конструкторы сайтов Конструктор сайтов REG. RU Конструктор лендингов Лицензии Купить Лицензию 1С-Битрикс Продлить Лицензию 1С-Битрикс
      • Сайты на CMS 1С-Битрикс Joomla WordPress
      • Сервисы Переадресация домена Парковочная страница
      • Мои услуги
    • Хостинг
      • Популярное Хостинг сайтов Конструктор сайтов REG. RU Бесплатная почта
      • Спецрешения
        Хостинг для 1C-Битрикс Хостинг для Joomla Хостинг для ASP.NET Хостинг для WordPress Хостинг для OpenCart Пакет Хостинг + Домен Сервер для бизнесаnew
      • Операции Продление Изменение владельца Договоры и письма Бесплатный перенос
      • Мои услуги

    • VPS
      • Обзор VPS Облачные VPS Облачные серверы Высокочастотные VPSnew Приложения ISPmanager LEMP Docker Снэпшоты VPS с администрированием
      • Классические VPS VPS на Linux VPS на Windows Спецрешения Jelastic PaaS Виртуальный дата-центр VMware Серверы для 1С
      • Операции Продление Изменение владельца Перенос услуг внутри REG. RU Договоры и письма
      • Мои услуги

    • Серверы и ДЦ
      • Популярное Dedicated-серверы Colocation Администрирование сервера Выделенные серверы для 1С Выделенные серверы с GPU
      • Облачная инфраструктура Обзор VPS Виртуальный дата-центр VMware
      • Операции Продление Изменение владельца Перенос услуг внутри REG. RU Договоры и письма
      • Услуги
        Сервер для бизнеса Дополнительные IP Бэкап сервера Мониторинг серверов
      • Мои услуги

    • SSL
      • Популярное Сравнение SSL-сертификатов О сертификатах SSL-сертификаты GlobalSign SSL-сертификаты Thawte SSL-сертификаты Comodo SSL-сертификаты TrustWave SSL-сертификаты Symantec SSL-сертификаты GeoTrust SSL-сертификаты Wildcard Бесплатный SSL-сертификат
      • Мои услуги

    • Сервисы
      • Продвижение Автоматическое SEO-продвижение Почта для домена Бесплатная почта Gmail, G Suite (Google Apps) для домена Полезные инструменты Определить свой IP-адрес Определить местоположение по IP Проверка DNS-записей домена
      • Мониторинг История хостинга домена История изменения Whois Whois Мониторинг доменов Экстренное оповещение SMS-сервисы, уведомления
      • Безопасность Защита персональных данных Host protection Защита от спама и вирусов Установка SSL-сертификата
      • Мои услуги

    • Партнёрам
      • Программы для партнёров Партнерская программа Описание и преимущества Для профессионалов Партнёрские тарифы Как стать партнёром REG. Reseller REG.API v2
      • Бонусная программа Описание и преимущества Правила
      • Разное Договоры и письма Безбумажное управление услугами Бизнес-секреты Промо материалы

Что такое 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:

  1. Откройте утилиту dig.

  2. Введите данные интересующего вас доменного имени.  

  3. Выберите тип записи SOA. Нажмите Проверить:

Готово, вы увидите данные SOA-записи:

Типы записей DNS - A, MX, NS, PTR, SOA

DNS (Domain Name System) — компьютерная распределенная система для получения информации о домене. Основное применение это получение IP адреса хоста по его доменному имени и информации о маршрутизации почты (MX запись).

Наиболее важные и востребованные в анализе DNS-записи.

SOA

Запись SOA (Start Of Authorisation) — начальная запись зоны, указывает на основной сервер который отвечает за данный домен. Для каждой зоны должна быть только одна и единственная зона SOA.

Так что из себя представляет запись SOA Давайте посмотрим:

Все эксперименты будут проведены на примере домена thetech.сom.ua.

Открываем командную строку cmd.exe и набираем в ней:

nslookup -type=SOA download. openlib.org.ua

в ответ получаем:

download.openlib.org.ua
primary name server = ns1.gigahost.ua
responsible mail addr = hostmaster.gigahost.ua
serial  = 2010102009
refresh = 14400 (4 hours)
retry   = 7200 (2 hours)
expire  = 604800 (7 days)
default TTL = 3600 (1 hour)

где:
primary name server — первичный сервер зоны,т.е. тот сервер который собственно и отвечает за эту зону;
responsible mail addr — email адрес ответственного за зону;
serial — cерийный номер версии; должен увеличиваться при каждом изменении в зоне — по нему вторичный сервер обнаруживает, что надо обновить информацию. Обычно пишется в виде ;
refresh — временной интервал в секундах, через который вторичный сервер будет проверять необходимость обновления информации;
retry — временной интервал в секундах, через который вторичный сервер будет повторять обращения при неудаче;
expire — временной интервал в секундах, через который вторичный сервер будет считать имеющуюся у него информацию устаревшей;
default TTL — время жизни информации на кэширующих серверах.

NS

Запись NS (name server) — указывает на DNS-сервера содержащие данную зону.

В командной строке пишем:

nslookup -type=NS download.openlib.org.ua

в ответ получаем:

download.openlib.org.ua  nameserver = ns2.gigahost.ua
download.openlib.org.ua  nameserver = ns1.gigahost.ua
download.openlib.org.ua  nameserver = ns3.gigahost.ua

Несколько записей означают, что зона содержится не на одном, а на нескольких NS серверах.

A

Запись A (address record) или запись адреса связывает имя хоста с адресом IP.

Пишем:

nslookup -type=A download.openlib.org.ua

Name:download.openlib.org.ua
Address:  77.87.194.47

где:
Address — IP-адрес запрашиваемого домена.

CNAME

Запись CNAME (canonical name record) — каноническая запись имени, псевдоним который используется для перенаправления запроса на другое имя.

Набираем:

nslookup -type=CNAME www.download.openlib.org.ua

и получаем:

download.openlib.org.ua
primary name server = ns1.gigahost.ua
responsible mail addr = hostmaster.gigahost.ua
serial  = 2010102009
refresh = 14400 (4 hours)
retry   = 7200 (2 hours)
expire  = 604800 (7 days)
default TTL = 3600 (1 hour)

как мы видим домен www.download.openlib.org.ua указывает на download.openlib.org.ua

MX

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

Пробуем:

nslookup -type=MX download. openlib.org.ua

download.openlib.org.ua  MX preference = 5, mail exchanger = alt1.aspmx.l.google.com
download.openlib.org.ua  MX preference = 5, mail exchanger = alt2.aspmx.l.google.com
download.openlib.org.ua  MX preference = 10, mail exchanger = aspmx3.googlemail.com
download.openlib.org.ua  MX preference = 10, mail exchanger = aspmx4.googlemail.com
download.openlib.org.ua  MX preference = 10, mail exchanger = aspmx5.googlemail.com
download.openlib.org.ua  MX preference = 30, mail exchanger = aspmx2.googlemail.com
download.openlib.org.ua  MX preference = 1, mail exchanger = aspmx.l.google.com
alt1.aspmx.l.google.com internet address = 74.125.53.27
alt2.aspmx.l.google.com internet address = 74.125.67.27
aspmx3.googlemail.com   internet address = 72.14.213.27
aspmx4.googlemail.com   internet address = 209.85.229.27
aspmx5.googlemail.com   internet address = 74.125.157.27
aspmx2.googlemail.com   internet address = 74.125.43. 27
aspmx.l.google.com      internet address = 74.125.39.27

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

PTR

Запись PTR (pointer) — указатель, служит для выполнения обратного преобразования IP-адресов в канонические имена хостов.

nslookup -type=PTR 77.87.194.47

47.194.87.77.in-addr.arpa       name = hvh29.gigahost.ua

В принципе это весь список нужных записей для администрирования и анализа. Есть еще записи, но они не столь важны для нас.

DNS сервер BIND (теория) / Хабр

Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу

DNS сервера BIND

(Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон

named

, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

Основные понятия Domain Name System

Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:



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

домены первого уровня

(ru, net, org и др). Информация о серверах корневой зоны расположена на данном

сайте корневых серверов

. Настройки корневой зоны всегда доступны

тут

. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.

Зона — это любая часть дерева системы доменных имен, размещаемая как единое целое на некотором DNS-сервере. Зону, для бОльшего понимания, можно назвать «зоной ответственности». Целью выделения части дерева в отдельную зону является передача ответственности (Делегирование) за эту ветвь другому лицу или организации. На иллюстрации, примеры зон выделены синим градиентом (зона name., зона k-max.name. со всем подчиненными ресурсами, www.openoffice.org со всем подчиненными поддоменами и ресурсами). На иллюстрации выделены не все зоны, а лишь некоторые для общего понимания и представления. В каждой зоне имеется, по крайней мере, один авторитетный сервер DNS, который хранит ВСЮ информацию о зоне, за которую он отвечает.

Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:

Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.

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

слэш

, а в DNS —

точка

. А так же

DNS адрес

читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux.

Доменное имя начинается с точки

(

корневого домена

) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о.

доменное имя

полностью отражает

структуру иерархии DNS

. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.nam

e.

, а k-max.nam

e

). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию

FQDN

.

FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:

mail.k-max.name.
 |     |  |  | |
 |     |  |  | +-корневой домен
 |     |  |  +---домен первого уровня
 |     |  +------точка, разделяющая домены/части FQDN
 |     +---------домен второго уровня
 +---------------поддомен/домен третьего уровня, возможно - имя хоста

Различие между

FQDN

и обычным доменным (

неFQDN

) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для

получения FQDN

требуется

обязательно

указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.

Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.

Итак, на схеме выше мы рассмотрели корневой домен, следующим в иерархии идут домены первого/верхнего уровня, они же TLD, они же Top-Level Domain. К данным доменам относятся национальные домены (ru., ua. и др) и общие домены (com., net., и др). Существуют так же специализированные домены, которые не опубликованы в системе DNS, но используются программами (домен .onion используется анонимной сетью Tor для перехвата и последующей маршрутизации обращений к скрытым сервисам этой сети). Еще есть т.н. зарезервированные доменные имена, определенные в RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. К таким именам относятся например example. com, example.org и example.net, а также test, invalid и др. Ниже по иерархии, как видно, идут домены третьего уровня и т.д. Заканчивается доменная иерархия — именами хостов, которые задаются соответствующими ресурсными записями или хостовыми записями.

Ресурсные записи

Ресурсная запись

— это то, собственно ради чего в конечном счете и существует DNS.

Ресурсная запись

— это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе

информацию соответствия

какого-то

имени

и

служебной информации

в DNS, например соответствие имени домена — IP адреса.

Запись ресурса состоит из следующих полей:

  • имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.
  • Time To Live (TTL) — дословно «время жизни» записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.
  • класс (CLASS) — определяет тип сети, (в 99,99% случаях используется IN (что обозначает — Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)
  • тип (TYPE) — тип записи синтаксис и назначение записи
  • данные (DATA) — различная информация, формат и синтаксис которой определяется типом.

При этом, возможно использовать следующие символы:


  • ; - Вводит комментарий
  • # - Также вводит комментарии (только в версии BIND 4.9)
  • @ — Имя текущего домена
  • ( ) — Позволяют данным занимать несколько строк
  • * — Метасимвол (только в поле имя)

Со всем набором ресурсных записей можно ознакомиться в

wikipedia

. Наиболее часто применяемые

ресурсные записи следующими

(далее, мы обязательно рассмотрим их на практике):


  • A — (address record/запись адреса) отображают имя хоста (доменное имя) на адрес IPv4. Для каждого сетевого интерфейса машины должна быть сделана одна A-запись. Например, следующая запись отображает доменное имя k-max.name. в IPv4 адрес хоста 81.177.139.65 (поле NAME k-max.name., поле TTL 86400, поле CLASS IN, поле DATA 81.177.139.65):
    k-max.name.             86400   IN      A       81.177.139.65
  • AAAA (IPv6 address record) аналогична записи A, но для IPv6.
  • CNAME (canonical name record/каноническая запись имени (псевдоним)) — отображает алиас на реальное имя (для перенаправления на другое имя), например, следующая запись задает алиас ftp для хоста www. k-max.name.:
    ftp             86400   IN      CNAME       www.k-max.name.
  • MX (mail exchange) — указывает хосты для доставки почты, адресованной домену. При этом поле NAME указывает домен назначения, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение MX, а поле DATA указывает приоритет и через пробел - доменное имя хоста, ответственного за прием почты. Например, следующая запись показывает, что для домена k-max.name направлять почту сначала на mx.k-max.name, затем на mx2.k-max.name, если с mx.k-max.name возникли какие-то проблемы. При этом, для обоих MX хостов должны быть соответствующие A-записи:
    k-max.name.             17790   IN      MX      10 mx.k-max.name.
    k-max.name.             17790   IN      MX      20 mx2.k-max.name.
  • NS (name server/сервер имён) указывает на DNS-сервер, обслуживающий данный домен. Вернее будет сказать — указывают сервера, на которые делегирован данный домен. Если записи NS относятся к серверам имен для текущей зоны, доменная система имен их практически не использует. Они просто поясняют, как организована зона и какие машины играют ключевую роль в обеспечении сервиса имен. Например, зону name. обслуживают следующие NS:
    name.                   5772    IN      NS      l6.nstld.com.
    name.                   5772    IN      NS      m6.nstld.com.
    name.                   5772    IN      NS      c6.nstld.com.
    name.                   5772    IN      NS      j6.nstld.com.
    ......

    зону k-max.name обслуживают:
    k-max.name.             1577    IN      NS      ns2.jino.ru.
    k-max.name.             1577    IN      NS      ns1.jino.ru.
  • PTR (pointer) — отображает IP-адрес в доменное имя (о данном типе записи поговорим ниже в разделе обратного преобразования имен).
  • SOA (Start of Authority/начальная запись зоны) — описывает основные/начальные настройки зоны, можно сказать, определяет зону ответственности данного сервера. Для каждой зоны должна существовать только одна запись SOA и она должна быть первая. Поле Name содержит имя домена/зоны, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение SOA, а поле DATA состоит из нескольких значений, разделенных пробелами: имя главного DNS (Primary Name Server), адрес администратора зоны, далее в скобках — серийный номер файла зоны (Serial number). При каждом внесении изменений в файл зоны данное значение необходимо увеличивать, это указывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону. Далее — значения таймеров (Refresh — указывает, как часто вторичные серверы должны опрашивать первичный, чтобы узнать, не увеличился ли серийный номер зоны, Retry — время ожидания после неудачной попытки опроса, Expire — максимальное время, в течение которого вторичный сервер может использовать информацию о полученной зоне, Minimum TTL — минимальное время, в течение которого данные остаются в кэше вторичного сервера). Ниже в примере приведено 2 одинаковые записи SOA (хотя вторая и записана в несколько строк), но они одинаковы по значению и формат записи второй более понятен в силу его структурированности:
    k-max.name.             86400   IN      SOA     ns1.jino.ru. hostmaster.jino.ru. 2011032003 28800 7200 604800 86400
    k-max.name.             86400   IN      SOA     ns1.jino.ru. hostmaster.jino.ru. (
                                                      2011032003 ; serial (серийный номер)
                                                      28800 ; refresh (обновление)
                                                      7200 ; retry (повторная попытка)
                                                      604800 ; expire (срок годности)
                                                      86400) ; minimum TTL (минимум)
  • SRV (server selection) — указывают на сервера, обеспечивающие работу тех или иных служб в данном домене (например Jabber и Active Directory).

Давайте рассмотрим, что есть

Делегирование

.

Делегирование

(корректнее сказать

делегирование ответственности

) — это операция

передачи ответственности за часть дерева доменных имен (зону)

другому лицу или организации. За счет делегирования, в DNS обеспечивается распределенность администрирования и хранения зон. Технически, делегирование заключается в выделении какой-либо части дерева в отдельную зону, и размещении этой зоны на DNS-сервере, принадлежащем другому лицу или организации. При этом, в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на авторитативные DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны. Например, на иллюстрации

корневой домен

делегирует полномочия серверам отвечающим за TLD, TLD же в свою очередь, делегируют полномочия управления зонами — серверам второго уровня, иногда на этом цепочка заканчивается, но бывает, что делегирование простирается до 4 и даже 5 уровней.

Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.

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

Серверы DNS

Выше, при рассмотрении типов ресурсных записей я упоминал о

первичном

и

вторичном

сервере. Кроме данных типов, существует еще один тип —

кэширующий

.

Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.

Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).

Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.

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

Клиенты DNS (resolver)

Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS?

Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется

библиотека Resolver

. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают

системные вызовы

gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch. conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то

файл /etc/hosts

или

DNS

) и в каком порядке использовать. В ранних версиях библиотеки Linux —

libc

, использовался

файл /etc/host.conf.

Вот фрагмент файла, который нас интересует:


[email protected]:~# cat /etc/nsswitch.conf
......
hosts:          files dns
networks:       files

Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка

hosts: files dns

) сначала из

файла hosts

, затем силами

DNS

, а так же преобразование имен сетей в IP (строка

networks: files

) с помощью файла /etc/network.Возможны так же параметры

nis

или

nisplu

, определяющие использовать

Network Information System (NIS)

чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.

Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет

какие

серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:


[email protected]:~# cat /etc/resolv.conf
nameserver 192.168.1.1
nameserver 192.168.1.2
domain  examle.com

Директива

nameserver

определяет адрес

сервера доменных имен

, который будет выполнять рекурсивные запросы resolver. В данном файле указано

использовать север имен

сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х

параметров nameserver

. Если

опция nameserver

не задана, то резолвер попытается соединиться с сервером на локальном хосте.

Параметр domain

определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же

опция search

, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.

Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:

Запросы DNS

В DNS имеются следующие типы запросов:

итеративный

(он же

прямой

),

обратный

и

рекурсивный

.

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

Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.

Обратный запрос посылает IP и просит вернуть доменное имя.

Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.

Обычно, провайдер выдает в локальной сети стоит DNS-сервер, обрабатывающий рекурсивные запросы, а так же, скорее всего, он настроен на кэширование запросов, что экономит трафик и снижает нагрузку на сеть. Схему взаимодействия клиента и DNS серверов можно представить следующей картинкой:

Давайте разберем, что тут нарисовано по шагам:

  1. Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запрос резолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
  2. Резолвер посылает запрос указанному серверу имен.
  3. Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запрос серверу, отвечающему за корневую зону.
  4. Сервер корневой зоны не обрабатывает рекурсивные запро

Общие сведения о понятиях DNS

  • Чтение занимает 5 мин

В этой статье

Область применения. Windows Server 2016, Windows Server 2012 R2, Windows Server 2012Applies To: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Служба доменных имен (DNS) — это распределенная база данных, представляющая пространство имен. Domain Name System (DNS) is a distributed database that represents a namespace. Пространство имен содержит все сведения, необходимые любому клиенту для поиска любого имени.The namespace contains all of the information needed for any client to look up any name. Любой DNS-сервер может отвечать на запросы о любом имени в своем пространстве имен.Any DNS server can answer queries about any name within its namespace. DNS-сервер отвечает на запросы одним из следующих способов:A DNS server answers queries in one of the following ways:

  • Если ответ находится в кэше, он отвечает на запрос из кэша.If the answer is in its cache, it answers the query from the cache.
  • Если ответ находится в зоне, размещенной на DNS-сервере, он отвечает на запрос из своей зоны.If the answer is in a zone hosted by the DNS server, it answers the query from its zone. Зона — это часть дерева DNS, хранящаяся на DNS-сервере.A zone is a portion of the DNS tree stored on a DNS server. Когда DNS-сервер размещает зону, он является полномочным для имен в этой зоне (то есть DNS-сервер может отвечать на запросы для любого имени в зоне). When a DNS server hosts a zone, it is authoritative for the names in that zone (that is, the DNS server can answer queries for any name in the zone). Например, сервер, на котором размещена зона contoso.com, может отвечать на запросы по любому имени в contoso.com.For example, a server hosting the zone contoso.com can answer queries for any name in contoso.com.
  • Если сервер не может ответить на запрос из своего кэша или зон, он запрашивает у других серверов ответ.If the server cannot answer the query from its cache or zones, it queries other servers for the answer.

Важно понимать основные возможности DNS, такие как делегирование, рекурсивное разрешение имен и интегрированные в Active Directory зоны DNS, так как они непосредственно влияют на структуру Active Directory логической структуры.It is important to understand the core features of DNS, such as delegation, recursive name resolution, and Active Directory-integrated DNS zones, because they have a direct impact on your Active Directory logical structure design.

Дополнительные сведения о DNS и службах домен Active Directory (AD DS) см. в разделе DNS и AD DS.For more information about DNS and Active Directory Domain Services (AD DS), see DNS and AD DS.

ДелегированиеDelegation

Чтобы DNS-сервер ответил на запросы о любом имени, он должен иметь прямой или косвенный путь к каждой зоне в пространстве имен.For a DNS server to answer queries about any name, it must have a direct or indirect path to every zone in the namespace. Эти пути создаются с помощью делегирования.These paths are created by means of delegation. Делегирование — это запись в родительской зоне, которая содержит сервер доменных имен, полномочный для зоны на следующем уровне иерархии.A delegation is a record in a parent zone that lists a name server that is authoritative for the zone in the next level of the hierarchy. Делегирование позволяет серверам в одной зоне ссылаться на клиентов на серверы в других зонах.Delegations make it possible for servers in one zone to refer clients to servers in other zones. На следующем рисунке показан один пример делегирования.The following illustration shows one example of delegation.

Корневой DNS-сервер размещает корневую зону, представленную точкой (.The DNS root server hosts the root zone represented as a dot ( . ).). Корневая зона содержит делегирование для зоны на следующем уровне иерархии — в зоне com.The root zone contains a delegation to a zone in the next level of the hierarchy, the com zone. Делегирование в корневой зоне сообщает корневому серверу DNS, что для поиска зоны com необходимо обратиться к серверу com.The delegation in the root zone tells the DNS root server that, to find the com zone, it must contact the Com server. Аналогично, делегирование в зоне com сообщает серверу com, что для поиска зоны contoso.com необходимо обратиться к серверу Contoso.Likewise, the delegation in the com zone tells the Com server that, to find the contoso.com zone, it must contact the Contoso server.

Примечание

Делегирование использует два типа записей. A delegation uses two types of records. В записи ресурса сервера имен (NS) содержится имя полномочного сервера.The name server (NS) resource record provides the name of an authoritative server. Записи ресурсов узла (A) и узла (AAAA) предоставляют адреса IP версии 4 (IPv4) и IP версии 6 (IPv6) полномочного сервера.Host (A) and host (AAAA) resource records provide IP version 4 (IPv4) and IP version 6 (IPv6) addresses of an authoritative server.

Эта система зон и делегирования создает иерархическое дерево, представляющее пространство имен DNS.This system of zones and delegations creates a hierarchical tree that represents the DNS namespace. Каждая зона представляет слой в иерархии, и каждое делегирование представляет собой ветвь дерева.Each zone represents a layer in the hierarchy, and each delegation represents a branch of the tree.

Используя иерархию зон и делегирования, корневой сервер DNS может найти любое имя в пространстве имен DNS.By using the hierarchy of zones and delegations, a DNS root server can find any name in the DNS namespace. Корневая зона включает делегирования, которые напрямую или косвенно переводят на все другие зоны в иерархии.The root zone includes delegations that lead directly or indirectly to all other zones in the hierarchy. Любой сервер, который может запрашивать корневой DNS-сервер, может использовать сведения в делегировании для поиска любого имени в пространстве имен.Any server that can query the DNS root server can use the information in the delegations to find any name in the namespace.

Рекурсивное разрешение именRecursive name resolution

Рекурсивное разрешение имен — это процесс, с помощью которого DNS-сервер использует иерархию зон и делегирований для реагирования на запросы, для которых он не является полномочным.Recursive name resolution is the process by which a DNS server uses the hierarchy of zones and delegations to respond to queries for which it is not authoritative.

В некоторых конфигурациях DNS-серверы включают корневые ссылки (то есть список имен и IP-адресов), которые позволяют им запрашивать корневые серверы DNS. In some configurations, DNS servers include root hints (that is, a list of names and IP addresses) that enable them to query the DNS root servers. В других конфигурациях серверы пересылают все запросы, которые они не могут ответить на другой сервер.In other configurations, servers forward all queries that they cannot answer to another server. Пересылка и корневые указания являются методами, которые DNS-серверы могут использовать для разрешения запросов, для которых они не являются полномочными.Forwarding and root hints are both methods that DNS servers can use to resolve queries for which they are not authoritative.

Разрешение имен с помощью корневых ссылокResolving names by using root hints

Корневые ссылки позволяют любому DNS-серверу размещать корневые серверы DNS.Root hints enable any DNS server to locate the DNS root servers. После того как DNS-сервер обнаружит корневой сервер DNS, он может разрешить любой запрос для этого пространства имен.After a DNS server locates the DNS root server, it can resolve any query for that namespace. На следующем рисунке показано, как DNS разрешает имя с помощью корневых ссылок.The following illustration describes how DNS resolves a name by using root hints.

В этом примере происходят следующие события:In this example, the following events occur:

  1. Клиент отправляет рекурсивный запрос на DNS-сервер для запроса IP-адреса, соответствующего имени ftp.contoso.com.A client sends a recursive query to a DNS server to request the IP address that corresponds to the name ftp.contoso.com. Рекурсивный запрос указывает, что клиент хочет получить окончательный ответ на запрос.A recursive query indicates that the client wants a definitive answer to its query. Ответ на рекурсивный запрос должен быть допустимым адресом или сообщением, указывающим, что адрес не найден.The response to the recursive query must be a valid address or a message indicating that the address cannot be found.
  2. Так как DNS-сервер не является полномочным для имени и не имеет ответа в своем кэше, DNS-сервер использует корневые ссылки для поиска IP-адреса корневого сервера DNS. Because the DNS server is not authoritative for the name and does not have the answer in its cache, the DNS server uses root hints to find the IP address of the DNS root server.
  3. DNS-сервер использует итеративный запрос, чтобы запросить у корневого сервера DNS разрешение имени ftp.contoso.com.The DNS server uses an iterative query to ask the DNS root server to resolve the name ftp.contoso.com. Итеративный запрос указывает, что сервер будет принимать ссылку на другой сервер вместо определенного ответа на запрос.An iterative query indicates that the server will accept a referral to another server in place of a definitive answer to the query. Так как имя ftp.contoso.com заканчивается на метку com, корневой сервер DNS возвращает ссылку на COM-сервер, на котором размещена зона com.Because the name ftp.contoso.com ends with the label com, the DNS root server returns a referral to the Com server that hosts the com zone.
  4. DNS-сервер использует итеративный запрос, чтобы запросить у COM-сервера разрешение имени ftp. contoso.com.The DNS server uses an iterative query to ask the Com server to resolve the name ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем contoso.com, com-сервер возвращает ссылку на сервер Contoso, на котором размещена зона contoso.com.Because the name ftp.contoso.com ends with the name contoso.com, the Com server returns a referral to the Contoso server that hosts the contoso.com zone.
  5. DNS-сервер использует итеративный запрос, чтобы попросить сервера Contoso разрешить имя ftp.contoso.com.The DNS server uses an iterative query to ask the Contoso server to resolve the name ftp.contoso.com. Сервер Contoso находит ответ в данных зоны, а затем возвращает ответ на сервер.The Contoso server finds the answer in its zone data and then returns the answer to the server.
  6. Затем сервер возвращает результат клиенту.The server then returns the result to the client.

Разрешение имен с помощью пересылкиResolving names by using forwarding

Пересылка позволяет маршрутизировать разрешение имен через определенные серверы вместо использования корневых ссылок. Forwarding enables you to route name resolution through specific servers instead of using root hints. На следующем рисунке показано, как DNS разрешает имя с помощью пересылки.The following illustration describes how DNS resolves a name by using forwarding.

В этом примере происходят следующие события:In this example, the following events occur:

  1. Клиент запрашивает DNS-сервер для имени ftp.contoso.com.A client queries a DNS server for the name ftp.contoso.com.
  2. DNS-сервер перенаправляет запрос на другой DNS-сервер, который называется сервером пересылки.The DNS server forwards the query to another DNS server, known as a forwarder.
  3. Поскольку сервер пересылки не является полномочным для имени и не имеет ответа в своем кэше, он использует корневые ссылки для поиска IP-адреса корневого сервера DNS.Because the forwarder is not authoritative for the name and does not have the answer in its cache, it uses root hints to find the IP address of the DNS root server.
  4. Сервер пересылки использует итеративный запрос, чтобы запросить у корневого сервера DNS разрешение имени ftp.contoso.com.The forwarder uses an iterative query to ask the DNS root server to resolve the name ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем com, корневой сервер DNS возвращает ссылку на COM-сервер, на котором размещена зона com.Because the name ftp.contoso.com ends with the name com, the DNS root server returns a referral to the Com server that hosts the com zone.
  5. Сервер пересылки использует итеративный запрос, попросив серверу com разрешить имя ftp.contoso.com.The forwarder uses an iterative query to ask the Com server to resolve the name ftp.contoso.com. Так как имя ftp.contoso.com заканчивается именем contoso.com, com-сервер возвращает ссылку на сервер Contoso, на котором размещена зона contoso.com.Because the name ftp.contoso.com ends with the name contoso.com, the Com server returns a referral to the Contoso server that hosts the contoso. com zone.
  6. Сервер пересылки использует итеративный запрос, чтобы попросить сервера Contoso разрешить имя ftp.contoso.com.The forwarder uses an iterative query to ask the Contoso server to resolve the name ftp.contoso.com. Сервер Contoso находит ответ в файлах зоны, а затем возвращает ответ на сервер.The Contoso server finds the answer in its zone files, and then returns the answer to the server.
  7. Затем сервер пересылки возвращает результат исходному DNS-серверу.The forwarder then returns the result to the original DNS server.
  8. Затем исходный DNS-сервер возвращает результат клиенту.The original DNS server then returns the result to the client.

Проверка создания DNS-записей SRV - Windows Server

  • Чтение занимает 2 мин

В этой статье

В этой статье описано, как проверить записи ресурсов локатора службы (SRV) для контроллера домена после установки службы каталогов Active Directory.

Исходная версия продукта:   Windows Server 2012 R2
Исходный номер статьи базы знаний:   816587

Аннотация

Запись SRV — это запись ресурса системы доменных имен (DNS), которая используется для идентификации компьютеров, на которых размещаются определенные службы. Записи ресурсов SRV используются для обнаружения контроллеров доменов Active Directory. Чтобы проверить записи ресурсов локатора SRV для контроллера домена, используйте один из указанных ниже способов.

Способ 1: использование диспетчера DNS

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

Active Directory создает записи SRV в следующих папках, где domain_name — это имя вашего домена:

  • Forward Lookup Zones/Domain_Name/_msdcs/dc/_sites/Default-First-Site-Name/_tcp
  • Forward Lookup Zones/Domain_Name/_msdcs/dc/_tcp

В этих расположениях должна появиться запись SRV для следующих служб:

Способ 2: Просмотр Netlogon. DNS

Если вы используете DNS-серверы сторонних производителей для поддержки Active Directory, вы можете проверить записи ресурсов локатора SRV, просмотрев службу Netlogon. DNS. Служба Netlogon. DNS находится в %systemroot%\System32\Config папке. Для просмотра этого файла можно использовать текстовый редактор, например "Блокнот".

Первая запись в файле представляет собой запись SRV для протокола LDAP контроллера домена. Эта запись должна выглядеть следующим образом:

_ldap _ldap._tcp. Domain_Name

Способ 3: Использование nslookup

Nslookup — это средство командной строки, которое отображает сведения, которые можно использовать для диагностики инфраструктуры службы доменных имен (DNS).

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

  1. На DNS-сервере нажмите кнопку Пуски выберите команду выполнить.
  2. В поле Открыть введите cmd .
  3. Введите команду nslookup и нажмите клавишу ВВОД.
  4. Введите команду set type=all и нажмите клавишу ВВОД.
  5. Введите _ldap._tcp.dc._msdcs. Domain_Name , где domain_name — имя вашего домена, а затем нажмите клавишу ВВОД.

Nslookup возвращает одну или несколько записей о расположении службы SRV, которые отображаются в следующем формате, где server_name — это имя узла контроллера домена, а domain_name — домен, в который входит контроллер домена, а Server_IP_Address — IP-адрес контроллера домена (IP-адрес).

Server: localhost
Address: 127.0.0.1
_ldap._tcp.dc._msdcs. Domain_Name
SRV service location:
priority= 0
weight= 100
port= 389 srv hostname= Server_Name . Domain_Name Server_Name . Domain_Name internet address = Server_IP_Address

Для получения дополнительных сведений о записях SRV, зарегистрированных службой Netlogon, просмотрите записи SRV, зарегистрированные службой Netlogon.

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

Запись SOA, или «Начало полномочий», определяет достоверную информацию о зоне DNS, включая первичный сервер имен, электронную почту администратора домена, серийный номер домена и несколько таймеров, относящихся к обновлению зоны. В зоне DNS домена есть только одна запись SOA.

Что касается записи SOA, если платформа DNS, которую вы используете (Windows, BIND и т. Д.), Соответствует RFC 1035, структура записи SOA будет такой же.Ниже приведен пример, взятый из зоны под названием «corp.com», размещенной на сервере Windows 2003 R2 под управлением Windows DNS.

Вы можете просмотреть настройки записи SOA, открыв свойства зоны домена и щелкнув вкладку «Начало полномочий (SOA)», или открыв сам файл зоны с помощью текстового редактора (при условии, что зона является стандартной. основной, не интегрированный в Active Directory.

Запись ресурса SOA содержит следующую информацию:

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

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

Первичный сервер

Хост, на котором хранится файл первичной зоны.

Ответственное лицо

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

Интервал обновления

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

Интервал повтора

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

Истекает после

Время в секундах, в течение которого дополнительный сервер будет продолжать попытки успешно завершить передачу зоны с основного DNS-сервера. Если это время истекает до успешной передачи зоны, у вторичного сервера истекает срок действия файла зоны. Вторичный сервер DN перестанет отвечать на запросы для зоны с истекшим сроком действия, так как данные зоны теперь считаются слишком старыми, чтобы быть надежными. Значение по умолчанию - 86 400.

Минимум (по умолчанию) TTL

Минимальное значение времени жизни, применяемое ко всем записям ресурсов в файле зоны. Это значение предоставляется в ответах на запросы, чтобы сообщить другим серверам, как долго они должны хранить данные в кеше. Значение по умолчанию - 3600. Когда создаются новые записи, TTL для новой записи будет использовать это значение. Значение записей ресурсов можно изменить индивидуально.

Вы нашли страницу информативной и полезной? Поделитесь им на одном из ваших любимых социальных сайтов.

Рекомендуемые книги и учебные ресурсы

записей DNS | Объяснение типов записей ресурсов

1 А Адрес указывает IPv4-адрес хоста.
2 NS Сервер имен уточняет полномочия зоны.
3 MD Место назначения почты было заменено записью MX (устарело).
4 MF Mail Forwarder был заменен записью MX (устаревшей).
5 CNAME Каноническое имя определяет псевдоним.
6 SOA Start of Authority раскрывает подробности о зоне.
7 МБ Доменное имя почтового ящика является экспериментальным.
8 MG Член почтовой группы является экспериментальным.
9 Г-Н Имя домена для переименования почты является экспериментальным.
10 ЗНАЧЕНИЕ NULL Нулевой ресурс является экспериментальным.
11 WKS Для пересылки почты использовался сервис Well Known (ныне устаревший).
12 PTR Указатель предназначен для обратного просмотра.
13 HINFO Информация о хосте предоставляет сведения об аппаратном и программном обеспечении хоста.
14 МИНФО Информация о почтовом ящике является экспериментальной.
15 MX Mail Exchange назначает почтовым серверам домен.
16 текст Текст позволяет вводить дополнительные тексты.
17 RP Ответственное лицо предоставляет информацию об ответственном лице.
18 AFSDB База данных AFS специально предназначена для клиентов AFS.
19 X25 Адрес X.25 PSDN предоставляет подробную информацию об инкапсуляции через X.25 (устарело).
20 ISDN Эта запись присваивает DNS-имени номер ISDN (устарело).
21 год RT Route Through Record обеспечивает сквозную привязку без адреса WAN (устарело).
22 NSAP Эта запись позволяет назначать доменные имена точкам доступа к сетевым службам (устарело).
23 NSAP-PTR Указатель NSAP был заменен на PTR (устаревший).
24 SIG Подпись заменена на RRSIG (устарела).
25 КЛЮЧ Ключ был заменен на IPSECKEY (устаревший).
26 PX Указатель на X.400 указывает правила отображения MIXER (устарело).
27 GPOS Географическое положение было заменено на LOC (устаревшее).
28 AAAA AAAA предоставляет IPv6-адрес хоста.
29 LOC Местоположение содержит информацию о местоположении.
30 NXT Далее был заменен на NSEC (устаревший).
31 год EID Идентификатор конечной точки предназначен для архитектуры маршрутизации Nimrod (устарело).
32 НИМЛОК Nimrod Locator предназначен для архитектуры маршрутизации Nimrod (устарело).
33 SRV Service Locator предоставляет информацию о других услугах.
34 ATMA ATM Address предоставляет информацию, когда есть асинхронные режимы передачи (устаревшие).
35 год НАПТР Указатель полномочий именования - это расширение записи A, которое разрешает шаблон поиска (регулярные выражения).
36 KX Key Exchanger позволяет управлять ключами для криптографии.
37 CERT Cert сохраняет сертификаты.
38 A6 A6 был заменен на AAAA.
39 DNAME Имя делегирования определяет псевдонимы для полных доменов.
40 Раковина Кухонная мойка позволяет хранить различные данные (устарело).
41 год OPT Опция - это псевдозапись при наличии механизма расширения DNS (EDNS).
42 APL Список префиксов адресов перечисляет области адресов в формате CIDR.
43 DS Орган, подписывающий делегирование, определяет зоны, подписанные DNSSEC.
44 SSHFP Отпечаток открытого ключа SSH раскрывает отпечаток ключей SSH.
45 IPSECKEY Ключ IPsec содержит ключ IPsec.
46 RRSIG Подпись RR содержит цифровую подпись для DNSSEC.
47 NSEC Далее Безопасные потоки подписанных зон в DNSSEC.
48 DNSKEY DNS Key содержит открытый ключ для DNSSEC.
49 DHCID Идентификатор DHCP связывает доменные имена с DHCP-клиентами.
50 NSEC3 Next Secure 3 - альтернатива NSEC.
51 NSEC3PARAM Эта запись содержит параметр для NSEC3.
52 TLSA Эта запись выдает ассоциацию сертификатов TLSA с доменным именем, относящимся к DANE.
53 СМИМЕА Эта запись выдает ассоциацию сертификата S / MIME с доменным именем.
54 н / д Не назначен
55 Бедра Протокол идентификации хоста отделяет маркеры конечных точек и функции позиционирования от IP-адресов.
56 НИНФО NINFO предоставляет информацию о статусе зоны (та же структура, что и TXT; устарело).
57 RKEY RKEY сохраняет ключи (та же структура, что и KEY и DNSKEY; устарело).
58 ТАЛИНК Якорная ссылка доверия связывает два доменных имени (устарело).
59 CDS Дочерний DS - это дочерняя копия записи DS.
60 CDNSKEY Дочерний DNSKEY - это дочерняя копия записи DNSKEY.
61 OPENPGPKEY OpenPGP Key раскрывает открытые ключи.
62 CSYNC Синхронизация между дочерними и родительскими объектами позволяет согласовывать родительскую и дочернюю зоны (устарело).
63 ЗОНЕМД Дайджест сообщений для зоны DNS является экспериментальным (устаревшим).
64–98 н / д Не назначен.
99 SPF Платформа политики отправителя была заменена записью TXT (устарела).
100 УИНФО Зарезервированный.
101 UID Зарезервированный.
102 GID Зарезервированный.
103 UNSPEC Зарезервированный.
104 NID NodeID экспериментальный.
105 L32 32-битный локатор является экспериментальным.
106 L64 64-битный локатор является экспериментальным.
107 LP Указатель локатора является экспериментальным.
108 EUI48 48-битный расширенный уникальный идентификатор шифрует адреса.
109 EUI64 64-битный расширенный уникальный идентификатор шифрует адреса.
110–248 н / д Не назначен.
249 TKEY Ключ транзакции позволяет обмениваться секретными ключами.

SOA-Records (Начало полномочий)

Зона содержит ровно одну SOA-запись, которая содержит следующие свойства для зоны:

  • Имя основного DNS-сервера

    Имя хоста первичного DNS-сервера для зоны.

    Зона должна содержать соответствующую NS-запись.

    ПРИМЕЧАНИЕ. Для правильной работы динамических обновлений от клиентов Windows и Active Directory важно, чтобы он содержал правильное имя хоста для первичного DNS-сервера для зоны, а также чтобы для этого имени существовала A-запись, указывающая на правильный Айпи адрес.

  • Электронный адрес ответственного лица

    Адрес электронной почты лица, ответственного за зону.

    Стандартным для этого является псевдоним "hostmaster", например, "hostmaster @ example".com ».

  • Серийный номер (см. Зональные передачи)

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

    Если серийный номер больше, чем у вторичного сервера, будет инициирована передача зоны.

    Это число автоматически увеличивается Simple DNS Plus при внесении изменений в зону или ее записи (происходит при сохранении зоны).

    Если у вас нет особой причины для изменения этого номера, лучше всего позволить Simple DNS Plus управлять им.

    Никогда не уменьшайте серийный номер.

  • Интервал обновления (см. Передачи зон)

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

  • Интервал повтора (см. Передачи зон)

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

  • Срок действия (см. Передачи зон)

    Как долго зона будет действительна после обновления.

    Вторичные серверы отбрасывают зону, если в течение этого интервала обновление не может быть выполнено.

  • Минимум (по умолчанию) TTL

    Используется другими DNS-серверами для кэширования отрицательных ответов (например, запись не существует и т. Д.).

  • Сетевая рабочая группа П. Мокапетрис Запрос комментариев: 1035 ISI Ноябрь 1987 г. Устаревшие: RFC 882, 883, 973 ДОМЕННЫЕ ИМЕНА - РЕАЛИЗАЦИЯ И СПЕЦИФИКАЦИЯ 1.СТАТУС ДАННОЙ ЗАПИСИ Этот RFC описывает детали системы и протокола домена, а также предполагает, что читатель знаком с концепциями, обсуждаемыми в сопутствующий RFC, «Доменные имена - концепции и возможности» [RFC-1034]. Система доменов представляет собой смесь функций и типов данных, которые официальный протокол и функции и типы данных, которые все еще экспериментальный. Поскольку доменная система намеренно расширяема, новые типы данных и экспериментальное поведение всегда следует ожидать по частям системы за пределами официального протокола.Официальные части протокола включать стандартные запросы, ответы и данные RR интернет-класса форматы (например, адреса хостов). Начиная с предыдущего набора RFC, несколько определения изменились, поэтому некоторые предыдущие определения устарели. Экспериментальные или устаревшие функции четко отмечены в этих RFC, и такую ​​информацию следует использовать с осторожностью. Читателя особенно предупреждают, чтобы он не зависел от ценностей, которые появляются в примерах как актуальные или полные, поскольку их цель в первую очередь педагогический.Распространение памятки не ограничено. Содержание 1. СТАТУС ДАННОЙ ЗАПИСИ 1 2. ВВЕДЕНИЕ 3 2.1. Обзор 3 2.2. Общие конфигурации 4 2.3. Условные обозначения 7 2.3.1. Предпочтительный синтаксис имени 7 2.3.2. Порядок передачи данных 8 2.3.3. Регистр 9 2.3.4. Ограничения по размеру 10 3. ОПРЕДЕЛЕНИЕ ПРОСТРАНСТВА ИМЕНИ ДОМЕНА И ОПРЕДЕЛЕНИЯ RR 10 3.1. Определения пространств имен 10 3.2. Определения RR 11 3.2.1. Формат 11 3.2.2. Значения ТИП 12 3.2.3. Значения QTYPE 12 3.2.4. Значения КЛАССА 13 Мокапетрис [Страница 1] Реализация и спецификация домена RFC 1035, ноябрь 1987 г. 3.2.5. Значения QCLASS 13 3.3. Стандартные РУ 13 3.3.1. CNAME RDATA формат 14 3.3.2. Формат HINFO RDATA 14 3.3.3. Формат MB RDATA (ЭКСПЕРИМЕНТАЛЬНЫЙ) 14 3.3.4. Формат MD RDATA (Устарело) 15 3.3.5. Формат MF RDATA (Устаревший) 15 3.3.6. Формат MG RDATA (ЭКСПЕРИМЕНТАЛЬНЫЙ) 16 3.3.7. Формат MINFO RDATA (ЭКСПЕРИМЕНТАЛЬНЫЙ) 16 3.3.8. Формат MR RDATA (ЭКСПЕРИМЕНТАЛЬНЫЙ) 17 3.3.9. Формат MX RDATA 17 3.3.10. Формат NULL RDATA (ЭКСПЕРИМЕНТАЛЬНЫЙ) 17 3.3.11. NS RDATA формат 18 3.3.12. Формат PTR RDATA 18 3.3.13. Формат SOA RDATA 19 3.3.14. TXT RDATA формат 20 3.4.ARPA для интернета RRs 20 3.4.1. Формат RDATA 20 3.4.2. WKS RDATA формат 21 3.5. IN-ADDR.ARPA домен 22 3.6. Определение новых типов, классов и специальных пространств имен 24 4. СООБЩЕНИЯ 25 4.1. Формат 25 4.1.1. Формат раздела заголовка 26 4.1.2. Формат раздела вопросов 28 4.1.3. Формат записи ресурса 29 4.1.4. Сжатие сообщений 30 4.2. Транспорт 32 4.2.1. Использование UDP 32 4.2.2. Использование TCP 32 5. МАСТЕР-ФАЙЛЫ 33 5.1. Формат 33 5.2. Использование мастер-файлов для определения зон 35 5.3. Пример мастер-файла 36 6. РЕАЛИЗАЦИЯ СЕРВЕРА ИМЕНИ 37 6.1. Архитектура 37 6.1.1. Контроль 37 6.1.2. База данных 37 6.1.3. Время 39 6.2. Стандартная обработка запросов 39 6.3. Обработка обновления и перезагрузки зоны

    DNS: что это такое и что он делает

    1. Образование
    2. Основы Интернета
    3. DNS: что это такое и что он делает

    Блэр Рэмплинг, Дэвид Далан

    По сути , DNS - это просто база данных, которая связывает значимые имена (известные как имен хостов ), например http: // www.microsoft.com на определенный IP-адрес, например 192.168.124.1. Однако простая привязка адресов к именам - это только начало, потому что DNS имеет гораздо больше функций, помимо сопоставления имени хоста и адреса.

    Ключевые особенности сопоставления имени хоста и IP-адреса следующие:

    • Преобразования адресов в имена и наоборот (известные как записи) хранятся в базе данных.
    • База данных DNS является распределенной.
    • База данных DNS также хранит дополнительные записи.

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

    В дополнение к базовым записям сопоставления IP-адреса и имени хоста, хранящимся в базе данных DNS, DNS также поддерживает записи для других целей. DNS содержит ряд типов записей, которые упрощают работу других приложений. Запись Mail Exchanger (MX), например, предоставляет почтовым серверам информацию, необходимую для пересылки сообщений электронной почты на сервер электронной почты получателя. Другой тип записи, запись службы (SVC), используется Microsoft Active Directory для поиска сетевых служб.

    Видеть разницу в DNS

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

    Многие распространенные приложения используют службы DNS, в том числе

    • Другие приложения, например обмен мгновенными сообщениями

    Всемирная паутина зависит от DNS для удобной навигации.Вы можете попасть на веб-сайт, введя IP-адрес сайта в своем веб-браузере, но для большинства людей запомнить множество произвольных чисел непросто. Намного легче запомнить DNS-имя веб-сайта, которое отражает его содержание, например http://www.yahoo.com или http://www.microsoft.com. Будет справедливо сказать, что без DNS Интернет не стал бы таким явлением, как сейчас.

    Обслуживание подключения к электронной почте

    Электронная почта - одно из наиболее популярных приложений, использующих DNS.Хотя Интернет просто использует DNS для связывания имен с IP-адресами веб-сайтов, для серверов электронной почты также требуются некоторые специализированные записи сверх того, что требуется для базового имени хоста для IP-адресов. Например, когда сообщение электронной почты отправляется из вашего почтового клиента (такого как Microsoft Outlook или Netscape Messenger), его можно отправить либо непосредственно в целевой домен (Microsoft.com, если заметка была отправлена ​​пользователю user @ microsoft). .com) или на другой почтовый сервер, который предоставляет услугу ретрансляции. Если ваше приложение электронной почты указывает сервер исходящей почты (SMTP), который не является конечным сервером назначения для сообщения, вы используете процесс ретрансляции.

    Адрес электронной почты состоит из двух частей: получателя и хоста. В адресе [email protected] postmaster - это получатель, пользователь, который получит сообщение. Однако это не имеет отношения к процессу SMTP, поскольку агент передачи почты (MTA) отвечает за то, чтобы сообщение попало в почтовый ящик получателя.

    Гораздо больший интерес представляет хост, domain.tld, . В этом случае domain.tld относится не к хосту в традиционном смысле записи A, а к почтовому серверу, известному как почтовый обменник (MX). Этот сервер отвечает за прием всей почты для domain.tld, обозначенной специальной записью - MX-записью - в DNS.

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

    Настройки официального сервера - документация по авторитетному серверу PowerDNS

    Здесь перечислены все настройки полномочного сервера PowerDNS, за исключением те, которые происходят из бэкэндов, которые задокументированы в соответствующих главы.Эти настройки могут быть установлены внутри pdns.conf или на командная строка при вызове двоичного файла pdns .

    Вы можете использовать синтаксис + = для инкрементной установки некоторых переменных, но это требует, чтобы у вас был хотя бы один неинкрементный параметр для переменная в качестве базовой настройки. Это в основном полезно для директива include-dir.

    Для логических настроек, указание имени настройки без значения значит да .

    8-битный DNS

    Разрешить 8-битные DNS-запросы.

    разрешить-axfr-ips

    • IP-диапазоны, разделенные запятыми
    • По умолчанию: 127.0.0.0/8,::1

    Если установлено, только эти IP-адреса или маски сети смогут выполнять AXFR без TSIG.

    Предупреждение

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

    allow-dnsupdate-from

    • IP-диапазоны, разделенные запятыми
    • По умолчанию: 127.0.0.0 / 8, :: 1

    Разрешить обновления DNS из этих диапазонов IP-адресов. Установите пустую строку для соблюдения ALLOW-DNSUPDATE-FROM в ALLOW-DNSUPDATE-FROM.

    разрешить-уведомить-от

    • IP-диапазоны, разделенные запятыми
    • По умолчанию: 0.0.0.0/0,::/0

    Разрешить AXFR NOTIFY из этих диапазонов IP-адресов. Установка пустой строки отбросит все входящие уведомления.

    разрешить рекурсию

    • IP-диапазоны, разделенные запятыми
    • По умолчанию: 0.0,0.0 / 0

    Указав allow-recursion , рекурсия может быть ограничена сетевые маски указаны. По умолчанию рекурсия разрешена отовсюду. Пример: allow-recursion = 198.51.100.0 / 24, 10.0.0.0/8, 192.0.2.4 .

    разрешить беззнаковое уведомление

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

    разрешить неподписанный супермастер

    Отключение этого параметра требует, чтобы все уведомления супермастера были подписаны действительная подпись TSIG.Он примет любой существующий ключ на ведомом устройстве.

    также уведомить

    • IP-адресов, разделенных запятыми

    При уведомлении домена также уведомляйте эти серверы имен. Пример: также-уведомление = 192.0.2.1, 203.0.113.167 . IP-адреса, перечисленные в также-уведомить всегда получать уведомление. Даже если они не совпадают список в only-notify.

    любой-to-tcp

    Изменено в версии 4.0.1: раньше было «нет».

    Отвечайте на вопросы ANY по UDP с помощью усеченного пакета, который ссылается на удаленный сервер к TCP. Полезно для смягчения отражения атак.

    api-ключ

    Статический предварительный общий ключ аутентификации для доступа к REST API.

    api-readonly

    Изменено в версии 4.2.0: Этот параметр был удален в версии 4.2.0.

    Запретить изменение данных через REST API, если установлено.

    axfr-fetch-timeout

    Максимальное время в секундах, в течение которого входящий AXFR запускается или бездействует после запуска.

    axfr-нижний серийный

    Также AXFR зона от мастера с более низким серийником.

    кэш-TTL

    Секунды для хранения пакетов в кэше пакетов. Значение 0 отключит кеш.

    углеродное наименование

    • Строка
    • По умолчанию: имя хоста сервера

    При отправке углеродных обновлений, если установлено, это переопределит наше имя хоста. Быть будьте осторожны, чтобы не включать в этот параметр какие-либо точки, если вы не знаете, что ты делаешь.См. «Отправка метрик в графит / метроном через углерод

    ».

    карбон-сервер

    Отправляет все доступные метрики на этот сервер через углеродный протокол, который используется графитом и метрономом. Это должен быть адрес (нет имена хостов). Кроме того, вы можете указать более одного сервера, используя список, разделенный запятыми, например: углерод-сервер = 10.10.10.10,10.10.10.20. Вы можете указать альтернативный порт, добавив: порт, например: 127.0.0.1:2004. См. Отправка метрик в графит / метроном вместо углерода.

    chroot

    Если установлено, chroot в этот каталог для большей безопасности. См. Безопасность PowerDNS.

    Убедитесь, что / dev / log доступен из chroot. логирование в противном случае будет тихо терпеть неудачу (при logrotate).

    При установке chroot , все остальные пути в конфиге (кроме config-dir и module-dir) установленные в конфигурации относятся к новому корню.

    При работе в системе, где systemd управляет службами, chroot выполняет не работает из коробки, так как PowerDNS не может использовать NOTIFY_SOCKET .Либо не используйте chroot в этих системах, либо установите «Тип» этого service на "simple" вместо "notify" (см. systemd документацию по изменению юнит-файлов)

    каталог конфигурации

    Расположение каталога конфигурации ( pdns.conf ). Обычно / etc / powerdns , но это зависит от SYSCONFDIR во время время компиляции.

    согласованные серверные ВМ

    Когда это установлено, PowerDNS предполагает, что любой отдельный домен находится только в одном бэкэнде.Это позволяет PowerDNS отправлять ЛЮБЫЕ запросы к своим серверам вместо того, чтобы иногда запрашивать точный необходимый тип. Это снижает нагрузку на серверные части, получая сразу все типы для данного имени, добавляя их все в кеш. Это значительно улучшает производительность для чувствительных к задержкам серверных ВМ, таких как серверы SQL, для которых требуется много времени. Это поведение будет включено по умолчанию в будущих версиях.

    пульт управления

    Переключатель отладки - не использовать.

    демон

    Работает как демон.

    по умолчанию-api-rectify

    Значение API-RECTIFY, если оно не задано для зоны.

    Примечание

    До 4.2.0 по умолчанию всегда было нет.

    алгоритм default-ksk

    Изменено в версии 4.1.0: Переименовано с default-ksk-algorithmms . Больше не поддерживает несколько имен алгоритмов.

    Алгоритм, который следует использовать для KSK при запуске pdnsutil secure-zone или с помощью конечной точки Zone API для включения DNSSEC.Должен быть одним из:

    • rsasha1
    • rsasha256
    • rsasha512
    • ecdsa256 (ECDSA P-256 с SHA256)
    • ecdsa384 (ECDSA P-384 с SHA384)
    • ed25519
    • ed448

    Примечание

    Фактические поддерживаемые алгоритмы зависят от крипто-библиотек PowerDNS был скомпилирован с использованием. Чтобы проверить поддерживаемые алгоритмы DNSSEC в вашей сборке PowerDNS запустите pdnsutil list -gorithms .

    default-ksk-size

    Размер ключа по умолчанию для KSK, созданного с помощью pdnsutil secure-zone.Актуально только для алгоритмов с нефиксированным размером ключей (например, RSA).

    default-publish-cdnskey

    Значение PUBLISH-CDNSKEY по умолчанию для зон, для которых не задана отдельная зона. Для получения дополнительной информации см. Документы PUBLISH-CDNSKEY, PUBLISH-CDS.

    default-publish-cds

    • Целые числа, разделенные запятыми
    • По умолчанию: пусто

    Значение PUBLISH-CDS по умолчанию для зон, для которых не задана отдельная зона.Для получения дополнительной информации см. Документы PUBLISH-CDNSKEY, PUBLISH-CDS.

    по умолчанию-soa-content

    • Строка
    • По умолчанию: a.misconfigured.dns.server.invalid hostmaster. @ 0 10800 3600 604800 3600

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

    по умолчанию-soa-edit

    Используйте это значение редактирования для всех зон, если нет Значение метаданных SOA-EDIT установлено.

    default-soa-edit-signed

    Используйте это значение soa-edit для всех подписанных зон, если нет Значение метаданных SOA-EDIT установлено. Переопределяет default-soa-edit

    по умолчанию-soa-mail

    Не рекомендуется, начиная с версии 4.2.0: этот параметр был удален в 4.4.0

    Почтовый адрес для вставки в запись SOA, если в бэкэнде не задан.

    default-soa-name

    • Строка
    • По умолчанию: a.misconfigured.dns.server.invalid

    Не рекомендуется, начиная с версии 4.2.0: этот параметр был удален в 4.4.0

    Имя для вставки в запись SOA, если в бэкэнде не задано.

    по умолчанию-ttl

    TTL для использования, когда его нет.

    по умолчанию-zsk-алгоритм

    Изменено в версии 4.1.0: Переименовано с default-zsk-algorithmms . Больше не поддерживает несколько имен алгоритмов.

    Алгоритм, который следует использовать для ZSK при запуске pdnsutil secure-zone или с помощью конечной точки Zone API для включения DNSSEC.Должен быть одним из:

    • rsasha1
    • rsasha256
    • rsasha512
    • ecdsa256 (ECDSA P-256 с SHA256)
    • ecdsa384 (ECDSA P-384 с SHA384)
    • ed25519
    • ed448

    Примечание

    Фактические поддерживаемые алгоритмы зависят от крипто-библиотек PowerDNS был скомпилирован с использованием. Чтобы проверить поддерживаемые алгоритмы DNSSEC в вашей сборке PowerDNS запустите pdnsutil list -gorithms .

    размер по умолчанию zsk

    Размер ключа по умолчанию для ZSK, созданного с помощью pdnsutil secure-zone.Актуально только для алгоритмов с нефиксированным размером ключей (например, RSA).

    прямой ключ

    Прочтите дополнительные записи DNSKEY, CDS и CDNSKEY из таблицы записей / вашего файла зоны BIND. Если не set, записи DNSKEY, CDS и CDNSKEY в файлах зон игнорируются.

    отключить-axfr

    Не разрешать передачи зон.

    отключить-axfr-rectify

    Отключить этап исправления во время исходящего AXFR. Требуется только для регрессионное тестирование.

    отключить системный журнал

    Не входить в системный журнал, только в стандартный вывод. Используйте этот параметр при запуске внутри супервизора, который обрабатывает ведение журнала (например, systemd).

    Предупреждение

    Не используйте этот параметр в сочетании с демоном, поскольку все регистрация исчезнет.

    отключить TCP

    Изменено в версии 4.2.0: Этот параметр был удален

    Не слушать TCP-запросы. Нарушает соответствие RFC.

    .

    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *