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

, который для своей работы использует порт 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 —

. А так же

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

(

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

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

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

, а k-max.nam

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

.

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

mail.k-max.name.
 |     |  |  | |
 |     |  |  | +-корневой домен
 |     |  |  +---домен первого уровня
 |     |  +------точка, разделяющая домены/части 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)
• @ — Имя текущего домена
• ( ) — Позволяют данным занимать несколько строк
• * — Метасимвол (только в поле имя)

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

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

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

• 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)

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

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

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

или

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

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

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

root@DNS:~# cat /etc/nsswitch.conf
......
hosts:          files dns
networks:       files

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

) сначала из

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

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

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

или

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

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

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

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

root@DNS:~# cat /etc/resolv.conf
nameserver 192.168.1.1
nameserver 192.168.1.2
domain  examle.com

Директива

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

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

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

. Если

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

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

, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции 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

• 08/08/2018
• Чтение занимает 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

• 09/22/2020
• Чтение занимает 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 содержит следующую информацию:

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

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

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

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

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

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

Минимум (по умолчанию) 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-запись, которая содержит следующие свойства для зоны:

Сетевая рабочая группа П. Мокапетрис Запрос комментариев: 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: что это такое и что он делает

2. Образование
3. Основы Интернета
4. 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.