Soa начальная запись зоны root example com

См. upward referrals debates
https://www.dns-oarc.net/oarc/articles/upward-referrals-considered-harmful

Проверяет конфиг сервера имен

named-checkconf

Перезагружает конфиг и зоны

rndc reload

Перезагружает только изменившиеся зоны

rndc reconfig

service bind9 start

rndc status

rndc flush

Конфигурация и файлы зон по-умолчанию лежат в /etc/bind/

acl network1 { 1.2.3.0/24; 192.168.0.0/20;
};
acl GoodDns { 1.2.3.4;
};

Ограничение на трансфер зон и запросы

 allow-transfer { localhost; GoodDns; }; allow-query { any; };

Настройка зоны и подключение файла зоны

zone "example.com" { type master; file "/etc/bind/db.example.com."; allow-query { any; };
};

Иногда для каких-либо проектов необходимо обеспечить работу серверов имен на своем VDS, используя минимальный вариант операционной системы. В этой статье рассказано, как настроить эту конфигурацию. При установке использовались VDS без предустановленного ПО.

BIND — это DNS сервер с открытым исходным кодом, который предоставляет службы DNS в дистрибутивах Linux.

В ОС семейства Windows Server используется встроенная роль DNS сервера.

При развертывании собственного сайта арендатору хостинга приходится сталкиваться с массой специфических терминов, например, с SOA (Start Of Authority), ресурсной записью о сервере, где хранится эталонная информация о домене. Термин впервые появился в спецификации RFC 1035 (1998 г.). В документе описаны стандартные, устаревшие и экспериментальные функции, позволяющие полноценно использовать систему доменов.

Введение

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

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

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

Зона типа hint для домена точки со списком корневых серверов. Файл зона необходимо периодически обновлять с сервера ftp://ftp.internic.net/domain/named.cache

zone "." { type hint; file "/etc/bind/db.root";
};

Зоны замыкания на себя прямые, обратные и броадкастов.

