DNS сервер BIND (теория)

настройка DNS сервера на LinuxДоброго времени, уважаемые читатели. Сегодня в блоге хочу рассмотреть работу Domain Name System – сервера на Linux. Разбираясь с работой SAMBA попытался поднять свой полноценный контроллер домена Active Directory и понял, что не хватает знаний до полноценного понимания DNS. Итак, основная цель DNS – это отображение доменных имен в IP адреса и наоборот – IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.

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

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

Domain Name SystemДоменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. “Вершиной” доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же  отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.

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

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

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

Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе – слэш, а в DNS точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал – всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.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.             TTL   CLASS      TYPE       DATA
  • имя (NAME) — доменное имя, к которому привязана или которому «принадлежит» данная ресурсная запись, либо IP адрес. При отсутствии данного поля, запись ресурса наследуется от предыдущей записи.
  • Time To Live (TTL) — дословно “время жизни” записи, время хранения записи в кэше DNS (после указанного времени запись удаляется), данное поле может не указываться в индивидуальных записях ресурсов, но тогда оно должно быть указано в начале файла зоны и будет наследоваться всеми записями.
  • класс (CLASS) – определяет тип сети, (в 99,99% случаях используется IN (что обозначает – Internet). Данное поле было создано из предположения, что DNS может работать и в других типах сетей, кроме TCP/IP)
  • тип (TYPE) — тип записи синтаксис и назначение записи
  • данные (DATA) – различная информация, формат и синтаксис которой определяется типом.

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

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

Со всем набором ресурсных записей можно ознакомиться в wikipedia. Наиболее часто применяемые ресурсные записи следующими (далее, мы обязательно рассмотрим их на практике):

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

    зону k-max.name обслуживают:

       k-max.name.             1577    IN      NS      ns2.jino.ru.
     k-max.name.             1577    IN      NS      ns1.jino.ru.
  • PTR (pointer) – отображает IP-адрес в доменное имя (о данном типе записи поговорим ниже в разделе обратного преобразования имен).
  • SOA (Start of Authority/начальная запись зоны) – описывает основные/начальные настройки зоны, можно сказать, определяет зону ответственности данного сервера. Для каждой зоны должна существовать только одна запись SOA и она должна быть первая (дополнение: Первой она быть не обязана. Во-всяком случае, файл, в котором она не первая, прекрасно проходит проверку. Однако, все значения, указанные в SOA-записи, применяются только к тем записям, что следуют ниже нее. Т.е. практического смысла делать ее не первой нет. Тоже самое касается и директивы $TTL (полагаю, что и $ORIGIN, хотя и не проверял). (с)). Поле 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. Ранее, в статьях о сети в Linux я упоминал о nsswitch. Вот фрагмент файла, который нас интересует:

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

В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.

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

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

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

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

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

порядок прохождения DNS запросовДавайте разберем, что тут нарисовано по шагам:

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

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

Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.

До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.

Ответы DNS сервера

