DNS сервер (BIND9)
Источники:
https://habrahabr.ru/post/137587/
http://www.itworkroom.com/?p=1334
Настройка DNS сервера на базе BIND9
Теория. Что такое DNS, и нафига оно.
Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как самого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 (query...) и для некоторых запросов TCP/53 (transfer...).
Основные понятия Domain Name System
Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:
Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов:http://www.root-servers.org/. Настройки корневой зоны всегда доступны тут:ftp://ftp.internic.net/domain/named.root. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.
Зона — это любая часть дерева системы доменных имен, размещаемая как единое целое на некотором DNS-сервере. Зону, для бОльшего понимания, можно назвать «зоной ответственности». Целью выделения части дерева в отдельную зону является передача ответственности (Делегирование) за эту ветвь другому лицу или организации. На иллюстрации, примеры зон выделены синим градиентом (зона name., зона k-max.name. со всем подчиненными ресурсами, http://www.openoffice.org со всем подчиненными поддоменами и ресурсами). На иллюстрации выделены не все зоны, а лишь некоторые для общего понимания и представления. В каждой зоне имеется, по крайней мере, один авторитетный сервер DNS, который хранит ВСЮ информацию о зоне, за которую он отвечает.
Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:
Таким образом, пространство имен раздроблено на зоны (zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.
FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:
mail.k-max.name.
| | | | |
| | | | +-корневой домен
| | | +---домен первого уровня
| | +------точка, разделяющая домены/части FQDN
| +---------домен второго уровня
+---------------поддомен/домен третьего уровня, возможно - имя хоста
Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.
Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.
Итак, на схеме выше мы рассмотрели корневой домен, следующим в иерархии идут домены первого/верхнего уровня, они же TLD, они же Top-Level Domain. К данным доменам относятся национальные домены (ru., ua. и др) и общие домены (com., net., и др). Существуют так же специализированные домены, которые не опубликованы в системе DNS, но используются программами (домен .onion используется анонимной сетью Tor для перехвата и последующей маршрутизации обращений к скрытым сервисам этой сети). Еще есть т.н. зарезервированные доменные имена, определенные в RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. К таким именам относятся например example.com, example.org и example.net, а также test, invalid и др. Ниже по иерархии, как видно, идут домены третьего уровня и т.д. Заканчивается доменная иерархия — именами хостов, которые задаются соответствующими ресурсными записями или хостовыми записями.
Ресурсные записи
Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.
Запись ресурса состоит из следующих полей:
имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.
Time To Live (TTL) — дословно «время жизни» записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.
класс (CLASS) — определяет тип сети, (в 99,99% случаях используется IN (что обозначает — Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)
тип (TYPE) — тип записи синтаксис и назначение записи
данные (DATA) — различная информация, формат и синтаксис которой определяется типом.
При этом, возможно использовать следующие символы:
-
; — Вводит комментарий
-
# — Также вводит комментарии (только в версии BIND 4.9)
-
@ — Имя текущего домена
-
( ) — Позволяют данным занимать несколько строк
-
* — Метасимвол (только в поле имя)
Со всем набором ресурсных записей можно ознакомиться в примечании1. Наиболее часто применяемые ресурсные записи следующие (далее, мы обязательно рассмотрим их на практике):
-
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 для хоста http://www.k-max.name.:
Код: Выделить всё
ftp 86400 IN CNAME http://www.k-max.name.
-
MX (mail exchange) — указывает хосты для доставки почты, адресованной домену. При этом поле NAME указывает домен назначения, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение MX, а поле DATA указывает приоритет и через пробел - доменное имя хоста, ответственного за прием почты. Например, следующая запись показывает, что для домена k-max.name направлять почту сначала на mx.k-max.name, затем на mx2.k-max.name, если с mx.k-max.name возникли какие-то проблемы. При этом, для обоих MX хостов должны быть соответствующие A-записи:
Код: Выделить всё
k-max.name. 17790 IN MX 10 mx.k-max.name. k-max.name. 17790 IN MX 20 mx2.k-max.name.
-
NS (name server/сервер имён) указывает на DNS-сервер, обслуживающий данный домен. Вернее будет сказать — указывают сервера, на которые делегирован данный домен. Если записи NS относятся к серверам имен для текущей зоны, доменная система имен их практически не использует. Они просто поясняют, как организована зона и какие машины играют ключевую роль в обеспечении сервиса имен. Например, зону name. обслуживают следующие NS:
Код: Выделить всё
name. 5772 IN NS l6.nstld.com. name. 5772 IN NS m6.nstld.com. name. 5772 IN NS c6.nstld.com. name. 5772 IN NS j6.nstld.com.
зону k-max.name обслуживают:
Код: Выделить всё
k-max.name. 1577 IN NS ns2.jino.ru. k-max.name. 1577 IN NS ns1.jino.ru.
-
PTR (pointer) — отображает IP-адрес в доменное имя (о данном типе записи поговорим ниже в разделе обратного преобразования имен).
-
SOA (Start of Authority/начальная запись зоны) — описывает основные/начальные настройки зоны, можно сказать, определяет зону ответственности данного сервера. Для каждой зоны должна существовать только одна запись SOA и она должна быть первая. Поле Name содержит имя домена/зоны, поля TTL, CLASS — стандартное значение, поле TYPE принимает значение SOA, а поле DATA состоит из нескольких значений, разделенных пробелами: имя главного DNS (Primary Name Server), адрес администратора зоны, далее в скобках — серийный номер файла зоны (Serial number). При каждом внесении изменений в файл зоны данное значение необходимо увеличивать, это указывает вторичным серверам, что зона изменена, и что им необходимо обновить у себя зону. Далее — значения таймеров (Refresh — указывает, как часто вторичные серверы должны опрашивать первичный, чтобы узнать, не увеличился ли серийный номер зоны, Retry — время ожидания после неудачной попытки опроса, Expire — максимальное время, в течение которого вторичный сервер может использовать информацию о полученной зоне, Minimum TTL — минимальное время, в течение которого данные остаются в кэше вторичного сервера). Ниже в примере приведено 2 одинаковые записи SOA (хотя вторая и записана в несколько строк), но они одинаковы по значению и формат записи второй более понятен в силу его структурированности:
Код: Выделить всё
k-max.name. 86400 IN SOA ns1.jino.ru. hostmaster.jino.ru. 2011032003 28800 7200 604800 86400
Код: Выделить всё
k-max.name. 86400 IN SOA ns1.jino.ru. hostmaster.jino.ru. ( 2011032003 ; serial (серийный номер) 28800 ; refresh (обновление) 7200 ; retry (повторная попытка) 604800 ; expire (срок годности) 86400) ; minimum TTL (минимум)
-
SRV (server selection) — указывают на сервера, обеспечивающие работу тех или иных служб в данном домене (например Jabber и Active Directory).
Делегирование
Давайте рассмотрим, что есть Делегирование. Делегирование (корректнее сказать делегирование ответственности) — это операция передачи ответственности за часть дерева доменных имен (зону) другому лицу или организации. За счет делегирования, в DNS обеспечивается распределенность администрирования и хранения зон. Технически, делегирование заключается в выделении какой-либо части дерева в отдельную зону, и размещении этой зоны на DNS-сервере, принадлежащем другому лицу или организации. При этом, в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на авторитативные DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны. Например, на иллюстрации корневой домен делегирует полномочия серверам отвечающим за TLD, TLD же в свою очередь, делегируют полномочия управления зонами — серверам второго уровня, иногда на этом цепочка заканчивается, но бывает, что делегирование простирается до 4 и даже 5 уровней.
Для большего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.
Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.
Серверы DNS
Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.
Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.
Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.
Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.
Клиенты DNS (resolver)
Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:
Код: Выделить всё
root@DNS:~# cat /etc/nsswitch.conf
......
hosts: files dns
networks: files
Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:
Код: Выделить всё
root@DNS:~# cat /etc/resolv.conf
nameserver 192.168.1.1
nameserver 192.168.1.2
domain examle.com
Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.
Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:
Запросы DNS
В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.
Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.
Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.
Обратный запрос посылает IP и просит вернуть доменное имя.
Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.
Обычно, в локальной сети стоит DNS-сервер, обрабатывающий рекурсивные запросы, а так же, скорее всего, он настроен на кэширование запросов, что экономит трафик и снижает нагрузку на сеть. Схему взаимодействия клиента и DNS серверов можно представить следующей картинкой:
Давайте разберем, что тут нарисовано по шагам:
-
Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запрос резолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
-
Резолвер посылает запрос указанному серверу имен.
-
Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запрос серверу, отвечающему за корневую зону.
-
Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
-
Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
и «вложенности» доменных имен. -
В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
-
Сервер локальной сети возвращает резолверу клиента запрошенные данные.
Обычно, количество шагов сокращено до минимума, т.к. на пути прохождения запросов встречается кэширующий сервер, который хранит необходимую информацию в кэше. В данной схеме может возникнуть вопрос: каким образом локальный DNS сервер, получивший рекурсивный запрос от резолвера, выбирает DNS-сервер из списка авторитативных? Существует множество корневых DNS-серверов в сети Интернет, какому из корневых серверов наш DNS-сервер отправит запрос?
Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.
До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.
Ответы DNS сервера
Ответы DNS бывают следующего типа:
Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).
Ответ DNS обычно содержит следующую информацию:
Запись заголовка — служебную информацию о запросе.
Запись запроса — повторяет отправленный запрос.
Запись ответа — собственно, сам ответ.
Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
Дополнительную информацию — дополнительные записи, например адреса NS-серверов.
Вышенаписанное наглядно подтверждается утилитой dig:
Код: Выделить всё
root@DNS:~# dig ya.ru
; <<>> DiG 9.7.3 <<>> ya.ru (раздел заголовка)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53499
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 2, ADDITIONAL: 3
;; QUESTION SECTION: (раздел запроса)
;ya.ru. IN A
;; ANSWER SECTION: (раздел ответа)
ya.ru. 4813 IN A 87.250.250.203
ya.ru. 4813 IN A 87.250.251.3
ya.ru. 4813 IN A 93.158.134.3
ya.ru. 4813 IN A 93.158.134.203
ya.ru. 4813 IN A 213.180.204.3
ya.ru. 4813 IN A 77.88.21.3
ya.ru. 4813 IN A 87.250.250.3
;; AUTHORITY SECTION: (авторитативные сервера)
ya.ru. 4813 IN NS ns1.yandex.ru.
ya.ru. 4813 IN NS ns5.yandex.ru.
;; ADDITIONAL SECTION: (дополнительная информация - адреса авторитативных name servers)
ns5.yandex.ru. 345565 IN A 213.180.204.1
ns1.yandex.ru. 345565 IN A 213.180.193.1
ns1.yandex.ru. 3565 IN AAAA 2a02:6b8::1
;; Query time: 7 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Jul 2 23:02:45 2011
;; MSG SIZE rcvd: 238
Обратное преобразование имен
DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.
На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.
В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
Наглядно приведенную схему можно представить командами:
Код: Выделить всё
[root@DNS~]# dig http://www.ru
...
;; QUESTION SECTION:
;www.ru IN A
;; ANSWER SECTION:
http://www.ru 52119 IN A 194.87.0.50
...
[root@DNS~]# dig -x 194.87.0.50
...
;; QUESTION SECTION:
;50.0.87.194.in-addr.arpa. IN PTR
;; ANSWER SECTION:
50.0.87.194.in-addr.arpa. 30385 IN PTR http://www.ru
При этом, команду dig -x 194.87.0.50 правильнее будет представить как dig 50.0.87.194.in-addr.arpa., то есть записи в поддоменах *.in-addr.arpa. представлены в так называемой обратной нотации (или reverse форме), то есть хосту с IP 194.87.0.50 будет соответствовать PTR-запись, имеющая FQDN 50.0.87.194.in-addr.arpa., которая в свою очередь указывает на домен http://www.ru Хочется отметить, что чаще всего за обратную зону и ее редактирование отвечает поставщик интернета.
Как и обещал, описываю ресурсную запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины http://www.ru. будет иметь такой вид:
Код: Выделить всё
50.0.87.194 IN PTR www.ru
Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:
Код: Выделить всё
80 IN PTR www.ru
Код: Выделить всё
Регистрация доменных имен
В двух словах хотел бы затронуть вопрос регистрации доменных имен.
Регистрация доменов — это действие, посредством которого клиент сообщает регистратору, каким DNS-серверам следует делегировать поддомен, и также снабжает регистратора контактной и платежной информацией. Регистратор передает информацию в соответствующий реестр. Чаще всего, это процесс внесения в реестр зоны первого уровня (то есть в TLD зоны ru, com или др.), записи о новом доменном подимени.
Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.
Уровни доменов, для которых необходима обязательная регистрация лица, ответственного за домен, следующие:
корневой домен
все домены первого уровня (TLD)
некоторые домены второго уровня (например, com.ru или co.uk)
Регистратором для корневого домена является организация ICANN. Чтобы стать регистратором доменов в зонах второго уровня (.com .net .org .biz .info .name .mobi .asia .aero .tel .travel .jobs ...), необходимо получить аккредитацию ICANN.
Правила регистрации в международных (gTLD — com., org, и др.) доменах устанавливаются ICANN. Правила регистрации в национальных (ccTLD — ru, us и др.) доменах устанавливаются их регистраторами и/или органами власти соответствующих стран, например единые правила для всех регистраторов в доменах .ru, и.рф задаются Координационным центром национального домена сети Интернет. Для многих доменов (в том числе и для ru) регистратор не единственный. При наличии нескольких регистраторов все они должны использовать единую (централизованную или распределённую) базу данных для исключения конфликтов и обеспечения уникальности доменного имени.
Услуга регистрации домена в большинстве случаев платная, цену и условия регистрации определяет регистратор. Для регистрации домена, необходимо выбрать свободное имя и отправить заявку на регистрацию у одного из регистраторов (например nic.ru), оплатить предоставление услуги. После подтверждения регистрации, необходимо в интерфейсе регистратора определить (делегировать) dns сервера, скорее всего это будут DNS вашего хостера.
В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.
Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Настройка кэширующего DNS сервера BIND9 для локальной сети в Linux.
Бывает много причин для внедрения своего ДНС сервера, кому то нужен он для локальной сети, чтобы не запоминать ip адреса пользователей и устройств, другой причиной может являться неудовлетворительная работа ДНС серверов провайдера. Очень нервирует когда крупный провайдер не может предоставить достойный доступ, ДНС сервера не могут обработать запрос в течении 1-3 минут, и все страницы тупо отваливаются так и не выяснив ip адрес сайта.
Установим DNS сервер Bind9:
Код: Выделить всё
sudo apt-get install bind9
Главные настройки находятся в файле (named.conf.options), отредактируем его:
Код: Выделить всё
sudo vi /etc/bind/named.conf.options
Содержимое файла:
Код: Выделить всё
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
// forwarders {
// 0.0.0.0;
// };
auth-nxdomain no; # conform to RFC1035
listen-on-v6 { any; };
};
Закомментированная секция forwarders, отвечает за то, куда будет передаваться DNS запрос на разрешение имени. Вместо 0.0.0.0, нужно указать альтернативный ДНС сервер. Например 213.180.204.3 — yandex, 8.8.8.8 — google. Если не указывать ничего запрос пойдет по рекурсии с корня.
После редактирования должно быть примерно так:
Код: Выделить всё
forwarders {
213.180.204.3;//yandex
8.8.8.8; //google
};
Сохраняем изменения и выходим (:wq)
Перезапускаем сервер (sudo service bind9 restart) и проверяем:
Код: Выделить всё
# nslookup ya.ru
Non-authoritative answer:
Name: ya.ru
Addresses: 213.180.204.3
В данном случае, сервер не является главным в обслуживании этой зоны (ya.ru).
Cоздадим зону для сети, чтобы сопоставить ip адреса компьютерам и сетевым устройствам.
Зоны описываются в конфигурационном файле: named.conf.local
Код: Выделить всё
sudo vi /etc/bind/named.conf.local
добавим в него секцию:
Код: Выделить всё
zone "home" {
type master;
file "/etc/bind/db.home";
};
Сохраняем изменения и выходим (:wq)
Зону мы обозначили, теперь настроим её:
Код: Выделить всё
sudo vi /etc/bind/db.home или sudo touch /etc/bind/db.home
редактируем до следующего вида:
Код: Выделить всё
@ IN SOA home. root.home. (
20131001 ; релиз зоны, дата
2h ; время обновления 2 часа
2h ; повтор каждый 2 часа
1w ; как долго хранить информацию 1 неделю
1d ) ; время жизни, TTL записи 1 день
@ IN NS name. ; имя сервера имен
@ IN A 192.168.20 ; A - запись - IP адрес нашего ДНС сервера который обслуживает эту зону, @ корневая зона
* IN CNAME @
webserver IN A 192.168.0.25 ; A - запись - IP адрес нашего web сервера в сети
torrentserver IN A 192.168.0.26 ; A - запись - IP адрес нашего torrent сервера в сети
vidserver IN A 192.168.0.27 ; A - запись - IP адрес нашего сервера видеонаблюдения в сети
Также надо внести изменения в файл локального разрешения имен: resolv.conf
Код: Выделить всё
sudo vi /etc/resolv.conf
указать в нем адрес:
Код: Выделить всё
nameserver 127.0.0.1
Сохраняем изменения и выходим (:wq)
перезапускам службу
Код: Выделить всё
sudo service bind9 restart
Теперь разрешением имен в интернете будут заниматься ДНС сервера указанные в секции forwarders.
Проверяем работоспособность:
1. Преобразование внутри сети:
Код: Выделить всё
ping webserver.home
Обмен пакетами с web.home [192.168.0.25] с 32 байтами данных:
Ответ от 192.168.0.25: число байт=32 время=115мс TTL=64
Ответ от 192.168.0.25: число байт=32 время=207мс TTL=64
Ответ от 192.168.0.25: число байт=32 время=86мс TTL=64
Ответ от 192.168.0.25: число байт=32 время=406мс TTL=64
2. Разрешение имен в интернете:
Код: Выделить всё
# nslookup ya.ru
Unknown answer:
Addresses: 192.168.20
Non-authoritative answer:
Name: ya.ru
Addresses: 213.180.204.3
Примечание 1
Ресурсные записи DNS — записи о соответствии имени и служебной информации в системе доменных имён.
В настоящий момент определены следующие типы ресурсных записей (жирным выделены наиболее используемые записи):
Тип |
Расшифровка названия (англ.) |
Код |
Описание |
Употребимость |
RFC |
A |
Address |
1 |
Адресная запись, соответствие между именем и IP-адресом |
одна из самых часто используемых записей |
RFC 1035 |
A6 |
Address version 6 |
38 |
Адрес в формате IPv6 |
заменена на AAAA из-за чрезмерной сложности в реализации, статус |
RFC 3363, RFC 2874 |
AAAA |
A+1+1+1 (A использовался для IPv4, AAAA для IPv6) |
28 |
Адрес в формате IPv6 |
эквивалента А для IPV4 |
RFC 3596 |
AFSDB |
AFS database |
18 |
Расположение базы данных AFS |
редкоупотребимая, чаще используется SRV-запись |
RFC 1183 |
CNAME |
Canonical name |
5 |
Каноническое имя для псевдонима (одноуровневая переадресация) |
широко используется (но имеет ограничения по применению) |
RFC 1035 |
DNAME |
Domain Name |
39 |
Псевдоним для домена |
? |
RFC 2672 |
DNSKEY |
DNS Key record |
48 |
Ключ подписи в DNSSEC. Формат — как в записи KEY. |
DNSSEC |
RFC 4034 |
DS |
Delegation signer |
43 |
Отпечаток (fingerprint) ключа подписи в DNSSEC |
DNSSEC |
RFC 3658 |
GPOS |
Geographical position |
27 |
Географическое положение |
устарела, см LOC |
RFC 1712 |
HINFO |
Host Information |
13 |
Информация об узле |
редкоупотребима |
RFC 1035 |
ISDN |
ISDN address |
20 |
Адрес в формате ISDN |
редкоупотребима (из-за малой популярности сетей ISDN без |
RFC 1183 |
KEY |
Public key |
25 |
Открытый ключ, используется в DNSSEC |
малоупотребима |
RFC 2535, RFC 3445 |
KX |
Key Exchanger |
36 |
? |
? |
RFC 2230 |
LOC |
Location information |
29 |
Географическое местоположение домена |
? |
RFC 1876 |
MB |
Mailbox |
7 |
Почтовый ящик |
редкоупотребима |
RFC 1035 |
MD |
Mail destination |
3 |
Почтовый адрес |
устарела |
RFC 1035 |
MF |
Mail forwarder |
4 |
Перенаправление почты |
устарела |
RFC 1035 |
MG |
Mail group member |
8 |
Номер почтовой группы |
редкоупотребима |
RFC 1035 |
MINFO |
Mailbox or mailing list information |
14 |
Информация о почтовом ящике или рассылке |
? |
RFC 1035 |
MR |
Mail rename domain name |
9 |
? |
редкоупотребима |
RFC 1035 |
MX |
Mail Exchanger |
15 |
Адрес почтового шлюза для домена. Состоит из двух частей — приоритета |
критически важна для SMTP-протокола, основа маршрутизации почты в |
RFC 1035 |
NAPTR |
Naming authority pointer |
35 |
Указатель на авторитетный узел именования (используется для IP-телефонии) |
малоупотребима |
RFC 3263, RFC 3403 |
NULL |
Null record |
10 |
Пустая запись |
редкоупотребима |
RFC 1035 |
NS |
Authoritative name server |
2 |
Адрес узла, отвечающего за доменную зону. Критически важна для |
DNS |
RFC 1035 |
NSAP |
Network service access point address |
22 |
Указатели в стиле OSI |
редкоупотребима |
RFC 1706 |
NSAP-PTR |
NSAP pointer |
23 |
Указатель на NSAP |
устарела |
RFC 1348 |
NSEC |
Next-Secure record |
47 |
Часть DNSSEC, подтверждает отсутствие записи. Формат — как у NXT. |
DNSSEC |
RFC 4034 |
NSEC3 |
Next-Secure record |
50 |
Расширение DNSSEC, подтверждающее отсутствие записи без возможности |
? |
RFC 5155 |
NSEC3PARAM |
NSEC3 parameters |
51 |
Запись с параметрами для NSEC3. |
DNSSEC |
RFC 5155 |
NXT |
Next domain |
30 |
Указатель на следующий домен подписанной зоны |
устарела DNSSEC |
RFC 2065 |
PTR |
point to reverse |
12 |
PTR запись прописывается в reverse зоне провайдера, владеющего этим IP, |
широко используется для IPv4-адресов в домене in-addr.arpa, для IPv6 — в |
RFC 1035 |
PX |
Pointer to X.400 |
? |
Указатель на систему маршрутизации почты X.400 |
X.400 |
RFC 822, RFC 2163 |
RP |
Responsible person |
17 |
Ответственный |
? |
RFC 1183 |
RRSIG |
DNSSEC signature |
46 |
Подпись записи средствами DNSSEC. Формат — как у SIG. |
DNSSEC |
RFC 4034 |
RT |
Route through |
21 |
Указание на узел, через который следует осуществлять маршрутизацию |
малоупотребима |
RFC 1183 |
SIG |
Cryptographic public key signature |
24 |
Сигнатура публичной подписи |
малоупотребима |
RFC 2931 |
SOA |
Start of authority |
6 |
Указание на авторитетность информации, используется для указания на новую |
DNS |
RFC 1035 |
SPF |
Sender Policy Framework |
99 |
Указывает сервера, которые могут отправлять почту с данного домена |
Должна была использоваться для spf-записи, которая размещается в TXT, |
RFC 7208 |
SRV |
Server selection |
33 |
Указание на местоположение серверов для сервисов |
Jabber, Active Directory |
RFC 2782 |
SSHFP |
SSH Fingerprints |
44 |
Отпечаток ключа SSH |
малоупотребима |
RFC 4255 |
TKEY |
Transaction key |
249 |
Метод распространения ключей для TSIG-записей |
? |
RFC 2930 |
TLSA |
Certificate association |
52 |
Ресурсная запись DANE |
? |
RFC 6698 |
TSIG |
Transaction signature |
250 |
Идентификация для DNS-операций с использованием общих секретных ключей и |
при передаче зон между DNS-серверами |
RFC 2845 |
TXT |
Text string |
16 |
Запись произвольных двоичных данных, до 255 байт в размере |
Sender Policy Framework, DNS-туннели и прочее |
RFC 1035 |
WKS |
Well-known service |
11 |
Список доступных общеизвестных сервисов (общеизвестные — с |
? RFC 1035 |
RFC 1035 |
X25 |
PSDN address |
19 |
Адрес в формате X.25 |
редкоупотребима |
RFC 1183 |
Примечание 2
Bind9 — isc_stdio_open ‘/var/log/bind/misc.log’ failed: permission denied
При настройке сервиса bind на Ubuntu 16.04 столкнулся с ошибкой:
isc_stdio_open '/var/log/bind/misc.log' failed: permission denied
Проблема кроется в усиленной защите AppArmor. Для исправления разрешаем запись в файл лога. В файле:
/etc/apparmor.d/usr.sbin.named
вносим изменения:
Код: Выделить всё
/var/log/dns/** rw,
Другой вариант отключаем AppArmor:
sudo systemctl stop apparmor
sudo systemctl disable apparmor
Примечание 3
Настройка логирования
logging {
channel general {
file "/var/log/named/general.log" versions 3 size 1m;
print-category yes;
print-time yes;
print-severity yes;
};
channel mydebug {
file "/var/log/named/debug.log" versions 3 size 1m;
severity debug 10;
print-category yes;
print-time yes;
print-severity yes;
};
channel dnssec {
file "/var/log/named/dnssec.log" versions 3 size 1m;
severity debug 10;
print-category yes;
print-time yes;
print-severity yes;
};
channel database {
file "/var/log/named/db.log" versions 3 size 1m;
severity error;
print-category yes;
print-time yes;
print-severity yes;
};
channel dispatch {
file "/var/log/named/dispatch.log" versions 3 size 1m;
severity debug 10;
print-category yes;
print-time yes;
print-severity yes;
};
channel error {
file "/var/log/named/error.log" versions 3 size 10m;
severity info;
print-category yes;
print-time yes;
print-severity yes;
};
channel security {
file "/var/log/named/security.log" versions 3 size 1m;
severity notice;
print-severity yes;
print-time yes;
};
channel config {
file "/var/log/named/config.log" versions 3 size 1m;
severity notice;
print-severity yes;
print-time yes;
};
channel resolver {
file "/var/log/named/resolver.log" versions 3 size 1m;
severity notice;
print-severity yes;
print-time yes;
};
channel client {
file "/var/log/named/client.log" versions 3 size 1m;
severity notice;
print-severity yes;
print-time yes;
};
channel misc {
file "/var/log/named/misc.log" versions 3 size 1m;
print-time yes;
};
channel zones {
file "/var/log/named/zones.log" versions 3 size 1m;
print-time yes;
};
channel xfer {
file "/var/log/named/xfer.log" versions 3 size 1m;
print-severity yes;
print-time yes;
};
channel network {
file "/var/log/named/network.log" versions 3 size 1m;
print-severity yes;
print-time yes;
};
channel update {
file "/var/log/named/update.log" versions 3 size 1m;
print-severity yes;
print-time yes;
};
channel zoneload {
file "/var/log/named/zoneload.log" versions 3 size 1m;
print-severity yes;
print-time yes;
};
channel query {
file "/var/log/named/query.log" versions 3 size 1m;
print-severity yes;
print-time yes;
severity debug 10;
};
channel rpz {
file "/var/log/named/rpz.log" versions 3 size 1m;
print-severity yes;
print-time yes;
};
category client { client; };
category cname { resolver; };
category config { config; };
category database { database; };
category default { general; };
category delegation-only { resolver; };
category dispatch { dispatch; };
category dnssec { dnssec; };
// category dnstap { mydebug; };
category edns-disabled { resolver; };
category general { general; };
category lame-servers { misc; };
category network { network; };
category notify { zones; };
category nsid { resolver; };
category queries { query; mydebug; };
category query-errors { query; mydebug; error; };
category rate-limit { database; };
category resolver { resolver; mydebug; };
category rpz { resolver; };
category security { security; };
category serve-stale { resolver; mydebug; error; };
category spill { database; mydebug; error; };
// category trust-anchor-telemetry { mydebug; };
category unmatched { mydebug; };
category update { update; };
category update-security { security; };
category xfer-in { xfer; };
category xfer-out { xfer; };
category zoneload { zoneload; };
category default { default_syslog; mydebug; };
};