zone "localhost" { type master; file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" { type master; file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" { type master; file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" { type master; file "/etc/bind/db.255";
};

Пример прямой и обратной зоны замыкания на себя, входящих в дистрибутив BIND9

; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA localhost. root.localhost. ( 2  ; Serial 604800  ; Refresh 86400  ; Retry 2419200  ; Expire 604800 )  ; Negative Cache TTL
;
@ IN NS localhost.
@ IN A 127.0.0.1
@ IN AAAA  ::1

;
$TTL 604800
@ IN SOA localhost. root.localhost. ( 1  ; Serial 604800  ; Refresh 86400  ; Retry 2419200  ; Expire 604800 )  ; Negative Cache TTL
;
@ IN NS localhost.
1.0.0 IN PTR localhost.

Что такое публичный DNS-сервер?

В приведенном выше сценарии мы ссылались на «запрашивающего”. Что же это может значить?

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

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

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

View — ограничение видимости зон

Использование ограничения видимости позволяет применять различные опции по отношению к различным клиентам.
Опция вступают в действие в зависимости от ip адреса клиента — источника запроса.

Это позволяет использовать разные данные по одной и той-же зоне для разных клиентов.
Для внутренних клиентов мы должны разрешить рекурсивные запросы, для внешних — запретить.

В конфигурационном файле необходимо запретить рекурсию по-умолчанию (закомментировать).
На рубеже версии 9.5 поведение этого флажка меняется, на новых версиях надо оставить строчку включенной.

allow-recursion { any; };

На версии 9.8.4 поведение такое:

• allow-recursion { any; }; view recusion yes; — разрешает рекурсию. (на нерекурсивный запрос дает хинт root-list);
• allow-recursion { any; }; view recusion no; — запрещает рекурсию молча (no answer);
• allow-recursion { none; }; view recusion yes|no; — запрещает рекурсию (REFUSED);
• закомментарен allow-recursion { none; }; view recusion yes|no; — запрещает рекурсию (REFUSED);

Т.е. для нас актуальны первые два варианта.

Выключить проверку DNSSEC. Требуется если мы в лабораторных условиях сквоттим TLD.

dnssec-validation no;

Конфигурация зон /etc/bind/named.conf

; список доступа - наши внутренние клиенты
acl internal { 10.13.0.0/24; localhost;
};
; область видимости для внутренних клиентов
view "internal-view" {  ; клиент - соответствует списку доступа match-clients { internal; };  ; разрешена рекурсия для внутренних клиентов recursion yes; ; зона видима только для внутренних клиентов zone "model.local" in { type master; file "/etc/bind/db.model.local"; };
; зона видима для внутренних клиентов иначе, чем для внешних
; файл зоны свой zone "model.example.net" in { type master; file "/etc/bind/db.model.example.net.internal"; };
; обратная зона для внутренних клиентов тоже своя zone "0.13.10.in-addr.arpa" in { type master; file "/etc/bind/rev.10.13.0.internal"; };
; дефолтные зоны сервера include "/etc/bind/named.conf.default-zones";
};
; область видимости, доступная всем прочим клиентам
view "external-view" { match-clients { any; };
; запрет рекурсии recursion no;
; запрет добавления Additional секции со ссылками на root сервера для всех запросов, которых нет в зонах.
; заставляет bind отвечать REFUSED на запрос посторонних имен. (Блокировка Upward referrals) additional-from-cache no;
; зона видится внешними клиентами не так, как внутренними
; файл зоны свой zone "model.example.net" in { type master; file "/etc/bind/db.model.example.net"; };
; обратная зона видится внешними клиентами не так, как внутренними
; файл зоны свой zone "0.13.10.in-addr.arpa" in { type master; file "/etc/bind/rev.10.13.0"; };
};

Обратите внимание: при запрете рекурсии внутри view перестанут работать CNAME на посторонние зоны.

При дублировании зон в областях видимости не забывайте прописать после NS записи еще и A-запись для вашего dns-сервера.
Внешние клиенты тоже должны знать ip адрес вашего NS.
Пример:

$ORIGIN model.local.
$TTL 1h
;
@ IN SOA ns1.model.local. hostmaster.model.local. ( 2014025006  ; Serial Number 10800  ; refresh 3600  ; retry 604800  ; expire 86400 )  ; min TTL
; IN NS ns1.model.local. IN MX 10 mail1
;
ns1 IN A 10.13.0.104 ; <--------- ОБЯЗАТЕЛЬНО
gw IN A 10.13.0.43
hi IN A 10.13.0.223

Если этого не сделать, в ответ на запрос к любому имени в зоне сервер будет отвечать ошибкой «ServerFail»:

root@model-net-ctrl-1:/etc/bind# dig hi.model.local. @10.13.0.104
;; Got answer:
;; HEADER opcode: QUERY, status: SERVFAIL, id: 60022

Глубокое погружение в систему доменных имен (DNS)

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

Обзор основных терминов и концепций DNS

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

TLDs или Домены верхнего уровня находится на самом высоком уровне иерархии доменных имен. Это самые общие части доменного имени, расположенные в крайнем правом углу. Например, «ком”Часть — это TLD URL-адреса www.example.com. Некоторые популярные домены верхнего уровня включают com, org, gov, net и edu.

Владельцы домена могут определять несколько разных хостов в этом домене. Их можно использовать для доступа к отдельным службам или компьютерам. Доступ к большинству веб-серверов можно получить через чистый домен, например example.com, или через объявление хоста, например www.example.com. Часть «www» здесь является хостом. Другое распространенное использование хоста — это предоставление доступа к API, например api.example.com.

Субдомены — это просто подмножество домена. Это позволяет владельцам сайтов иметь несколько поддоменов в родительском домене. Например, домен под названием University.edu может иметь несколько поддоменов для каждого из своих отделов, таких как www.cs.university.edu или www.phy.university.edu. Разница между хостами и субдоменами заключается в том, что первый определяет разные компьютеры или службы, а второй разделяет родительский домен на разные группы.

Полное доменное имя

А Полное доменное имя или FQDN является абсолютным доменом веб-сайта. Он представляет собой корень рассматриваемого домена. Домен обычно содержит несколько подмаршрутов или путей, например www.example.com/new/example. Здесь раздел www.example.com — это полное доменное имя. Кроме того, полное доменное имя всегда заканчивается точкой «.» символ, например «www.example.com.». Но пользователи не обязаны вводить эту конечную точку, так как клиентская программа позаботится об этом.

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

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

Серверы TLD находятся ниже корневых серверов в иерархии DNS. Корневые серверы направляют объекты запроса DNS на сервер TLD этого запроса. Затем сервер TLD перенаправляет запрашивающий объект на сервер имен, который имеет конкретную IP-информацию для рассматриваемого домена.

Серверы доменных имен

Мы уже обсуждали, что сервер имен хранит сопоставления домена и IP в файле зоны. Информация в файлах зоны сохраняется в виде записей. В файле зоны есть много типов записей. Мы коснемся некоторых из самых важных из них.

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

example.com. В SOA ns1.example.com. admin.example.com. ( 12083; порядковый номер 3h; интервал обновления 30м; интервал повтора 3 нед; срок годности 1ч; отрицательный TTL)

Существенные части следующие.

• example.com — Это корень зоны, указывающий, что файл предназначен для «example.com». домен.
• В SOA — «IN» означает Интернет, а SOA представляет собой тот факт, что это запись SOA.
• ns1.example.com. — Это основной сервер имен для «example.com». домен. Кроме того, если вы настроили динамический DNS в Ubuntu, здесь будет находиться ваш основной сервер имен.
• admin.example.com. — Это адрес электронной почты администратора, ответственного за данную зону. Символ «@» заменяется точкой «.» символ адреса электронной почты.
• 12083 — Это серийный номер для этой зоны, и вам необходимо увеличивать этот серийный номер каждый раз, когда вы обновляете файл зоны. Таким образом вторичные серверы определяют, что в этой зоне произошло изменение.
• 3ч — Интервал обновления для зоны указывает, как долго вторичные серверы должны ждать перед поиском изменений в файле зоны первичного сервера.
• 30м — Интервал повтора зоны определяет, как долго вторичные серверы должны ждать перед повторной попыткой опроса первичного сервера.
• 3 нед — Это период истечения срока действия, который определяет, как дольше вторичные серверы должны пытаться установить успешную связь. Если соединение не может быть установлено в течение этого периода времени, вторичные серверы перестанут отвечать как авторитетные для этой зоны.
• 1 час — Если сервер имен не может найти запрошенное имя в этом файле зоны, он будет кэшировать ошибку имени на это время.

Записи A и AAAA

имя хоста В IPv4Address. имя хоста В AAAA IPv6Address

Ниже приведен соответствующий пример использования сервера имен ns1, определенного в записи SOA.

ns1.example.com. IN A 111.112.221.222

Следующая запись «A» определяет веб-сервер как «www».

www IN A 111.112.211.212

Записи CNAME представляют собой псевдоним для сервера имен, определяемый записью A или AAAA. Например, в следующем фрагменте кода объявляется хост с именем «сервер» с использованием записи A, а затем создается псевдоним «www» для этого хоста.

сервер IN A 111.111.111.111. www IN CNAME server

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

В MX 10 mail.example.com.

Обратите внимание, что в этой записи не определен хост, и он также имеет новый номер «10». Это используется для указания предпочтений. Если имеется несколько записей MX, электронные письма будут направляться на сервер с наименьшим номером предпочтения.

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

IN NS ns1.example.com. В НС ns2.example.com.

Как и записи MX, записи NS также определены для всей зоны и не требуют имен хостов. Более того, многие службы DNS в Ubuntu считают файлы зон недействительными, если они не содержат нескольких записей ns. Таким образом, большинство файлов зоны определяют более одного сервера имен.

222.111.222.111.in-addr.arpa. 33692 В PTR host.example.com.

Приведенный выше фрагмент представляет собой базовый пример записи PTR. Он отображает IP 222.111.222.111 на host.example.com.

Записи CAA определяют, какие Центры сертификации (CA) разрешено выдавать сертификаты SSL / TLS для конкретного доменного имени. Если для домена не определена запись CAA, любой CA может выдать сертификат. Однако, если ЦС определен явно, то только этот конкретный орган может выдать сертификат.

example.com. В CAA 0 выпуск "letsencrypt.org"

Запись CAA похожа на приведенный выше фрагмент. Поля host, IN и CAA зависят от DNS, а флаги (0), теги (проблема) и значения («letsencrypt.org») зависят от CAA. ЦС проигнорирует запись, если флаг установлен в «0», но он должен воздержаться от выдачи сертификата, если он установлен в «1».

Как на самом деле работает DNS?

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

Корневой сервер возвращает адрес сервера имен TLD для этого домена, который является «.com»Сервер имен в этом примере. Теперь преобразователь отправляет запрос на сервер TLD, чтобы узнать, дает ли он ожидаемый результат. Однако сервер TLD также не имеет информации, но знает, какой сервер имен имеет. Он возвращает адрес того сервера имен, у которого есть сопоставления домена и IP для нашего URL.

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

Установка и настройка DNS-сервера Ubuntu

Теперь, когда мы обсудили, как работает DNS, и большинство ключевых концепций, мы можем приступить к созданию нашего собственного DNS-сервера. В этой части урока мы будем использовать СВЯЗЫВАТЬ(Демон именования в Интернете Berkley) программа, которая является наиболее популярной реализацией DNS и обеспечивает чрезвычайно высокую производительность даже при большой нагрузке.

$ sudo apt install bind9. $ sudo apt install dnsutils

Файлы конфигурации для BIND находятся в папке /etc/bind каталог вашего Файловая система Linux Основные данные конфигурации сохраняются в /etc/bind/named.conf файл. В /etc/bind/named.conf.options файл используется для установки глобальных опций, /etc/bind/named.conf.local для настройки зон, и /etc/bind/named.conf.default-zones файл для управления зонами по умолчанию.

Более того, вполне возможно настроить один и тот же DNS-сервер ubuntu как первичный, вторичный и кэширующий сервер. Роли меняются в зависимости от зон, которые обслуживает сервер. Например, вы можете настроить свой сервер как Начало полномочий (SOA) для одной зоны, при этом предлагая вторичные услуги для другой зоны. Между тем, он может предлагать услуги кэширования для хостов, находящихся в вашей локальной сети.

В этом разделе мы покажем, как создавать конфигурации DNS Ubuntu для первичного сервера имен. Этот сервер будет обрабатывать запросы для полного доменного имени «example.com“. Просто замените это доменное имя своим собственным URL-адресом для реализации тех же конфигураций.

Во-первых, нам нужно будет настроить файл прямой зоны. Открой /etc/bind/named.conf.local файл, используя ваш любимый текстовый редактор Linux и добавьте следующие фрагменты.

$ sudo nano /etc/bind/ named.conf.local

zone "example.com" { тип мастер; файл "/etc/bind/db.example.com"; };

Вы можете настроить свой DNS-сервер BIND на получение автоматических обновлений при изменении файлов конфигурации. Для этого воспользуйтесь файлом /var/lib/bind/db.example.com как в приведенном выше фрагменте, так и в следующей команде.

$ sudo cp /etc/bind/db.local /etc/bind/db.example.com

Приведенная выше команда копирует уже существующий файл зоны, который мы будем использовать в качестве шаблона для наших следующих шагов. Теперь мы отредактируем наш файл зоны (/etc/bind/db.example.com) и внесите необходимые изменения.

$ sudo nano /etc/bind/db.example.com

;; Файл данных BIND для example.com.; 604800 $ TTL. @ IN SOA example.com. root.example.com. ( 2; Серийный. 604800; Обновить. 86400; Повторить. 2419200; Срок действия. 604800 ); Отрицательный TTL кеша

;; Файл данных BIND для example.com.; 604800 $ TTL. @ IN SOA example.com. root.example.com. ( 3; Серийный 604800; Обновить 86400; Retry 2419200; Срок действия 604800); TTL отрицательного кэша @ IN NS ns.example.com. @ В А 192.168.1.10. @ IN AAAA:: 1. нс IN A 192.168.1.10

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

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

$ sudo systemctl перезапуск bind9.service

Теперь, когда наш файл прямой зоны настроен правильно, давайте изменим файл обратной зоны. Это позволяет DNS-серверу Ubuntu преобразовывать IP в полное доменное имя. Просто отредактируйте /etc/bind/named.conf.local файл и добавьте приведенные ниже фрагменты.

$ sudo nano /etc/bind/ named.conf.local

зона "1.168.192.in-addr.arpa" { тип мастер; файл "/etc/bind/db.192"; };

Вам нужно будет заменить «1.168.192» первыми тремя октетами вашей собственной сети. Причем файл зоны должен иметь соответствующее имя. Заменить “192” часть файла зоны «/Etc/bind/db.192» чтобы соответствовать первому октету вашей сети. Так, например, если вы находитесь в сети 10.1.1.1/24; ваш файл зоны будет иметь вид «/etc/bind/db.10»И запись«1.168.192.in-addr.arpa» будет «10.1.1.in-addr.arpa“.

$ sudo cp /etc/bind/db.127 /etc/bind/db.192

Мы создали /etc/bind/db.192 файл путем копирования существующего файла шаблона. Теперь давайте отредактируем этот файл и внесем те же изменения, что и в /etc/bind/db.example.com файл.

$ sudo nano /etc/bind/db.192

;; Файл обратных данных BIND для локальной сети 192.168.1.XXX.; 604800 $ TTL. @ В SOA ns.example.com. root.example.com. ( 2; Серийный 604800; Обновить 86400; Retry 2419200; Срок действия 604800); TTL отрицательного кэша; @ IN NS нс. 10 В PTR ns.example.com.

Не забывайте увеличивать серийный номер при каждом последующем изменении файла обратной зоны. Кроме того, для каждой записи A, настроенной в /etc/bind/db.example.com, вы всегда должны добавлять PTR-запись в файл /etc/bind/db.192.

Как только все это будет сделано, просто перезапустите службу BIND.

$ sudo systemctl перезапуск bind9.service

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

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

$ sudo nano /etc/bind/ named.conf.local

zone "example.com" { тип мастер; файл "/etc/bind/db.example.com"; разрешить передачу {192.168.1.11; }; }; зона "1.168.192.in-addr.arpa" { тип мастер; файл "/etc/bind/db.192"; разрешить передачу {192.168.1.11; }; };

Затем перезапустите BIND на основном сервере, введя следующую команду.

$ sudo systemctl перезапуск bind9.service

Теперь вам нужно установить BIND на вторичный сервер. Затем перейдите к редактированию /etc/bind/named.conf.local файл и добавьте следующее для прямой и обратной зон.

zone "example.com" { типа раб; файл "db.example.com"; мастера {192.168.1.10; }; }; зона "1.168.192.in-addr.arpa" { типа раб; файл "db.192"; мастера {192.168.1.10; }; };

$ sudo systemctl перезапуск bind9.service

$ sudo nano /etc/bind/ named.conf.local

zone "example.com" { тип мастер; файл "/etc/bind/db.example.com"; разрешить передачу {192.168.1.11; }; также-уведомить {192.168.1.11; }; }; зона "1.168.192.in-addr.arpa" { тип мастер; файл "/etc/bind/db.192"; разрешить передачу {192.168.1.11; }; также-уведомить {192.168.1.11; }; };

$ sudo nano /etc/bind/ named.conf.options

экспедиторы { 1.2.3.4; 5.6.7.8; };

Теперь открой свой любимый Эмулятор терминала Linux и введите команду ниже для перезапуска BIND.

$ sudo systemctl перезапуск bind9.service

Тестирование и устранение неполадок конфигураций DNS в Ubuntu

$ sudo nano /etc/resolv.conf

сервер имен 127.0.0.53. поиск example.com

Вы можете легко узнать DNS-сервер, используемый распознавателем вашего локального компьютера, с помощью следующей команды.

$ systemd-resolve --status

Еще один полезный способ проверки конфигураций DNS — использовать команду Linx dig. Просто используйте dig против интерфейса обратной связи и посмотрите, прослушивает ли он порт 53 или нет.

$ dig -x 127.0.0.1

В приведенной ниже команде используется Команда grep в Linux чтобы отфильтровать релевантную информацию.

$ dig -x 127.0.0.1 | grep -i "53"

Если вы настроили BIND как кэширующий сервер, используйте dig для проверки внешнего домена и запишите время запроса.

$ dig ubuntu.com

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

$ ping example.com

Проверка работоспособности DNS-сервера

Проверить работоспособность полученной конфигурации можно используя команду dig. В Debian/Ubuntu устанавливается через apt-get пакет dnsutils.

# apt -y install dnsutils

В CentOS/AlmaLinux/RockyLinux установка dig производится через менеджер пакетов dnf или yum (для CentOS 7) — пакет bind-utils.

# dnf -y install bind-utils
# yum -y install bind-utils (для CentOS 7)

Для проверки запускаем команду dig: 

# dig @1.1.1.1 example.com

В случае успеха ответ будет таким:

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> @1.1.1.1 exapmle.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54919
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
ns1.example.com. 3600 IN A 1.1.1.1
ns2.example.com. 3600 IN A 2.2.2.2
;; Query time: 0 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Вс янв 15 18:08:36 MSK 2023
;; MSG SIZE rcvd: 60

Данной утилитой проверяется ответ сервера, то что ему известно про существование зоны и записи в ней.

Настройка DNS в системе Ubuntu

Иногда пакет bind9 уже установлен в шаблоне Ubuntu, его необходимо запустить и добавить в автозапуск:

# systemctl start bind9
# systemctl enable bind9

Если bind9 не установлен, установка такая же, как для системы Debian.

# apt update
# apt -y install bind9

Дальнейшая настройка выполняется точно также как в случае настройки на Debian

Настройка DNS в системе Debian

В шаблоне debian следует установить пакет bind (предварительно синхронизировав информацию о пакетах).

# apt update
# apt -y install bind9

Отредактируйте файл /etc/bind/named.conf добавив в него описание вашей зоны (предположим, что домен называется example.com).

zone "example.com" { type master; file "/etc/bind/example.com";
};

Отредактируйте файл /etc/bind/example.com добавив в него строки:

$TTL 3600
@ IN SOA ns1.example.com. root.example.com. (2012000001 10800 3600 604800 86400)
@ IN NS ns1
@ IN NS ns2
ns1 IN A 1.1.1.1
ns2 IN A 2.2.2.2
@ IN A 1.1.1.1
www IN A 1.1.1.1

Не забудьте проверить права на файл /etc/bind/example.com и поправить их в случае необходимости:

# chown bind:bind /etc/bind/example.com

После чего можно перечитать конфигурацию DNS-сервера:

# rndc reload

После приведенной настройки можно указывать серверы имен ns1.example.com/1.1.1.1 и ns2.example.com/2.2.2.2 у регистратора. В Личном кабинете следует указывать записи через символ /, у регистраторов может быть меню Child Nameservers где указывается данное соответствие.

Корневые серверы DNS

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

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

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

Зона обратного просмотра

Зона обратного просмотра управляется владельцем диапазона ip адресов.

Пример файла зоны обратного просмотра, для которой мы являемся мастером

;
$ORIGIN 0.13.10.IN-ADDR.ARPA.
$TTL 1h
;
@ IN SOA ns1.model.local. hostmaster.model.local. ( 2014023001  ; Serial Number 10800  ; refresh 3600  ; retry 604800  ; expire 86400 )  ; min TTL
; IN NS ns1.model.local.
;
2 IN PTR ns1.model.local.
101 IN PTR netctrl-01.model.local.
255 IN PTR bc.model.local.
;

Конечные мысли

Зона прямого просмотра

Зоны прямого просмотра делегируются нам владельцем родительского домена.

Пример файла зоны, для которой мы являемся мастером (SOA ns1.model.local.)
Сервер ns.example.com. указан в качестве вторичного.

Параметры времени жизни записи:

• TTL — время, на которое запись считается действительной, после выдачи сервером. Записи в кэше хранятся в течение TTL.
• Negative Cache TTL — время действия ответа об отсутствии записи (NXDOMAIN). Запись о том, что запрошенное имя не существует хранится в кэше на это время.

TTL можно задавать отдельно для каждой записи. Negative Cache TTL — действует на зоны в целом.

;
$ORIGIN model.local.
$TTL 1h
;
@ IN SOA ns1.model.local. hostmaster.model.local. ( 2014023001  ; Serial Number 10800  ; refresh 3600  ; retry 604800  ; expire 86400 )  ; Negative Cache TTL
; IN NS ns1.model.local. IN NS ns.example.com. IN MX 10 mail1
;
gw IN A 10.13.0.1
; несколько имен на один адрес
ns1 IN A 10.13.0.2
net-ctrl-1 IN A 10.13.0.2
mail1 IN A 10.13.0.10
front2 IN A 10.13.0.11
back1 IN A 10.13.0.20
back2 IN A 10.13.0.21
; несколько адресов на одно имя - балансировка
back IN A 10.13.0.20 IN A 10.13.0.21
stor1 IN A 10.13.0.30
stor2 IN A 10.13.0.31
stor-vip IN A 10.13.0.40
front-vrrp IN A 10.13.0.50
www IN CNAME model.local.
bc IN A 10.13.0.255
;
; users
user1 IN CNAME back.model.local.
www.user1 IN CNAME back.model.local.
user2 IN CNAME back.model.local.
www.user2 IN CNAME back.model.local.
;

Файлы зоны

Мы уже упоминали в перечисленных выше процессах «файлы зоны» и «записи».

Файлы зоны это способ, с помощью которого DNS-сервер хранит информацию о доменах, которые он знает. Каждый домен, информация о котором есть у DNS-сервера, хранится в файле зоны. Если DNS-сервер настроен для работы c рекурсивные запросами, как публичный DNS-сервер, он найдет ответ и предоставит его. В противном случае он укажет пользователю, где искать дальше. Чем больше у сервера файлов зоны, тем больше ответов на запросы он сможет предоставить.

Файл зоны описывает DNS «зону», которая, по существу, является подмножеством всей системы DNS. Как правило, она используется для настройки только одного домена. Она может содержать некоторое количество записей, которые указывают, где находятся ресурсы для запрашиваемого домена.

Параметр зоны $ORIGIN эквивалентен высшему уровню полномочий в зоне по умолчанию. 
Таким образом, если файл зоны используется для настройки домена «example.com.», то параметр $ORIGIN также будет установлен для этого домена.

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

Точно так же $TTL настраивает «время жизни» информации, которую он предоставляет. По сути, это таймер. Кэширующий DNS-сервер может использовать ранее запрошенные результаты для ответа на вопросы, пока заданное значение TTL не истечет.

Как проверить данные SOA-записи

Стандартный способ проверки содержимого SOA-записи – это утилита DIG (Domain Information Groper). Она работает в веб-интерфейсе на сайте хостинга, предоставляющего доступ к DNS-серверам, или устанавливается на локальный компьютер. На сайте разработчика представлены дистрибутивы под 64-разрядную Windows и Linux-совместимые системы.

Процедура проверки в веб-версии:

1. Запустите утилиту.
2. Введите имя интересующего домена (сайта).
3. Выберите тип записи «SOA».
4. Нажмите кнопку «Проверить».

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

Чуть иначе работает сервис XSEO. После ввода доменного имени и нажатия на кнопку «Проверить» отобразится название сервера, откуда был получен отклик, текущий серийный номер и другие параметры, о которых шла речь выше.

Настройка DNS в Windows

Зайдите в Диспетчер серверов — Управление — нажмите Добавить роли и компоненты и добавьте DNS-сервер.

Далее в Диспетчере серверов переходим в Средства — DNS.

Нажимаем на имя сервера, на кнопку Действие — Настроить DNS сервер. Откроется мастер настройки DNS сервера. Нажимаем Далее и выбираем Зону прямого просмотра.

Вводим имя зоны и жмем Далее.

Запрещаем динамическое обновление.

После можно настроить пересылку запросов определенным DNS серверам, либо оставить распознавание имен при помощи корневых серверов. Жмем Далее — Готово.

Осталось добавить DNS-записи. Выбираем Зоны прямого просмотра, нажимаем на созданную нами зону и нажимаем на кнопку Тип записи ресурса. Ищем тип записи Узел (типа А или АААА), выбираем его и создаем запись.

В появившемся окне добавляем А-записи. У первой записи Узел остается пустой. Указываем IP и создаем запись.

Аналогичным образом создаем остальные А-записи, при этом указывая название в поле Узел.

Редактируем запись Сервер имен (NS).

Выбираем имя сервера и нажимаем на кнопку Изменить. В открывшемся окне меняем имя NS (в нашем случае ns1.example.com.). Не забудьте в конце добавить точку!

Ниже указываем соответствующий IP (в нашем случае 1.1.1.1) и нажимаем ОК.

Первое имя NS настроено, добавляем второе. В окне нажимаем на Добавить, а затем таким же способом добавляем второе имя NS (в нашем случае это ns2.example.com. и IP 2.2.2.2). Получим такую картину:

Аналогично А-записям можно добавить другие, например, MX или TXT.

Что представляет собой SOA-запись

Серверы доменных имен DNS обычно настраиваются в кластеры. Базы данных в них систематически синхронизируются посредством передачи зон. Запись SOA содержит данные для управления этим процессом – это серийный номер, время кэширования информации и взаимодействия с внешними запросами. Также в ней записана контактная электронная почта и имя главного сервера идентификации доменов.

1. Запись создается автоматически и не подлежит удалению.
2. Перечисленная информация располагается в верхней части зоны.
3. Зона без записи SOA не соответствует стандарту RFC 1035.

Критично не только наличие данных, но еще и соблюдение определенного синтаксиса. Например, в блоке временных параметров положено использовать буквы, соответствующие неделям, дням, часам, минутам и секундам (w, d, h, m и s соответственно). Формат самой SOA-записи выглядит так:

имя [TTL] SOA данные
имя: имя зоны
TTL: значение параметра TTL
SOA: тип записи

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Типы ресурсных записей (RR)

SOA запись в файле зоны должна быть только одна. В файле она должна стоять первой.
Запись SOA определяет какой сервер является владельцем зоны и какие на зону установлены параметры.
После записи SOA надо обязательно указать IN NS запись с тем-же сервером, что и в заголовке.

Пример: домен example.com обслуживается серверами ns.example.com и ns.examle.net.
После указания директивы $ORIGIN сервер автоматически допишет за нас все неполные dns имена (таким образом hostmaster читается как hostmaster.example.com). Имя сервера вне зоны пишется полностью.

$TTL 2d ; zone TTL default = 2 days or 172800 seconds
$ORIGIN example.com.
@ IN SOA ns hostmaster ( 2003080800 ; serial number 1d12h  ; refresh = 1 day 12 hours 15M  ; update retry = 15 minutes 3W12h  ; expiry = 3 weeks + 12 hours 2h20M  ; minimum = 2 hours + 20 minutes ) IN NS ns IN NS ns.example.net.  ; out-of-zone
...
; A record for the NS RR above
ns IN A 192.168.2.1
;

Пример 2: домен example.com обслуживается двумя серверами вне зоны. Для них указаны полные имена в записях IN NS.
Т.к. домен обслуживается другими серверами никакие A записи не допускаются.

$TTL 2d ; zone TTL default = 2 days or 172800 seconds
$ORIGIN example.com.
@ IN SOA ns.example.net. hostmaster.example.com. ( 2003080800 ; serial number 1d12h  ; refresh = 1 day 12 hours 15M  ; update retry = 15 minutes 3W12h  ; expiry = 3 weeks + 12 hours 2h20M  ; minimum = 2 hours + 20 minutes ) IN NS ns.example.net. ; out-of-zone name server IN NS ns.example.org. ; out-of-zone name server

Инфраструктурная запись, указывающая имя сервера имен для данного домена.
Формат

owner-name ttl class rr target-name
example.com. IN NS ns1.example.com.

Согласно стандарту, каждый публичный домен должен иметь минимум 2 сервера имен. Частный домен может обслуживаться и одним сервером.

Если NS сервер для нашего домена находится в нашем домене, то мы обязаны указать A-запись для этого сервера (glue-record).
Если NS сервер лежит вне домена — A-запись указывать не нужно.

Пример: NS записи для основного домена и для делегированного поддомена с указанием glue-records.

$TTL 2d ; default TTL is 2 days
$ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 ; serial number 2h  ; refresh = 2 hours 15M  ; update retry = 15 minutes 3W12h  ; expiry = 3 weeks + 12 hours 2h20M  ; minimum = 2 hours + 20 minutes ) IN NS ns1.example.com. IN NS ns2.example.com.
; обязательно указываем адреса этих серверов
ns1 IN A 192.168.0.3
ns2 IN A 192.168.0.4
; переключение на поддомен
$ORIGIN us.example.com.
@ IN NS ns3.us.example.com. IN NS ns1.example.com.
; обязательно указываем на сервер поддомена
ns3.us.example.com. A 10.10.0.24

