DNS
Пространство доменных имен DNS
Система доменных имен – это, прежде всего, база данных, содержащая информацию об узлах сети. Распределенная база данных системы доменных имен индексируется по именам узлов. Каждое доменное имя является просто путем в огромном перевернутом дереве, которое носит название пространства доменных имен.
Доменные имена
Каждому узлу дерева соответствует текстовая метка, длина которой не может превышать 63 символов, причем использование символа точки недопустимо. Пустая (нулевой длины) метка зарезервирована для корня. Полное доменное имя произвольного узла дерева – это последовательность меток в пути от этого узла до корня. Доменные имена всегда читаются от собственно узла к корню («вверх» по дереву), причем метки разделяются точкой.
Сама по себе метка корневого узла записывается исключительно из соображений удобства как самостоятельная точка (.). В результате некоторые программы интерпретируют имена доменов, заканчивающиеся точкой, как абсолютные. Абсолютное доменное имя записывается относительно корня и однозначно определяет расположение узла в иерархии. Абсолютное доменное имя известно также под названием полного доменного имени, обозначаемого аббревиатурой FQDN (fully qualified domain name). Имена без завершающей точки иногда интерпретируются относительно некоторого доменного имени (не обязательно корневого) точно так же, как имена каталогов, не начинающиеся с символа «/» (слэш), часто интерпретируются относительно текущего каталога.
В DNS «братские» узлы, то есть узлы, имеющие общего родителя, должны иметь разные метки. Такое ограничение гарантирует, что доменное имя единственно возможным образом идентифицирует отдельный узел дерева. Это ограничение на практике не является ограничением, поскольку метки должны быть уникальными только для братских узлов одного уровня, но не для всех узлов дерева.
Домены
Домен – это просто поддерево в пространстве доменных имен. Доменное имя домена идентично доменному имени узла на вершине домена.
Так что теоретически домен – это просто сегмент пространства доменных имен. Но если домен состоит только из доменных имен и других доменов, то где все узлы? Ведь домены то – это группы узлов, верно?
Узлы сети, разумеется, присутствуют, и представлены они доменными именами. Следует помнить, что доменные имена являются просто указателями в базе данных DNS. «Узлы» – это доменные имена, которые указывают на информацию по каждому конкретному узлу. Домен содержит все узлы сети, доменные имена которых в него входят. Узлы сети связаны логически, зачастую по географическому или организационному признаку, и совсем необязательно – сетью, адресом или типом используемого оборудования. Десяток узлов, входящих в разные сети, возможно даже расположенных в разных странах, может принадлежать одному единственному домену.
Доменные имена, соответствующие листьям дерева, как правило, относятся к отдельным узлам сети и могут указывать на сетевые адреса, информацию об оборудовании и о маршрутизации почты. Доменные имена внутри дерева могут идентифицировать отдельные узлы, а так же могут указывать на информацию об этом домене. Имена доменов внутри дерева не привязаны жестко к тому или другому варианту. Они могут представлять как домен (имени которого соответствуют), так и отдельный узел в сети.
Записи ресурсов
Информация, связанная с доменными именами содержится в записях ресурсов (RRs, resource records).1 Записи разделяются на классы, каждый из которых определяет тип сети или программного обеспечения. В настоящее время существуют классы для интернет сетей (на основе семейства протоколов TCP/IP), сетей на основе протоколов Chaosnet, а также сетей, которые построены на основе программного обеспечения Hesiod.
В пределах класса записи делятся на типы, которые соответствуют различным видам данных, хранимых в пространстве доменных имен. В различных классах определяются различные типы записей, хотя некоторые типы могут являться общими для нескольких классов. Так, практически в каждом классе определен тип адрес. Каждый тип записи в конкретном классе определяет формат, который должны соблюдать все RR записи, принадлежащие этому классу и имеющие данный тип.
DNS серверы и зоны
Программы, владеющие информацией о пространстве доменных имен, называются DNS серверами. DNS серверы обычно обладают полной информацией по определенным сегментам (или зонам) пространства доменных имен, которая загружается из файла либо может быть получена от других серверов имен. В таких случаях говорят, что сервер имен является авторитетным для конкретной зоны. DNS серверы могут быть авторитетными также и для нескольких зон.
Разница между зоной и доменом важна, но не очень заметна. Все домены высшего уровня и домены уровней от второго и ниже, такие как berkeley.edu и hp.com, разбиваются на более мелкие, легко управляемые единицы путем делегирования. Эти единицы называются зонами. Домен edu разделен на много зон, включая зону berkeley.edu, зону purdue.edu и зону nwu.edu. На вершине домена существует также зона edu. Естественно, что ребята, управляющие edu, разбивают домен edu на более мелкие единицы: в противном случае им пришлось бы самим сопровождать поддомен berkeley.edu. Гораздо более разумно делегировать berkeley.edu Беркли. Что же остается тем, кто управляет edu? Зона edu, которая содержит преимущественно информацию о делегировании для поддоменов, входящих в edu.
Поддомен berkeley.edu, в свою очередь, разбивается на несколько зон путем делегирования. Делегированные поддомены носят имена cc, cs, ce, me и т. д. Каждый из этих поддоменов делегируется ряду серверов имен, некоторые из которых являются компетентными и для berkeley.edu. Тем не менее зоны живут самостоятельно и могут иметь совершенно отдельный набор авторитетных DNS серверов.
Зона включает все доменные имена, которые включает домен с тем же именем, за исключением доменных имен, принадлежащих к делегированным поддоменам. Зона также содержит имена доменов и данные всех поддоменов, которые не были делегированы.
Теперь становится понятно, почему объектом, загружаемым DNS сервером, является зона, а не домен: домен может содержать больше информации, чем требуется для работы сервера. Домен может содержать данные, делегированные другим серверам. Поскольку зоны ограничиваются делегированием, они никогда не включают делегированные данные.
Обычно в начале существования у домена еще нет никаких поддоменов. В таком случае, поскольку делегирования не происходит, домен и зона содержат одинаковые данные.
Делегирование поддоменов
Даже в случае отсутствия насущной необходимости делегировать части домена полезно более широко понимать процедуру делегирования поддомена. Делегирование теоретически включает передачу ответственности за какую то часть домена другой организации. На деле же происходит назначение различных DNS серверов в качестве авторитетных в делегируемых поддоменах (мы не случайно употребляем здесь множественное число – именно серверов).
Хранимая зоной информация после делегирования включает уже не информацию по делегированному поддомену, а информацию о серверах имен, являющихся для этого поддомена авторитетными. В таком случае, если у DNS сервера родительского домена запрашиваются данные для поддомена, в ответ предоставляется список DNS серверов, которые обладают соответствующей информацией.
Разновидности DNS серверов
Спецификация DNS определяет два типа DNS серверов: первичный мастер сервер (primary master) и дополнительный, или вторичный мастер сервер (secondary master). Первичный мастер сервер производит загрузку данных для зоны из файла на машине сервере. Вторичный мастер сервер получает данные зоны от другого DNS сервера, который является авторитетным для этой зоны и называется его мастером (master server). Довольно часто мастер сервер является первичным мастером для зоны, но не обязательно: вторичный мастер сервер может получать зональные данные и от другого вторичного. Когда запускается вторичный сервер, он устанавливает связь с мастером и при необходимости получает зональные данные. Этот процесс называется передачей, или трансфером зоны (zone transfer).
Как первичный, так и вторичный мастер серверы зоны являются для этой зоны авторитетными. Несмотря на несколько уничижительное название, вторичные (slave) серверы не являются серверами второго сорта. Эти два типа серверов предусмотрены в DNS с целью облегчения администрирования. После создания зональных данных и установки первичного мастера можно не беспокоиться о копировании данных с узла на узел при создании дополнительных DNS серверов зоны. Достаточно просто установить вторичные DNS серверы, которые будут получать данные от первичного мастер сервера для этой зоны. После этого передача и получение зональных данных будут происходить по необходимости автоматически.
Вторичные серверы имеют большое значение, поскольку наличие нескольких авторитетных DNS серверов для каждой зоны – идея очень правильная. Понадобится больше одного сервера, чтобы обеспечить избыточность, распределить нагрузку, гарантировать, что каждому из узлов зоны легко доступен хотя бы один DNS сервер. Использование вторичных серверов делает такую архитектуру выгодной и в плане управления.
Однако было бы несколько неточно называть конкретный DNS сервер первичным или вторичным. Ранее мы говорили, что сервер может являться авторитетным для более чем одной зоны. Точно так же DNS сервер может являться первичным для одной зоны и вторичным – для другой. Но в большинстве случаев сервер имен является либо первичным, либо вторичным для большинства загружаемых им зон. Поэто му, когда мы называем конкретный сервер имен первичным или вторичным, то имеем в виду, что он является таковым для большинства зон, которые входят в сферу его компетенции.
Файлы данных зоны
Файлы, из которых первичные DNS серверы производят чтение зональных данных, называются, и вполне логично, файлами данных зоны. Мы достаточно часто называем их файлами данных. Вторичные DNS серверы также могут загружать зональные данные из файлов. Обычно вторичные серверы настраиваются таким образом, что при каждом получении зональных данных с основного сервера происходит сохранение резервной копии полученной информации в файлах данных. При последующем перезапуске или сбое происходит сначала чтение файлов с резервных копий в целях определения актуальности зональных данных. Это позволяет устранить необходимость в передаче зональных данных, если они не изменились, и обеспечивает вторичный DNS сервер рабочим набором данных в случае недоступности первичного сервера.
Файлы данных содержат RR записи, описывающие зону. RR записи описывают все узлы сети в зоне и помечают делегирование поддоменов.
Клиенты DNS
Клиенты DNS (resolvers) позволяют осуществлять доступ к DNS серверам. Программы, которым требуется информация из пространства доменных имен, используют DNS клиент, решающий следующие задачи:
- Опрашивание DNS серверов
- Интерпретация полученных ответов (RR записей или сообщений об ошибках)
- Возврат информации в программу, которая ее запросила
Клиент – это даже не отдельный процесс. Клиент практически во всем полагается на DNS серверы: его хватает ровно на то, чтобы создать запрос, отправить его и ждать ответа, затем повторно послать запрос, если ответ не получен; и это практически все, на что он способен. Большая часть работы, связанной с поиском ответа на вопрос, ложится на сервер имен. Спецификация DNS называет этот тип анализатора примитивным (stub resolver). В других реализациях системы DNS существуют более совершенные клиенты, способные делать гораздо более сложные вещи, например следовать перенаправляющим ответам и находить DNS серверы, являющиеся авторитетными для определенной зоны.
Разрешение имен
DNS серверы исключительно хорошо умеют получать данные из пространства доменных имен. Что неудивительно, учитывая ограниченную интеллектуальность большинства DNS клиентов. Серверы могут не только поставлять информацию по зонам, для которых являются авторитетными, но и производить поиск в пространстве доменных имен, получая данные зон, в их компетенцию не входящих. Этот процесс называется разрешением имен или просто разрешением.
Поскольку пространство имен имеет структуру перевернутого дерева, серверу нужна лишь частичка информации, чтобы пробраться к любому узлу дерева: доменные имена и адреса корневых DNS серверов (разве это больше, чем частичка?). Сервер может обратиться к корневому DNS серверу с запросом по любому доменному имени пространства до менных имен, после чего получает руководящие указания по продолжению поиска.
Корневые DNS серверы
Корневые серверы обладают информацией об авторитетных DNS серверах для каждой из зон высшего уровня. (На деле некоторые корневые DNS серверы одновременно являются авторитетными для некоторых родовых зон высшего уровня.) Получив запрос по любому доменному имени, корневой сервер может вернуть, по меньшей мере, список имен и адресов DNS серверов, авторитетных для зоны высшего уровня, в иерархии которой расположен домен. А DNS серверы высшего уровня могут вернуть список авторитетных серверов для зоны второго уровня, в иерархии которой расположен домен. Каждый из опрашиваемых серверов либо возвращает информацию о том, как подобраться «поближе» к искомому ответу, либо сразу конечный ответ.
Корневые серверы, очевидно, имеют очень большое значение для процесса разрешения имен. Поэтому в DNS существуют механизмы (скажем, кэширование), позволяющие разгрузить корневые серверы. Но в отсутствие другой информации разрешение должно начинаться с корневых DNS серверов. И это делает корневые серверы ключевым элементом работы DNS. Недоступность всех корневых DNS серверов сети Интернет в течение длительного времени привела бы к невозможности разрешения имен в сети.
Локальный DNS сервер запрашивает адрес girigiri.gbrmpa.gov.au у корневого сервера и получает ссылку на DNS серверы домена au. Локальный сервер повторяет запрос, отправляя его одному из DNS серверов au, и получает ссылку на серверы gov.au. DNS сервер gov.au отсылает локальный DNS сервер к серверам gbrmpa.gov.au. И наконец, локальный DNS сервер запрашивает DNS сервер gbrmpa.gov.au и получает искомый адрес.
Рекурсивные и итеративные dns-запросы
Почему локальный DNS сервер попросту не перенаправил клиент к другому серверу? Потому что примитивный клиент не способен следовать по таким ссылкам. Каким образом сервер понял, что отвечать клиенту ссылкой – пустая трата времени? Очень просто: клиент сделал рекурсивный запрос. Существуют запросы двух видов: рекурсивные и итеративные (или нерекурсивные). Рекурсивные запросы возлагают большую часть работы по разрешению имени на единственный DNS сервер. Рекурсия, или рекурсивное разрешение имен, – это название последовательности действий DNS сервера при получении им рекурсивного запроса. Сервер DNS повторяет какую то базовую последовательность действий (посылает запрос удаленному серверу и следует по ссылкам), пока не получит ответ, то есть действует аналогично рекурсивному алгоритму программирования.
Итерация, или итеративное разрешение имен, – это название последовательности действий DNS сервера при получении им итеративного запроса.
В случае рекурсии клиент посылает серверу рекурсивный запрос информации для определенного доменного имени. Сервер в таком случае обязан вернуть ответ на запрос (запрошенную информацию) либо ошибку, сообщающую, что данные указанного типа не существуют либо не существует доменное имя. Сервер не может вернуть ссылку на другой DNS сервер, если запрос рекурсивный.
Если DNS сервер, получивший запрос, не авторитетен для запрашиваемой информации, ему придется опрашивать другие серверы в поисках ответа. В этом случае сервер может делать либо рекурсивные запросы, возлагая таким образом ответственность за нахождение ответа на опрашиваемые DNS серверы (и снимая с себя ответственность), либо итеративные запросы, возможно получая ссылки на DNS серверы, расположенные «ближе» к искомому доменному имени. Существующие реализации очень воспитаны и по умолчанию действуют по второ му варианту, следуя по ссылкам, пока не будет найден ответ.
DNS сервер, получивший рекурсивный запрос, на который он сам не в состоянии ответить, отправляет запрос «ближайшим известным» серверам. Ближайшие известные серверы – это те, которые являются авторитетными для зоны, ближе всего расположенной к доменному имени, о котором идет речь. К примеру, если сервер получает рекурсивный запрос для адреса доменного имени girigiri.gbrmpa.gov.au, он, прежде всего, выяснит, известно ли, какие серверы являются авторитетными для girigiri.gbrmpa.gov.au, и, если это известно, отправит запрос одному из них. В противном случае будет произведен аналогичный поиск DNS серверов для gbrmpa.gov.au, а затем для gov.au и au. По умолчанию поиск не будет продолжаться дальше корневой зоны, поскольку каждому DNS серверу известны доменные имена и адреса корневых серверов имен. Использование ближайших известных DNS серверов позволяет во всех случаях максимально сократить процесс разрешения.
Итеративное взаимодействие
Итеративное разрешение не требует от DNS сервера такой серьезной работы. При итеративном разрешении сервер имен возвращает наилучший ответ из уже известных ему. Выполнение дополнительных запросов в таком случае не требуется. Сервер имен, получивший запрос, сверяется с локальными данными (в том числе и данными кэша) в поисках запрошенной информации. Если конечный ответ в этих данных не содержится, сервер находит в локальных данных имена и адреса DNS серверов, наиболее близко расположенных к доменному имени, для которого сделан запрос, и возвращает их в качестве указания для продолжения процесса разрешения. Заметим, что ответ включает все серверы имен, содержащиесяв локальных данных, и выбор следующего DNS сервера для опроса совершается отправителем итеративного запроса.
Кратко о разрешении доменного имени
DNS клиент отправляет запрос локальному DNS серверу, который посылает итеративные запросы ряду других серверов в поисках ответа. Каждый из опрашиваемых серверов возвращает ссылку на другой сервер, который является авторитетным для зоны, расположенной ближе к искомому доменному имени и глубже в дереве пространства имен. В итоге локальный сервер посылает запрос авторитетному серверу, который и возвращает ответ. На протяжении всего процесса поиска локальный DNS сервер использует каждый из получаемых ответов, будь то ссылка или искомая информация, для обновления метрики RTT для реагирующих на запросы DNS серверов, что впоследствии позволяет принимать осмысленные решения при выборе серверов, используемых в процессе разрешения доменных имен.
Отображение адресов в имена
Отображение адрес-имя необходимо для получения вывода, который легко воспринимается людьми (скажем, при чтении log файлов). Это отображение также применяется в авторизации. Например, UNIX узлы преобразуют адреса в доменные имена с целью сравнения их с записями в файлах .rhosts и hosts.equiv. При использовании таблиц узлов отображение адресов в доменные имена довольно тривиально. Требуется обычный последовательный поиск адреса в таблице узлов. Поиск возвращает указанное в таблице официальное имя узла.
Но в DNS преобразование адреса в имя происходит несколько сложнее. Данные, в том числе и адреса, которые хранятся в пространстве доменных имен, индексируются по именам. Если есть доменное имя, поиск адреса – процедура относительно простая. Но поиск доменного имени, которому соответствует заданный адрес, казалось бы, потребует полного перебора данных для всех доменных имен дерева.
На деле же существует другое решение, более разумное и эффективное. Несложно производить поиск по доменным именам, поскольку они являются своеобразными индексами базы данных, и точно таким же образом можно создать сектор пространства доменных имен, в котором в качестве меток будут использоваться адреса. В пространстве доменных имен сети Интернет таким свойством обладает домен in-addr.arpa.
Узлам домена in-addr.arpa в качестве меток присваиваются числа в нотации IP адреса (dotted octet representation – октеты, разделенные точками, – распространенный метод записи 32 битных IP адресов в виде четырех чисел, принадлежащих интервалу от 0 до 255 и разделяемых точками). Так, домен in-addr.arpa может содержать до 256 поддоменов, каждый из которых будет соответствовать одному из возможных значений первого октета IP адреса. Каждый из этих поддоменов может содержать до 256 собственных поддоменов, каждый из которых будет соответствовать одному из возможных значений второго октета. Наконец, на четвертом уровне существуют RR записи, ассоциированные с последним октетом, которые содержат полное доменное имя узла по данному IP адресу. Результатом подобных построений является невероятно объемный домен: in-addr.arpa, достаточно вместительный, чтобы охватить все IP адреса сети Интернет.
Заметим, что при чтении в доменном имени IP адрес оказывается записанным наоборот, поскольку имя читается от листа дерева к корню. К примеру, если IP адрес узла winnie.corp.hp.com – 15.16.192.152, со ответствующий узел в домене in-addr.arpa – 152.192.16.15.in-addr.arpa, который отображается в доменное имя winnie.corp.hp.com.
То, что первые октеты IP адреса расположены выше в дереве, позволяет администраторам делегировать ответственность за зоны in-addr.arpa в соответствии с топологией сети. Возьмем для примера зону 15.in-addr.arpa, которая содержит данные обратного преобразования для всех узлов, адреса которых начинаются с цифры 15: эта зона может быть делегирована администраторам сети 15/8. Это стало бы невозможным, если бы октеты были расположены в обратном порядке. Если бы IP адреса записывались наоборот (в другом порядке), зона 15.in-addr.arpa включала бы каждый узел, IP адрес которого заканчивает ся цифрой 15, и делегировать эту зону было бы немыслимо.
Кэширование
По сравнению с простым поиском в таблице узлов процесс разрешения может показаться ужасно запутанным и нескладным. В действительности же этот процесс довольно быстр. Одна из возможностей, существенно его ускоряющих, – кэширование. Чтобы обработать рекурсивный запрос, DNS серверу приходится самостоятельно сделать довольно много запросов. Однако в процессе сервер получает большое количество информации о пространстве доменных имен. Каждый раз, получая список DNS серверов в ссылке, он знакомится с серверами, авторитетными для какой то зоны, и узнает адреса этих серверов. Когда завершается процесс разрешения и необходимые данные возвращаются клиенту, сделавшему исходный запрос, новые знания могут быть сохранены для последующего использования.
DNS серверы кэшируют получаемые данные, чтобы ускорить обработку последующих запросов. Когда в следующий раз DNS клиент сделает запрос по доменному имени, о котором серверу уже что то известно, процесс разрешения пройдет быстрее. Если сервер кэшировал ответ, положительный или отрицательный, ответ просто возвращается клиенту. Но даже если готового ответа у DNS сервера нет, он, возможно, «помнит в лицо» те DNS серверы, которые являются авторитетными для зоны этого конкретного доменного имени, и будет напрямую работать с ними.
Время жизни
Разумеется, DNS серверы не могут кэшировать данные навсегда. Иначе изменения на авторитетных серверах никогда не распространялись бы по сети. Удаленные серверы просто продолжали бы использовать кэшированную информацию. Поэтому администратор зоны, которая содержит данные, обычно определяет для этих данных время жизни (time to live, или TTL). Время жизни – это интервал времени, в течение которого произвольному DNS серверу разрешается пользоваться кэшированными данными. По окончании этого временного интервала сервер обязан удалить кэшированную информацию и получить новую от авторитетных DNS серверов. Это касается также кэшируемых отрицательных ответов, сервер имен обязан удалять их на случай, если на авторитетных DNS серверах появилась новая информация.
BIND
Выбор авторитетного DNS сервера
DNS серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитетных DNS серверов одной зоны. Время отклика определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз при передаче запроса удаленному серверу DNS сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если серверу приходится выбирать один из нескольких авторитетных серверов, выбор падает на сервер с наименьшим временем отклика.
До того как сервер BIND впервые послал запрос некоему серверу и получил от него ответ, удаленному серверу присваивается случайное значение времени отклика, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS сервер BIND гарантированно опросит все авторитетные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.
В общем и целом, это простой, но элегантный алгоритм, позволяющий DNS серверам BIND достаточно быстро «зацикливаться» на ближайших DNS серверах, не прибегая к нестандартным, требовательным к ресурсам механизмам измерения производительности.
Основной файл настроек сервера BIND
Обычно это /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
listen-on port 53 { 127.0.0.1; 45.144.235.105; }; # адреса на которых сервер будет принимать запросы
allow-query { any; }; # адреса сетей из которых принимаем запросы
allow-recursion { 127.0.0.0/8; 192.168.72.0/24; }; # разрешаем рекурсивные запросы для localhost и локальной сети
allow-transfer { none; }; # кому можно предавать данные DNS-зон, по умолчанию никому
forwarders { 8.8.8.8; 8.8.4.4; }; # сервера пересылки, которым мы будем передавать запросы, которые не сможем разрешить самостоятельно, указываем любые внешние DNS
dnssec-validation auto;
listen-on-v6 { none; };
}
Файлы данных для зоны
Файлы зоны обслуживаемых сервером BIND рекомендуется хранить в отдельной папке на пример /etc/bind/zones/
Настройка прямой зоны
Прямая зона отвечает за сопоставление доменных имен IP-адресам, при запросе к прямой зоне мы указываем доменное имя и получаем в ответ связанный с ним IP-адрес.
; /etc/bind/zones/db.example.com
;
$TTL 86400 ; TTL - время жизни DNS-записи, именно на это время клиент может поместить ее в собственный кеш,
; по истечении TTL клиент обязан запросить запись заново
; SOA-запись показывает, что данный DNS сервер является самым надежным источником информации в пределах этой зоны.
; @ IN SOA - основная запись домена, указывает его корневой DNS-сервер - ns.example.com. и адрес ее администратора admin.example.com. (который следует понимать, как root@interface31.lab).
; Символ @ в начале строки указывает на текущий домен
@ IN SOA ns.example.com. admin.example.com. (
2024051701 ; Serial - серийный номер зоны, при каждом изменении данных мы должны увеличивать серийный номер,
; по его изменению вторичные сервера понимают, что произошли изменения и начинают синхронизацию.
; Широко применяется следующий алгоритм формирования серийного номера: ГГГГ-ММ-ДД плюс две цифры указывающие на номер итерации, если в одну и ту же дату вносится несколько изменений.
604800 ; Refresh - период обновления данных вторичными серверами,
; по истечении данного времени они повторно запрашивают у основного сервера SOA-запись и анализируют серийный номер
86400 ; Retry - периодичность повторного обращения к основному серверу, если предыдущая попытка завершилась неудачей
2419200 ; Expire - максимальное время жизни зоны на вторичных серверах при отсутствии синхронизации с основным,
; по истечении этого времени вторичный сервер перестает обслуживать запросы
604800 ) ; Negative Cache TTL - время жизни негативного кеша или минимальное время жизни записи.
; Применяется для кеширования неудачного результата запроса со стороны клиента, например, обращение к несуществующему доменному имени.
; NS-записи - делегирует зону DNS для использования определенного полномочного сервера имен.
@ IN NS ns.example.com. ; NS-записи, которые указывают на сервера имен, обслуживающие зону.
; A-записи содержат имя хоста и соответствующий ему адрес IPv4.
@ IN A 192.0.0.1 ; символ @ относится к текущему домену, т.е. определяет какой адрес вернет сервер если будет запрошено имя домена
ns IN A 192.0.0.1 ; IP-адрес вашего сервера
host1 IN A 192.0.0.20 ; A-запись указывает на IP-адрес сервера
; CNAME-записи - используются для создания псевдонимов доменных имен.
some.aliase IN CNAME host2 ; CNAME-запись - псевдоним который указывает на другое доменное имя, типа ссылки
; MX-записи - указывает почтовый сервер для доменного имени, используемый в протоколе SMTP для маршрутизации электронной почты на нужный почтовый сервер.
@ IN MX 10 mx1.example.com. ; почтовый сервер1, с наивысшим приоритетом
@ IN MX 20 mx2.example.com. ; почтовый сервер2 с меньшим приоритетом
Также необходимо определить зону в конфигурации BIND /etc/bind/named.conf.local
zone "example.com" { # наименование зоны, которую будет обслуживать сервер, задается в виде доменного имени
type master; # тип зоны, в нашем случае - master - первичная
file "/etc/bind/zones/db.example.com"; # файл с данными зоны
allow-transfer { 192.168.0.2; }; # узел, которому разрешается передавать данные зоны, указываем адрес нашего вторичного DNS-сервера
};
Настройка обратной зоны
Обратная зона предназначена для обратного преобразования, с ее помощью мы можем по IP-адресу узнать доменное имя узла. Для повседневной работы обратная зона обычно не требуется, и многие администраторы ее не создают, но при ее отсутствии могут возникнуть проблемы у многих сетевых сервисов, чаще всего неявные и неочевидные для начинающих, поэтому мы рекомендуем всегда сразу создавать обратную зону.
; /etc/bind/zones/db.192.168.0
;
$TTL 86400
; SOA-запись ничем не отличается от аналогичной записи прямой зоны и записи, указывающие на сервера имен, обслуживающие зону.
@ IN SOA ns.example.com. admin.example.com. (
2024051701 ; Serial -
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; NS-записи такие же как в прямой зоне
@ IN NS ns.example.com. ; NS-записи, которые указывают на сервера имен, обслуживающие зону.
;
; PTR-запись - используются для поиска доменных имен на основе IP-адреса.
; каждый адрес должен указывать на единственное имя – каноническое.
20.0.168.192.in-addr.arpa IN PTR host1.example.com
Также необходимо определить зону в конфигурации BIND /etc/bind/named.conf.local
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.192.168.0";
};
Loopback адрес
Серверу имен требуется еще один дополнительный файл db.ADDR для loopback -сети и специального адреса, который используется узлом для направления пакетов самому себе. Эта сеть (почти) всегда имеет номер 127.0.0/24, а адрес узла (почти) всегда – 127.0.0.1.
; /etc/bind/zones/db.127
;
$TTL 604800
@ IN SOA ns.example.com. admin.example.com. (
2024051701 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.example.com.
; PTR записи для loopback адресов
1 IN PTR localhost.
Также необходимо определить зону в конфигурации BIND /etc/bind/named.conf.local
zone "0.0.127.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.127";
};
PowerDNS
PowerDNS - это универсальный сервер имен, который поддерживает большое количество различных бэкендов, начиная от простых файлов зон и заканчивая реляционными базами данных и алгоритмами распределения нагрузки и отказоустойчивости. Основное отличие от других решений состоит в том, что он может использовать файлы конфигурации BIND, считывать информацию из MariaDB, MySQL, Oracle, PostgreSQL и других баз данных.
PowerDNS (PDNS) имеет два ключевых компонента: авторитетный сервер (authoritative server) и рекурсор (recursor). Другие DNS-серверы объединяют эти роли в одну. Соответственно, PDNS может работать как авторитетный сервер имен, то есть, как оригинальный источник информации о зоне DNS и как простой рекурсор для конкретного домена. Из ключевых особенностей PDNS можно выделить:
# pdnsutil - утилита для работы с зонами и записями
# Удаляем зону example.com
pdnsutil delete-zone example.com
# Создаем и редактируем новую зону akulovs.ru
pdnsutil create-zone akulovs.ru ns1.akulovs.ru.
pdnsutil set-kind akulovs.ru MASTER
pdnsutil replace-rrset akulovs.ru @ SOA 'ns1.akulovs.ru. admin.akulovs.ru. 1 3600 1800 1209600 3600'
# Добавляем записи в зону
pdnsutil add-record akulovs.ru ns1 A 45.144.235.105
pdnsutil add-record akulovs.ru @ A 45.144.235.105
# Редактируем записи зоны в удобном редакторе
pdnsutil edit-zone akulovs.ru
# Проверяем листинг зоны
pdnsutil list-zone akulovs.ru