Ответы DNS бывают следующего типа:

  1. Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
  2. Неавторитативный ответ (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.  имя главного DNS (Primary Name Server)        345565  IN      A       213.180.193.1
ns1.yandex.ru.          3565    IN      AAAA    2a0ua.em2:6emb8::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

Обратное преобразование имен

структура домена in-addr.arpa.DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле TypePTR, а в поле DataFQDN-имя соответствующее данному 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 www.ru.
...
;; QUESTION SECTION:
;www.ru.                                IN      A

;; ANSWER SECTION:
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     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., которая в свою очередь указывает на домен www.ru..  Хочется отметить, что чаще всего за обратную зону и ее редактирование отвечает поставщик интернета.

Как и обещал, описываю ресурсную запись PTR в домене IN-ADDR.ARPA, соответствующая приведенной выше записи А для машины 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., то запись можно представить так:

50 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, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.

Что еще почитать:

man (5) resolver: http://www.opennet.ru/man.shtml?topic=resolver&category=5&russian=0
man (3) gethostbyname:  http://www.opennet.ru/cgi-bin/opennet/man.cgi?topic=gethostbyname&category=3
Linux Network Administrators Guide v2 Russian: скачать.
RFC882, 1035, 1183
Статья DNS сервер bind – практика

Upd 2013.01.28: обновил информацию по SOA-записи (спасибо комментатору feedbee на хабре)

С Уважением, Mc.Sim!


Другие материалы в категории DNS


Теги: , , , , ,

56 комментариев к “DNS сервер BIND (теория)”

  1. 18 июля, 2011 at 01:56
    1

    Как всегда Ваши статьи бесподобны! Качественно, подробно, хорошо оформлено. Очень приятно читать. Правда неделю всЁ не могу собраться с мыслями и полностью прочитать статьи про DNS, потому что объЁм материала очень большой.
    Продолжайте в том же духе! =)

    • 18 июля, 2011 at 12:10
      2

      Спасибо. Да, статьи получились громоздкими, но содержательными! :)

  2. 18 июля, 2011 at 23:40
    3

    Не громоздкими, а объЁмными. Но это ни разу не недостаток. По себе знаю, как не получается разорвать статью на части, несмотря на то, что объЁм не маленький получается.

  3. Сергей
    24 января, 2012 at 00:00
    4

    Спасибо огромное за статью. Вдохновляет. С Вашей помощью успешно поднял свой первый DNS сервер. Ура!

    • 24 января, 2012 at 09:16
      5

      Пожалуйста! Приходите еще!

  4. 25 января, 2012 at 16:11
    6

    Круто! Молодец!!

    • 26 января, 2012 at 16:53
      7

      Спасибо. приходите еще!

  5. Shurr
    4 февраля, 2012 at 10:24
    8

    вопрос .
    Домен IN-ADDR.ARPA где находится? Куда идет запрос
    “50.0.87.194.in-addr.arpa. IN PTR” ?
    как поддерживается актуальность базы записей домена IN-ADDR.ARPA и “чаще всего за обратную зону и ее редактирование отвечает поставщик интернета.” ?
    спасибо.

    • 4 февраля, 2012 at 15:48
      9

      Про обратное преобразование имен написано выше в разделе “Обратное преобразование имен“. Домен arpa. точно такой же как и домен ru., как домен com. и др., соответственно in-addr.arpa. и ip6.arpa. аналогичны доменам ru.org., ua.com. и другим. Поддерживается он той же конторой IANA. За тем лишь исключением, что поддомены домена in-addr.arpa. в большинстве своем принадлежат провайдерам (например Вымпелком, Ростелеком и др.), хостинговым компаниям и дата-центрам, они и вносят в эти зоны правки. То есть провайдер держит за собой тот поддомен, подсети которого ему принадлежат.

      • Shurr
        5 февраля, 2012 at 15:14
        10

        То есть при получении блока IP адресов, провайдер обязан сообщать владельцу домена in-addr.arpa. ns-сервера своих поддоменов?

        да и там наверно опечатка? вместо “80 IN PTR http://www.ru.” “50 IN PTR http://www.ru. ” поставить?

        • 5 февраля, 2012 at 20:36
          11

          То есть при получении блока IP адресов, провайдер обязан сообщать владельцу домена in-addr.arpa. ns-сервера своих поддоменов?

          все верно.

          да и там наверно опечатка? вместо «80 IN PTR http://www.ru.» «50 IN PTR http://www.ru. » поставить?

          спасибо за замечание – поправил.

  6. evtuserg
    29 февраля, 2012 at 01:36
    12

    Спасибо, отличная статья! Если будет желание и возможность, опишите пожалуйста настройку ftp-сервера под linux, буду признателен. Продолжайте в том же духе =)

    • 29 февраля, 2012 at 10:14
      13

      Пожалуйста. Приходите еще!
      Про фтп учту, но пока другие приоритеты – со squid разбираюсь.

  7. Vlad
    15 марта, 2012 at 13:31
    14

    Очень все четно и грамотно. респект)

  8. лолка
    18 апреля, 2012 at 17:55
    15

    Информативный блог у вас, хорошо материал подносите. *THUMBS UP*

    • 18 апреля, 2012 at 18:07
      16

      спасибо

  9. bosyak
    9 мая, 2012 at 12:35
    17

    А можно ли создать такой НС сервер который бы на любой запрос отдавал бы определеный IP адрес? Эдакий универсальный нс сервер?

    • 9 мая, 2012 at 20:21
      18

      попробуй поискать статьи с ключевыми словами wildcard dns

  10. Павел
    7 июня, 2012 at 00:43
    19

    Статья просто великолепна! Очень доступно, чётко и ясно! Спасибо большое, Mc.Sim.

    Но всё равно кое что я не понял. Практика:
    1. Купил я домен mydomain.ru
    2. Делегировал его у регистратора (если не ошибусь, то делегировать его на домашнем сервере не получится не имея второго NS(DNS) сервера) так?
    4. AD в Win2008 предлагает заполнить доменное имя в формате FDQN (ad.mydomain.ru). Он поднимает DNS и он будет управлять зоной ad.mydomain.ru или нет и зачем это нужно если есть NS сервера регистратора? Или просто я должен у регистратора создать запись SRV или A?
    5. Я поднимаю сайт на IIS на том же сервере, указываю адрес mydomain.ru мне надо у регистратора указать запись типа А со своим IP. Так?
    6. Настраиваем Exchange Server, ему так же требуется домен в формате FDQN. К примеру mail.mydomain.ru. В данном случае я должен у регистратора указать 2 записи, MX с указанием IP моего почтового сервера и CNAME mail.mydomain.ru для доступа к WEB-интерфейсу почты? А если Exchange Server находится на другом сервере, а не на том же где сайт mydomain.ru, то я должен указать запись типа mail А [ip адрес сервера Exchange]?
    Теорию хорошо закреплять практикой. Очень буду благодарен за ответ.

    • 7 июня, 2012 at 23:25
      20

      если не ошибусь, то делегировать его на домашнем сервере не получится не имея второго NS(DNS) сервера) так?

      Теоретически. это возможно, но при смене IP – делегирование перестанет работать.

      AD в Win2008 предлагает заполнить доменное имя в формате FDQN (ad.mydomain.ru).

      на самом деле, использовать внешний домен в локальной сети в AD я бы не стал.

      Он поднимает DNS и он будет управлять зоной ad.mydomain.ru или нет и зачем это нужно если есть NS сервера регистратора?

      В данном случае, при создании AD и сопутствующего локального DNS сервера, о создаваемом локальном DNS, вышестоящий DNS (у регистратора) не имеет никакого понятия о существовании поддомена ad.mydomain.ru .
      В результате, DNS в локальной сети будет работать так:
      Пользователи в локальной сети будут корректно обрабатывать все адреса из домена mydomain.ru, потому что локальный DNS не зная ничего о домене mydomain.ru будет обращаться к корневым NS серверам. На все запросы о записях в домене ad.mydomain.ru будет отвечать локальный DNS.
      DNS “снаружи” будет работать так:
      Пользователи из интернета при обращении к домену mydomain.ru, будут получать ответы от внешних DNS серверов, но ничего не будут знать о зоне ad.mydomain.ru.

      Или просто я должен у регистратора создать запись SRV или A?

      Размещать на внешних NS серверах SRV записи из AD – это, имхо, тоже некорректно и небезопасно.

      Я поднимаю сайт на IIS на том же сервере, указываю адрес mydomain.ru мне надо у регистратора указать запись типа А со своим IP. Так?

      примерно так. Точнее будет звучать так: IIS сервер должен иметь внешний IP в интернет и A-запись должна указывать на этот IP. Если IIS в локальной сети и к интернету подключен через маршрутизатор, то A-запись должна указывать на внешний IP маршрутизатора, а на маршрутизаторе, в свою очередь, должны быть проброшены соответствующие порты (80,443 и т.п.)

      6. Настраиваем Exchange Server, ему так же требуется домен в формате FDQN. К примеру mail.mydomain.ru. В данном случае я должен у регистратора указать 2 записи, MX с указанием IP моего почтового сервера и CNAME mail.mydomain.ru для доступа к WEB-интерфейсу почты? А если Exchange Server находится на другом сервере, а не на том же где сайт mydomain.ru, то я должен указать запись типа mail А [ip адрес сервера Exchange]?

      примерно так, но точнее будет так: MX должна указывать не на IP, а на имя. Соответственно, нужно иметь A-запись с указанием на IP с установленным Exchange Server, а MX – указывающую на соответствующую запись, пример:
      @ IN MX 5 smtp.mydomain.ru.
      smtp IN A 1.2.3.4

      это для работы SMTP, для доступа к Веб-интерфейсу по адресу mail.mydomain.ru можно создать CNAME вида:
      mail IN CNAME smtp.mydomain.ru.

      Вроде бы я ничего не перепутал…

  11. Павел
    8 июня, 2012 at 09:57
    21

    Спасибо большое за такой развёрнутый ответ!

    • 8 июня, 2012 at 10:54
      22

      Пожалуйста. Приходите еще )

  12. Леонид Гордеевич
    22 октября, 2012 at 17:23
    23

    Подобные произведения (шедевры) я люблю хранить у себя локально для того чтобы можно было почитать тогда когда уже или еще нета нет или в тиши внимательно и рассуждая. При этом все что мешает на экране – лишнее. И было бы очень полезно чтобы там где есть Ваши статьи была возможность сохранить вариант для печати а сюда идти для того чтобы задать вопрос. Или у Вас может быть есть ftpшка откуда можно скачать все в красивом виде. Я не лентяй но…
    А вообще выше все уже сказано. Спасибо!

    • 23 октября, 2012 at 22:30
      24

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

  13. Павел
    16 декабря, 2012 at 20:27
    25

    Можете подсказать как оформить ns сервера и создать локальный сервер?
    1. Есть доменое имя.
    3. Есть 1 статический ip.
    4. Провайдер разрешает свободно редактировать свою PTR запись.
    5. Есть домашний сервер на WinServ 2012.
    6. Есть аккаунт на сервисе который предоставляет secondary NS.

    Как все настроить и что у регистратора указать как ns для домена, что бы мой домашний сервер отвечал за мой домен?

    • 19 декабря, 2012 at 17:59
      26

      Доброго времени, Павел.
      В целом, схема такая:
      1. Поднимаете мастер DNS у себя.
      2. Синхронизируете мастер DNS с secondary NS.
      3. Указываете у регистратора доменного имени IP адреса мастер и secondary NS.
      4. по желанию – редактируете обратную запись.
      5. работаете.

      В данной схеме могу прогнозировать следующее:
      На втором шаге secondary NS потребует от вашего мастер DNS каких-либо нереальных требований.
      На третьем шаге регистратор начнет проверять корректность настройки NS серверов и скажет, что ваш IP на мастер сервере принадлежит неудобной ему подсети или что-то вроде того )

      В целом, если домен будет использоваться для веб-сервера, то я бы не стал заморачиватсья с поднятием своего NS сервера. У любого веб-хостера услуга DNS бесплатна. Ну на крайний случай, можно воспользоваться NS серверами яндекса, которые так же бесплатны – pdd.yandex.ru.
      Как-то так.

  14. Павел
    20 декабря, 2012 at 00:03
    27

    Спасибо большое.
    Я это так, для лаб. Нужно же как то учится. Вот гипервизор дома поставил на “сервачек” и изучаю.:)
    PS очень буду благодарен инвайту на хабр, если сможете выписать (видел там вашу статью о DNS). Сам я адекватен, но до статей не дорос, а вот вопрос по теме иногда там очень хочется задать, а нельзя.:(

    • 20 декабря, 2012 at 13:30
      28

      Я сам не имею доступа к хабру. Мой пост разместил копипастер.

  15. snake
    27 декабря, 2012 at 10:40
    29

    Статья замечательная, но помогите с практикой немного :)
    Я совсем запутался :( Как работает вся эта махина, понятно, но пытаешься что то реализовать на практике…. :(
    1. есть внешний IP, на нем крутится apache
    2. у хостера зарегистрирован домен и на его ns сервере прописан мой ip
    если я хочу сделать виртуальный домен третьего уровня. Например new.mydomen.ru размещенный на том же IP что и mydomen.ru
    Apache я настроил и он его понимает.
    Подскажите, как мне прописать его на ns сервере провайдера?

    • 27 декабря, 2012 at 20:06
      30

      ну просто создаете А-запись на тот же IP, но на имя new.mydomen.ru

  16. bigferumdron
    12 марта, 2013 at 18:02
    31

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

    На данный момент я представляю себе схему взаимодействия так:

    1. Вводим адрес сайта k-max.name в адресную строку браузера на своем компе и нажимаем Enter.
    2. Браузер через специльную программу resolver посылает запрос об IP адресе домена к DNS-серверу интернет-провайдера.
    3. Этот сервер о данном IP-адресе ничего не знает и посылает запрос одному из корневых серверов “.”
    4. Корневой сервер тоже не знает ничего о домене, но знает айпишник днс-сервера отвечающего за зону .name , и отдает его серверу интернет провайдера.
    5. Далее днс сервер провайдера посылает запрос на DNS сверер отвечающий за зону .name . Тот тоже не знает айпишника домена, но знают днс, которые знают айпишник . Возращают их в ответ на запрос.
    6. Наконец днс сервер провайдера обращается уже к полученным на предыдущем шаге ДНС, и получают IP сайта k-max.name

    Вопросы:

    1. В целом ДНС сервер это программа, приложение, или целый копьютер?
    2.Откуда местный днс сервер знает адреса корневых серверов? т.е. они как-то жестко прописаны ? если да, то так на каждом компе, или только на днс серверах?
    3.Понимаю,что выбор к какому из корневых серверов послать запрос, он делает на основании времени отклика. Но не понимаю, откуда он его узнает,
    ведь для этого нужно сперва послать какие-то проверочные запросы ко всем 13 серверам, и получить ответ, и уже на основании ответа определить какой из них наиболее быстрый..?….

    4. Domain Name System это ведь распределенная база данных о соответсвтии ip и доменов. С корневыми серверами и TOp Domain Levels все вроде понятно. А дальше как-то не особо.. КОгда регим домен, до
    прописываем ДНС сервера хостера. ЭТо что получается, что у каждого хостера есть еще свой дополнительный дНС сервер, который хранит данные лишь о доменах , зарегеных под этим регистратором?

    5. Как происходит когда несколько сайтов на одном айпи.. В общих чертах. Т,е. в моей схеме в 6 пункте в итогде браузер получает Айпишник сайта, а обстоят дела когда сайтов несколько на одном ip?
    понимаю что это делается через виртуальные хосты на сервере, но вот как об этом узнает браузер? наверное он получает в ответ не просто айпи а еще доп. информацию какую-то?

    НАдеюсь на вашу помощь…

    • 16 марта, 2013 at 15:57
      32

      bigferumdron, приветствую.
      Попробую прояснить ситуацию на сколько это возможно…

      На данный момент я представляю себе схему взаимодействия так:

      Некоторые правки:
      1. …
      2. Тут я бы сказал, что resolver посылает запрос к тем DNS серверам, которые прописаны в сетевых настройках (это не обязательно провайдерские DNS)

      Вопросы:

      1. DNS – сервер – это служба (читай- программа, работающая в фоновом режиме). Под работу этой программы может быть выделен отдельный компьютер. В таком случае это уже будет целый компьютер. )
      2. Существует сайт отвечающий за информацию о корневых серверах. Кроме того, имеется актуально обновляющийся файл, содержащий непосредственно адреса корневых серверов. ДНС сервер (по крайней мере bind) хранит локальную копию данного файла и обновляет его обычно с помощью обновлений операционной системы. Более подробно можно с этим ознакомиться, почитав практику.
      3. Все верно, последовательно перебирая посылая запросы на корневые сервера, DNS сервер формирует некоторую статистику, в соответствии с которой и выбирает лучший сервер.
      4. Указывая у регистратора IP адреса DNS серверов мы тем самым осуществляем делегирование зоны.

      ЭТо что получается, что у каждого хостера есть еще свой дополнительный дНС сервер, который хранит данные лишь о доменах , зарегеных под этим регистратором?

      В целом верно, но я бы перефоразировал так: у каждого хостера есть еще свой дополнительный дНС сервер, который хранит данные лишь о доменах , зарегеных делегированных неким под этим регистратором.
      5. Это уже не работа DNS протокола, это работа HTTP протокола, то есть Веб-сервера и веб-клиента (браузера). Когда на одном IP несколько сайтов, то браузер посылает на этот IP – HTTP запрос (он же HTTP заголовок). В этом запросе содержится информация о запрашиваемого сайта. Обычно, эта информация содержится в поле Host:.
      Как-то так.
      Надеюсь, что стало более понятно.

  17. Дядька
    8 апреля, 2013 at 09:23
    33

    Здравствуйте, Mc.Sim
    Хотел бы посоветоваться как возможно улучшить работу.. несколько “неправильной” конфигурации bind-а..
    По ряду причин есть необходимость обслуживать рекурсивные запросы из инета перенаправляя их на другой сервер в локальной сети. Запросы для “всего”, а не для определенной зоны (собсно, потому и – неправильная)
    Возможно, даже “улучшать” нужно на уровне айпи стека, а возможно и средствами бинд-а, ибо опций там масса..
    Собсно, требуется, чтобы второй сервер, получивший рекурсивный запрос, отдал результат первому только о своей зоне, а все остальные запросы – игнорировать (дропать, или что он там еще умеет..)
    Сейчас этот “второй” сервер пытается разрезолвить всё, что приходит из инета, в результате чего дико лагает вся локалка…
    На “первом” сервере тупо прописан адрес второго сервера в опции forwarders перед описанием рут-зон..
    Посоветуйте, плз, что можно сделать на 1-м или 2-ом сервере..?? (на первом я бы не хотел ничего “говорить” о существовании интересующей меня зоне, которая обслуживается на втором)

    Заранее спасибо.

    • 9 апреля, 2013 at 16:02
      34

      Здравствуйте,
      Мало, что понял…
      Противоречивая информация:
      “Запросы для «всего», а не для определенной зоны (собсно, потому и — неправильная)”
      при этом, вам необходимо, чтобы “второй” сервер (на который эти запросы перенаправляются)
      “отдал результат первому только о своей зоне, а все остальные запросы — игнорировать”
      Почему бы сразу на первом сервере их не дропать?
      Почему бы не завести зону сразу на первом сервере, а остальное – игнорировать.

    • 9 апреля, 2013 at 16:11
      35

      думаю, что будет проще объяснить что и как, если более полно опишите конечную задачу…

  18. Дядька
    21 мая, 2013 at 07:24
    36

    Здравствуйте, Mc.Sim
    Конечная задача – исключить какое-либо упоминание на первом серваке про мою зону, ибо доступ к нему у всех (ну не у всех, а у “кого надо” ;) )
    Знаю, что “правильности” можно легко достичь, прописав зону на первом..
    Ну вот какие-то такие.. тараканы.. *CRAZY*

    Почему бы сразу на первом сервере их не дропать?

    Было бы интересно, как это сделать.. Короче, на первом можно делать всё, без упоминании о моем домене, а на втором – вообще “всё”..

    • 27 мая, 2013 at 11:36
      37

      Доброго времени, Дядька
      Попробуйте на втором сервере в разделе
      options {
      #задать
      recursion no;
      fetch-glue no;
      };

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

  19. Дядька
    10 июня, 2013 at 14:40
    38

    Mc.Sim, спасибо, вроде чуть полегчало..
    а можно ли на уровне айпи еще ченить потюнить?
    есть смысл отслеживать состояние соединений “длинных” запросов по тцп на 53-й порт?

    • 12 июня, 2013 at 20:22
      39

      а можно ли на уровне айпи еще ченить потюнить?
      есть смысл отслеживать состояние соединений «длинных» запросов по тцп на 53-й порт?

      netfilter и iptables вам в помощь )
      Какие-то рекомендации дать трудно, кроме общих

  20. Turok
    24 июня, 2013 at 12:28
    40

    Добрый день!
    Подскажите,пожалуйста, в каком направлении рыть.
    В одной локальной сети есть сервер(windows7) на нём DHCP Turbo, Bind9 и сайт.
    Вот как сделать так, чтобы при вводе ЛЮБОГО адреса в адресную строку браузера открывался тот сайт на сервере?
    Например, как у мегафона, когда закачиваются деньги на счёту, при попытке отрыть какой либо сайт происходит редирект на сайт мегафона.

    • 24 июня, 2013 at 13:10
      41

      Добрый день, Turok
      Если я правильно понял задачу, то DNS тут не причем.
      Вам нужно искать решение похожее на Cut-through Proxy. Например

      • Turok
        24 июня, 2013 at 20:42
        42

        Cut-through Proxy, ну это совсем круто для меня. Там, наверное, несколько проф сисадминов настраивали эту штуку, а я в этом деле…..

        С помощью DNS как эта проблема и решается, только я зря про редирект написал. Сейчас я прикинул и сделал две зоны ru и com, на который в основном заходят, вот с таким описанием
        $TTL 1
        ru. SOA ru. http://www.ru. 43 1 1 1 1
        ; Serial, Refresh, Retry, Expire, Neg. cache TTL

        NS 192.168.0.3.

        A 192.168.0.3
        * CNAME @

        и теперь при любом домене в зоне ru или com открывается один тот же сайт!

        Теперь новая задача появилась!:-)
        Я где-то видел, что при подключение к точке доступа wi-fi с интернетом в винде вылетает окошечко(с каким-то описанием), при клике на него открывается стартовая страница провайдера.
        Вот хочу так же!)
        С этим я даже приблизительно не знаю куда лезть, даже не знаю, что в поисковик написать)

        • 25 июня, 2013 at 12:03
          43

          * CNAME @

          при данной конфигурации, пользователи вообще никогда никуда не попадут в зоне ru. Если нужно именно это, то вполне себе решение )
          По поводу WiFi: если нужен какой-то аналог хотспота с аутентификацией по разовып паролям, то ищите по словам captive portal.
          Навскидку, несколько готовых решений: PfSense, Zentyal, m0n0wall

          • Turok
            26 июня, 2013 at 19:24
            44

            Спасибо! Будем думать =)

  21. Васька
    1 июля, 2013 at 22:30
    45

    Привет все!

    Есть файлы обратных зон, около 100 шт., подобного содержания:
    $ORIGIN 0.168.192.in-addr.arpa.
    ; Практически в каждой зоне есть несколько (5-10) записей отличных от «local.»
    ; Хочется сделать красиво и сократить всё при помощи $GENERATE
    $GENERATE 0-255 $ PTR $-0-168-192.local.
    ; Этот паршивец выбивается :(
    100 PTR example.com.

    При просмотре получаю две записи (крутятся по round-robin)

    # dig -x 192.168.128.100
    100.0.168.192.in-addr.arpa. 86400 IN PTR 100-0-168-192.local.
    100.0.168.192.in-addr.arpa. 86400 IN PTR example.com.

    “Задвоение” PTR это нормально? Может ли это помешать, к примеру, почтовику?
    Спсб.

    • 15 июля, 2013 at 23:22
      46

      Приветствую,
      С точки зрения DNS в дублировании записи нивижу ничего криминального, даже rfc использует такие примеры.
      А вот с точки зрения почтового сервера – не уверен, что это корректно. хотя, если это сервер локальной сети, то это зависит лишь от настроек Вашего сервера. ИМХО.

  22. g49144
    6 августа, 2013 at 17:48
    47

    откуда bind знает ip корневого домена

    • 16 августа, 2013 at 14:37
      48

      bind берет адреса из локальной копии файла. Которую получает либо вручную силами администратора, либо с помощью системных апдейтов. Этот вопрос я рассматривал в практической статье. Рекомендую.

  23. current_user
    14 октября, 2014 at 11:50
    49

    Спасибо за статью ! было очень интересно читать , я бы хотел уточнить у Вас кое что

    После прочтения данных статей решил поднять кэширующий dns сервер который бы обслуживал пару локальных зон

    вот конфиг зоны

    $ORIGIN lan.
    $TTL 1D;
    @ IN SOA ns1.test.lan. test.tes.lan. (
    14102014 ; serial
    10H ; refresh (8 hours)
    2H ; retry (1 hours)
    1W ; expire (2 weeks)
    1D ; minimum (1 day)
    )
    @ IN NS localhost.
    @ IN A 10.10.10.156
    log IN A 10.10.10.156
    wiki IN A 10.10.10.156
    nav IN A 10.10.10.156

    теперь подумываю купить домен предположим comcom.ru имея реальный ip допустим 46.8.130.40

    что бы данный сайт обслуживался на моем сервере и был доступен из интернета по имени мне нужно будет попросить регистратор где буду покупать имя добавить у себя на ns сервере запись вида

    comcom.ru IN A 46.8.130.40 ?

    • 18 декабря, 2014 at 00:17
      50

      Обычно, регистраторы требуют как минимум 2 DNS сервера, к которым предъявляются довольно суровые проверки (например от nic).
      Для домашнего пользователя это получается довольно накладно.
      Проще оплатить соответствующую услугу.
      Но если же вы все требования регистратора учтете, то вам нужно регистратора попросить сделать запись NS, а не А, как в вашем примере. То есть так:
      comcom.ru IN NS 46.8.130.40

  24. 24 июня, 2015 at 11:08
    51

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

    • 10 октября, 2015 at 13:00
      52

      Спасибо за пояснение.
      Это явным текстом не указано в статье, но в общем-то после полного прочтения и наличия некой практики такой вывод можно сделать )

  25. Дмитрий
    4 сентября, 2016 at 21:34
    53

    Спасибо большое за труд! *THUMBS UP* Статья очень интересная и познавательная. Нравится, что Вы объясняете людям многие тонкости работы, что, несомненно, улучшает понимание пока сложных вещей. Успехов Вам во всем! =)

  26. komronit
    23 мая, 2017 at 14:23
    54

    Привет! Профессионалы! У меня к вам вопрос.. как можно выделить определённый объём трафика например, 500МБ каждому пользователю в день? чтобы после окончание этого квота пользователь больше не смог выйти в интернет. Желательно на squid+sarg или другая?

  27. 4 февраля, 2021 at 10:41
    56

    Хочу похвалить автора статьи за его труд. Как раз изучаю DNS для организации bind на работе. Огромное спасибо за качественный и понятный материал.

Написать комментарий