A-запись указывает на ip адрес для данного имени хоста. Опционально указать особо ttl.

Пример: различные вариации записи

$TTL 2d ; zone default = 2 days or 172800 seconds
joe IN A 192.168.0.3  ; одинаковые ip
www IN A 192.168.0.3
; можно указать домен полностью
www.example.com. A 192.168.0.3
fred 3600 IN A 192.168.0.4  ; указан другой ttl
ftp IN A 192.168.0.24 ; разные ip для одного имени IN A 192.168.0.7
mail IN A 192.168.0.15  ; разные ip для одного имени
mail IN A 192.168.0.32
mail IN A 192.168.0.3
squat IN A 10.0.14.13  ; другая подсеть

AAAA-запись используется для IPv6 адресов

ws1-29 A 10.0.10.29 AAAA 2002:d4c0:4090::d110:1011 

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

Инфраструктурная запись указывающая на имя почтового сервера для домена.
Если имя сервера в этом-же домене — требуется еще А-запись с ip адресом почтового сервера.

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

Пример: почтовые сервера для домена и поддомена в одном файле

$TTL 2d ; zone default = 2 days or 172800 seconds
$ORIGIN example.com.
example.com. IN SOA ns1.example.com. root.example.com. ( 2003080800 ; serial number 2h  ; refresh = 2 hours 15M  ; update retry = 15 minutes 3W12h  ; expiry = 3 weeks + 12 hours 2h20M  ; minimum = 2 hours + 20 minutes )
; почтовый сервер для адресов вида user@example.com IN MX 10 mail.example.com.
; почтовые сервера для поддомена user@us.example.com
us IN MX 10 mail.us.example.com.
us IN MX 20 mail.example.com.
; A-запись для основного почтового сервера
mail IN A 192.168.0.5
; Переключение на поддомен
$ORIGIN us.example.com.
; A-запись для почтового сервера поддомена
mail IN A 10.10.0.29

Запись CNAME используется для указания псевдонима или ссылки одного имени на другое.
Если сервер вернул клиенту CNAME в ответ на запрос, то клиенту придется повторно делать запрос на разрешение CNAME.
Используется для удобства администрирования при наличии многих имен у одного сервера.

Примеры различных псевдонимов в домене example.com.:

joe IN A 192.168.254.3
www IN CNAME joe
www IN CNAME joe.example.com.
ftp IN CNAME www.example.com. ; паровоз
bill IN CNAME fred.another.com. ; перенаправление на имя в другом домене
; IN A 192.168.254.8
www IN CNAME example.com.

Перенаправление зон RFC 6672

Обратная запись указывает на имя по ip адресу. Используется специальный домен .IN-ADDR.ARPA.
Для IPv6 используется другой домен — IP6.ARPA. Поэтому обратные записи необходимо держать в разных файлах для ipv4 и ipv6.

Пример для IPv4:

$TTL 2d ; 172800 secs
$ORIGIN 23.168.192.IN-ADDR.ARPA.
@ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 ; serial number 12h  ; refresh 15m  ; update retry 3w  ; expiry 3h  ; minimum ) IN NS ns1.example.com. IN NS ns2.example.com.
2 IN PTR joe.example.com. ; FDQN
15 IN PTR www.example.com.
17 IN PTR bill.example.com.
74 IN PTR fred.example.com.

Пример для IPv6:

; reverse IPV6 zone file for example.com
$TTL 2d  ; default TTL for zone 172800 secs
$ORIGIN 0.0.0.0.8.b.d.0.1.0.0.2.IP6.ARPA.
@ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 ; sn = serial number 12h  ; refresh = refresh 15m  ; retry = update retry 3w  ; expiry = expiry 2h  ; min = minimum ) IN NS ns1.example.com. IN NS ns2.example.net.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR ns1.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0 IN PTR mail.example.com.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR joe.example.com.
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.0 IN PTR www.example.com.

Обратные зоны для бесклассовых подсетей

Приемы через CNAME и DNAME

Типы записи

В файле зоны может быть множество различных типов записей. Мы рассмотрим некоторые из наиболее распространенных видов (или обязательных) ниже.

Начальная запись зоны или SOA (Start of Authority) — обязательная запись для всех файлов зоны. Она должна быть первой записью в файле (хотя $ORIGIN или $TTL могут появиться выше). Она также является одной из самых сложных для понимания.

Начальная запись зоны выглядит примерно так:

domain.com. In SOA ns1.domain.com. admin.domain.com. ( 12083 ; serial number 3h ; refresh interval 30m ; retry interval 3w ; exiry period 1h ; negative TTL
)

Поясним, что означает каждая часть:

• domain.com.: Это корень зоны. Он указывает, что файл зоны относится к домену  domain.com.domain. Часто вы будете видеть, что он заменен на “@”, что является только заполнителем, который замещает содержимое переменной $ORIGIN, о которой мы узнали выше.
• In SOA: Часть «In» означает Интернет (и будет присутствовать во многих записях). SOA является показателем того, что это начальная запись зоны.
• ns1.domain.com.: Эта часть определяет мастер-сервер для этого домена. DNS-сервер может быть либо мастером, то есть первичным, либо слейв, или вторичным. 
• admin.domain.com.: Это электронный адрес администратора этой зоны. Символ «@» заменяется точкой в ​​адресе электронной почты. Если в части имени email адреса обычно стоит точка, это означает замену символа «\» в этой части (your.name@domain.com становится your\name.domain.com).
• 12083: Это серийный номер файла зоны. Каждый раз, когда вы редактируете файл зоны, необходимо увеличивать это число. Слейв серверы проверят, если серийный номер мастер сервера для зоны больше, чем тот, который находится у них в системе. Если это так, то сервер запросит новый файл зоны, а если нет, то он продолжит обслуживать исходный файл.
• 3h: Это интервал обновления для зоны. Это количество времени, которое слейв сервер будет ждать прежде, чем запросит у мастер сервера изменение файла зоны.
• 30m: Это интервал повтора для этой зоны. Если слейв сервер не может подключиться к мастеру, когда наступает период обновления, он будет ждать данное количество времени, а после повторит запрос мастер серверу.
• 3w: Это период истечения. Если слейв DNS-сервер не смог связаться с мастер сервером в течение этого периода времени, он больше не будет возвращать запросы к авторитетному источнику этой зоны.
• 1h: Это количество времени, которое DNS-сервер будет кэшировать ошибку, если не сможет найти запрашиваемое имя в файле.

А и AAAA записи

Обратите внимание, что нет необходимости указывать полное имя. Мы можем просто указать узел (без FQDN), и DNS-сервер заполнит остальное согласно значению $ORIGIN. Тем не менее мы могли бы так же легко использовать FQDN:
ns1.domain.com.     IN A     111.222.111.222

В большинстве случаев это то место, где вы укажете свой веб-сервер как «WWW»:
WWW         IN A    222.222.222.222

Мы должны также сказать, где находится основной домен. Мы можем сделать это следующим образом:
domain.com.     IN A     222.222.222.222

У нас также есть возможность преобразования всего, что находится под этим доменом, но не явно относится к этому серверу. Мы можем сделать это с помощью символа «*»:
*     IN A     222.222.222.222

Все выше перечисленное также работает с AAAA записями для IPv6-адресов.

CNAME записи указывает псевдоним для канонического имени вашего сервера (который определен А или AAAA записью).

Например, у нас может быть A запись, определяющая узел «server1», а затем мы можем использовать «WWW» в качестве псевдонима для данного узла:
server1    IN A     111.111.111.111
www         IN    CNAME    server1

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

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

MX записи указывают серверы обмена почты для домена. Это помогает сообщениям электронной почты приходить в ваш почтовый сервер правильно.
В отличие от многих других типов записей, почтовые записи, как правило, не присоединяют узел к чему-либо, потому что они распространяются на всю зону. Они, как правило, выглядит следующим образом:
       IN     MX 10 mail.domain.com.

Обратите внимание, что в начале нет имени узла.
Также в записи присутствует дополнительный номер. Это предпочтительный номер, который помогает компьютерам определить, какому серверу отправлять почту, если указаны несколько почтовых серверов. Более низкие значения имеют более высокий приоритет.

Запись MX должна, по сути, переправлять на узел, указанный в записи A или AAAA, а не к той, что указана CNAME.
Представим, что у нас есть два почтовых сервера. Там должны быть записи, которые выглядят примерно так:
       IN         MX     10     mail1.domain.com.
        IN     MX     50    mail2.domain.com.
mail1     IN A     111.111.111.111
mail2     IN A     222.222.222.222

В этом примере узел «mail1» является предпочтительным сервером обмена почты.
Мы могли бы также написать это следующим образом:
       IN         MX     10     mail1
        IN     MX     50     mail2
mail1     IN A     111.111.111.111
mail2     IN A     222.222.222.222

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

Как MX записи, NS записи являются параметрами всей зоны, так что они также не соединяют узлы. Выглядят они так:
       IN NS ns1.domain.com.
        IN NS ns2.domain.com.

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

Как всегда, учитывайте соединение для узлов с записями A или AAAA:
       IN NS     ns1.domain.com.
        IN NS     ns2.domain.com.
ns1     IN A     111.222.111.111
ns2     IN A     123.211.111.233

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

Терминология доменов

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

Система доменных имен

Система доменных имен, более известная как «DNS», является сетевой системой, которая позволяет нам преобразовать удобные для человека имена (обычно буквенные) в уникальные адреса.

Доменное имя это удобная для человека форма имени, которую мы привыкли ассоциировать с интернет-ресурсом. Например, «google.com» является доменным именем. Некоторые скажут, что часть «Google» является доменом, но в целом мы можем считать эту комбинированную форму доменным именем. 

URL-адрес «google.com» соединен с сервером, находящимся в собственности Google Inc. Система доменных имен позволяет нам соединиться с сервером Google при вводе «google.com» в браузере.

Домен верхнего уровня

Домен верхнего уровня, или TLD, это самая общая часть домена. Является последней частью доменного имени справа (отделен точкой). Распространенными доменами верхнего уровня считаются «com», «net», «org», «gov», «edu» и «io».

В пределах домена его владелец может определять собственные узлы, которые ссылаются на отдельные компьютеры или услуги, доступные через домен. Например, большинство владельцев доменов делают свой веб-сервер доступным через  корневой  домен (example.com), а также через «узел», определенный как «www» (www.example.com).
У вас могут быть другие определения узлов под общим доменом. Вы можете иметь API доступ через «api» узел (api.example.com) или FTP доступ, обозначив узел «FTP» или «files» (ftp.example.com или files.example.com). Имена узлов могут быть произвольными, при условии, что они являются уникальными для данного домена.

Объект, связанный с узлами, называется поддомен.
DNS работает в иерархии. Домены верхнего уровня могут иметь множество доменов под ними. Например, домен верхнего уровня «com» включает в себя «google.com» и «ubuntu.com». Поддомен это домен, который является частью домена более высокого уровня. В этом случае можно сказать, что «ubuntu.com» явлется поддоменом «com». Как правило, он называется просто доменом или часть «Ubuntu» называется SLD, что означает домен второго уровня.

Точно так же каждый домен может контролировать «поддомены», которые находятся под ним. Например, у вас мог бы быть поддомен для отдела истории в вашей школе по адресу «www.history.school.edu». В этом случае часть «history» считается поддоменом.
Разница между именем узла и поддомена в том, что узел указывает на компьютер или ресурс, в то время как поддомен расширяет родительский домен. 

Читая о поддоменах или узлах, вы можете заметить, что самый левые части доменов наиболее конкретные. Это объясняет работу DNS: от наиболее конкретного к наименее конкретному, так как вы читаете слева направо.

Полностью определенное имя домена

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

Это означает, что он указывает на каждый родительский домен, включая TLD. Правильный FQDN заканчивается точкой, указывая на корень иерархии DNS. Примером FQDN является «mail.google.com.». Иногда программное обеспечение, которое запрашивает FQDN, не нуждается в точке на конце, но завершающая точка требуется для соответствия стандартам ICANN.

DNS-сервера могут быть «авторитетными», что означает, что они предоставляют ответы на запросы о доменах под своим контролем. В противном случае они могут указать на другие серверы или предоставить кэшированные копии данных других DNS-cерверов.

Файлы зоны находятся на DNS-серверах и в общем определяют ресурсы, доступные под конкретным доменом, или место, в котором можно запросить данную информацию. 

Комьюнити теперь в Телеграм

Подпишитесь и будьте в курсе последних IT-новостей

Как работает DNS

Теперь, когда вы знакомы с некоторой терминологией, связанной с DNS, возникает вопрос, как действительно работает система?

Система очень проста, если смотреть в общем, но очень сложна, если вы углубитесь в детали. В целом, это очень надежная инфраструктура, которая была необходима для адаптации интернета таким, каким мы знаем его сегодня.

Какие параметры хранятся в SOA-записи

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

Прочитать содержимое легко любым текстовым редактором вроде Блокнота или Notepad++. Подойдут и утилиты, встроенные в файловые менеджеры.

Основные типы информации в SOA:

1. TTL – время в секундах, которое затрачивается на кэширование данных, передаваемых через DNS-серверы.
2. MNAME – имена удаленных компьютеров, где будет храниться остальная информация о доменах.
3. RNAME (Hostname) – контактный электронный адрес лица, ответственного за конкретную SOA-запись.
4. Serial Number – серийный номер базы данных зоны, меняющийся при обновлении данных (это указывает вторичным серверам на то, что пора обновить конфигурацию).
5. Refresh – время в секундах, отпускаемое на запрос данных у первичного DNS-сервера, чтобы определить, требуется ли обновлять информацию (не менялся ли серийный номер).
6. Retry – время ожидания в секундах, через которое сервер будет принимать повторный запрос при неудачной попытке считывания информации.
7. Expire – период в секундах, в течение которого используются ранее полученные данные от первичного DNS-сервера. По истечении срока они теряют актуальность.
8. Minimum TTL – период хранения данных зоны в кэше.

Перечисленных параметров достаточно, чтобы обеспечить бесперебойную связь DNS-серверов между собой. Остальная информация хранится в других типах записей: NS, A, AAAA, MX, SRV, TXT, SPF, DKIM, CNAME. Подобная классификация упрощает считывание и понимание данных, а также снижает риски сбоев из-за ошибок доступа внешних приложений.

Настройка DNS в системе CentOS

Иногда DNS сервер уже предустановлен в шаблоне ПО Сentos/AlmaLinux/RockyLinux. Его следует настроить и запустить. Если его нет, то нужно предварительно установить:

# dnf -y install bind
# yum -y install bind (для Centos 7)

Запускаем DNS сервер и добавляем его в автозагрузку:

# systemctl start named
# systemctl enable named

Отредактируйте /etc/named.conf и удалите или закомментируйте символами // строки:

listen-on port 53 { 127.0.0.1; };
allow-query { localhost; };

allow-transfer { 1.1.1.1; 2.2.2.2;};

В результате блок options файла /etc/named.conf будет выглядеть примерно так:

options {
// listen-on port 53 { 127.0.0.1; };
// listen-on-v6 port 53 { ::1; }; directory "/var/named"; dump-file "/var/named/data/cache_dump.db"; statistics-file "/var/named/data/named_stats.txt"; memstatistics-file "/var/named/data/named_mem_stats.txt"; recursing-file "/var/named/data/named.recursing"; secroots-file "/var/named/data/named.secroots"; allow-query { localhost; };
// recursion yes; dnssec-enable yes; dnssec-validation yes; /* Path to ISC DLV key */ bindkeys-file "/etc/named.root.key"; managed-keys-directory "/var/named/dynamic"; pid-file "/run/named/named.pid"; session-keyfile "/run/named/session.key"; allow-transfer { 1.1.1.1; 2.2.2.2;};
};

Следующий шаг (создание и настройка использования rndc.key) можно пропустить, если не будете пользоваться командой rndc, — в таком случае перезапустите DNS-сервер командой: 

# systemctl restart named/etc/init.d/named restart

Создайте ключ /etc/rndc.key командой:

# rndc-confgen -a

Добавьте в /etc/named.conf:

key "rndc-key" { algorithm hmac-md5; secret "sUUony71pdPDHSZjNrkDFQ==";
};
controls { inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
};

Где строку secret:

secret "sUUony71pdPDHSZjNrkDFQ==";

следует брать из файла /etc/rndc.key.

Запустите named и добавьте его в автозапуск:

# systemctl start named
# chkconfig named --level 2345 on

Настройка зоны производится аналогично настройке на Debian / Ubuntu со следующими отличиями:

• файл конфигурации DNS-сервера /etc/named.conf
• зоны расположены в каталоге /var/named

Вывод

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