Как создать собственный DNS-сервер

Обновлено: 21.11.2024

Система доменных имен является важной частью Интернета, но ее часто упускают из виду. В этом посте я объясню свое обоснование использования собственных авторитетных серверов имен DNS, а затем поделюсь сценариями автоматического развертывания и настройки, которые я создал по ходу работы, что позволит вам настроить собственные DNS-серверы менее чем за час.< /p>

Что такое авторитетный сервер имен?

В целом существует два типа DNS-серверов. Рекурсивные распознаватели — это тип, с которым пользователи, скорее всего, знакомы. Примерами рекурсивных распознавателей являются Cloudflare 1.1.1.1 и Google 8.8.8.8. Когда вашему компьютеру потребуется выполнить поиск DNS, он запросит рекурсивный преобразователь.

Авторитетные серверы имен являются источником достоверной информации в системе доменных имен. Когда рекурсивные распознаватели получают запрос на конкретное доменное имя, они получают эту информацию от авторитетных серверов имен (при условии, что она еще не сохранена в их кеше).

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

Если вам интересно узнать больше о DNS, этот веб-комикс послужит отличным введением.

Зачем использовать собственные DNS-серверы?

Можно владеть доменом и управлять веб-сайтом, вообще не задумываясь о DNS. Это связано с тем, что почти каждый регистратор доменов предлагает своим клиентам бесплатный хостинг DNS. Учитывая это, зачем мне запускать собственные серверы имен?

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

Почему бы НЕ запускать собственные DNS-серверы?

Если бы не обучение, вам почти наверняка НЕ СЛЕДУЕТ запускать собственные DNS-серверы. Как упоминалось выше, для небольших сайтов ваш регистратор доменов, вероятно, предоставляет DNS-хостинг бесплатно. Для пользователей, которым нужен больший контроль, большее время безотказной работы или повышенная производительность, есть платные провайдеры хостинга DNS, которые отлично справляются со своей задачей.

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

Автоматическое развертывание

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

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

Запуск экземпляров облачного сервера

Я решил разместить свои DNS-серверы на Linode. Конечно, вы можете использовать любого поставщика VPS, но сценарий в этом разделе работает только для предоставления экземпляров на Linode. Если вы следуете инструкциям и хотите использовать другого поставщика VPS, подготовьте два компьютера с Linux (я использовал CentOS 8) в разных центрах обработки данных, а затем перейдите к следующему разделу.

Зачем нам два сервера? Спецификация DNS фактически требует по крайней мере двух авторитетных серверов имен для каждой зоны. Подробнее см. в разделе 4.1 RFC 1034.

Приведенный выше фрагмент кода Python создает два облачных сервера с помощью Linode API, настроенных с использованием моего локального ключа SSH для разрешения удаленного доступа. Смотрите полный источник для более подробной информации. Единственная настройка, необходимая перед этим, — это создание учетной записи Linode и получение ключа API для использования скриптом.

Предоставление программного обеспечения и конфигурации DNS

Я использую Ansible для создания сценария конфигурации сервера.

Общая роль просто отключает вход по паролю через SSH для повышения безопасности. Подробнее см. в определении роли.

Более актуальна роль сервера имен.

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

Третий шаг обеспечивает файл конфигурации BIND.

Последний шаг предоставляет файл зоны.

Этот файл создан по шаблону, поэтому мне не нужно дублировать общедоступные IP-адреса моих серверов имен, поскольку они уже указаны в файле инвентаризации.

Что дальше?

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

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

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

В предыдущей статье этой серии, состоящей из двух частей, "Введение в DNS (систему доменных имен)" я описал, как устроена база данных DNS и как настроить службы имен на клиенте. Я также перечислил и описал некоторые из наиболее распространенных записей DNS, с которыми вы, вероятно, столкнетесь при создании сервера имен или просто пытаетесь интерпретировать результаты команды dig.

В этой статье я покажу вам, как создать собственный сервер имен с помощью BIND (домена имен в Интернете Беркли). Это не так сложно, как вы думаете, особенно потому, что вы можете сделать это в два этапа.

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

Настройка DNS-сервера с помощью BIND

Настроить сервер имен с помощью BIND довольно просто, поэтому я покажу вам, как это сделать на любом компьютере, доступном для экспериментов. Этот небольшой лабораторный проект покажет вам, как установить и настроить BIND на вашем компьютере в качестве кэширующего сервера имен, протестировать его, а затем настроить в качестве основного сервера имен с файлом зоны, который вы можете использовать в качестве преобразователя имен для вашей сети или просто для тестирования.

Установка сервера имен на любом имеющемся у вас компьютере GNU/Linux технически возможна, поскольку он не будет мешать другим хостам в сети или их работе. Однако вам, вероятно, не следует делать это на компьютере, которым вы не владеете или на который не имеете права модифицировать, если у вас нет на это явного разрешения.

Мои настройки

Вам нужен только один компьютер для выполнения всех задач, кроме одной, в этом лабораторном проекте. Я использую эту настройку на своем гораздо более мощном ThinkPad, потому что серверы имен, предоставляемые DHCP (протокол динамической конфигурации хоста), когда я подключаюсь к не домашним сетям с использованием проводных или беспроводных подключений, иногда могут быть ненадежными. Чтобы показать, что почти любой хост может хорошо работать в качестве сервера имен, я протестировал этот проект на старом нетбуке ASUS EeePC 900.

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

Файл hosts

Во-первых, давайте взглянем на файл /etc/hosts. В состоянии по умолчанию в файле hosts должно быть только две строки, первые две строки показаны в листинге 1 ниже.

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

Хотя вы можете добавить имена хостов и их соответствующие IP-адреса, как показано в листинге 1, это не оптимальное решение для службы имен, особенно во время путешествий. Если в вашем файле hosts есть другие записи, вам может потребоваться закомментировать их на время этого проекта, если они мешают именованию или IP-адресам. У большинства из вас не будет никаких записей, кроме двух строк по умолчанию.

Подготовка

Прежде чем начать, вы должны подготовиться, выполнив следующие шаги.

Сначала сделайте резервные копии файлов /etc/hosts, /etc/named.conf, resolv.conf и /etc/sysconfig/iptables.

Если они еще не установлены, используйте диспетчер пакетов вашего дистрибутива, чтобы установить следующие RPM-пакеты BIND: bind, bind-chroot и bind-utils. Чтобы ваш лабораторный хост мог использовать кэширующий сервер имен, вы должны добавить строку сервера имен, указывающую на ваш собственный хост, в /etc/resolv.conf. Например, если IP-адрес вашего тестового хоста — 192.168.0.203, как и мой epc, добавьте следующую строку в начало списка серверов имен в /etc/resolv.conf:

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

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

Эти изменения вступят в силу немедленно и не требуют перезагрузки или перезапуска службы. Теперь попробуйте пропинговать общий общедоступный хост, который не блокирует пакеты ICMP (Internet Control Message Protocol); не стесняйтесь использовать мой брандмауэр, которым является Raspberry Pi.

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

Вы должны получить сообщение об ошибке "Время ожидания подключения истекло; нет доступа к серверам".

Настройка кеширующего сервера имен

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

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

Для первоначальной настройки кэширующего сервера имен необходимо внести пару изменений в файл по умолчанию /etc/named.conf, поэтому отредактируйте этот файл в своем любимом редакторе. Сначала добавьте IP-адрес вашего локального тестового хоста в строку «прослушивание порта 53», как показано в листинге 2 ниже. Это позволяет named прослушивать внешний IP-адрес вашего хоста, чтобы другие компьютеры также могли использовать его в качестве сервера имен.

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

Добавьте строку "экспедиторы", как показано ниже. Это сообщает вашему кэширующему DNS-серверу, где получить IP-адреса, если они еще не кэшированы локально. IP-адреса в приведенном ниже списке предназначены для общедоступных DNS-серверов Google. Вы можете использовать своего местного интернет-провайдера, OpenDNS или какой-либо другой общедоступный сервер имен в качестве переадресации. Нет необходимости определять какие-либо серверы пересылки, и в этом случае BIND будет использовать корневые серверы Интернета, как определено в файле /var/named/named.ca, для поиска полномочных серверов имен для доменов, если серверы пересылки не определены. Но для этого упражнения определите серверы пересылки, как показано в листинге 2.

Закомментируйте строку IPV6, поскольку мы не используем IPV6 в тестовой среде. Обратите внимание, что две косые черты "//" обозначают комментарии в файле named.conf.

Листинг 2. Файл /etc/named.conf содержит простую конфигурацию, необходимую для настройки кэширующего сервера имен. Строки, которые необходимо добавить или изменить, выделены жирным шрифтом.

Добавьте локальный сетевой адрес 192.168.0.0/24 в строку allow-query. В этой строке указываются сети, из которых DNS-запросы будут приниматься этим DNS-сервером.

Запустить службу имен

Теперь запустите названную службу и настройте ее так, чтобы она запускалась при каждой загрузке. Я использую команду systemctl на моем хосте Fedora, но команда может отличаться на вашем хосте, в зависимости от используемого вами дистрибутива. Обратите внимание, что имя службы распознавателя BIND называется name.

На этом этапе ваш кеширующий сервер имен будет правильно разрешать хосты в Интернете, потому что эти DNS-запросы для общедоступных хостов перенаправляются на общедоступные серверы имен Google — см. строку «forwarders» в named.conf. Однако вы по-прежнему зависите от файла /etc/hosts для внутренних служб имен. Создание первичного сервера имен может решить эту проблему.

Создание основного сервера имен

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

Два новых файла, которые вы создадите, — это файлы прямой и обратной зон, которые вы поместите в каталог /var/named. Это расположение задается директивой "directory" в файле конфигурации named.conf.

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

Файл прямой зоны содержит записи "A", которые связывают имена хостов в зоне, также называемых доменами, с их соответствующими IP-адресами. Он также может содержать записи CNAME, являющиеся псевдонимами реальных имен хостов в записях A, и записи MX для почтовых серверов.

Первая строка без комментариев в листинге 3 — это спецификатор Time to Live, который в данном случае равен одному дню для всех записей, не указанных иначе. Д означает день. Спецификаторы в строке SOA (Start of Authority) столь же очевидны. Детали параметров в записи SOA подробно описаны здесь.

Запись NS должна иметь полное доменное имя (полное доменное имя) хоста, на котором вы выполняете этот лабораторный проект. Также в файле должна быть запись A с действительным IP-адресом хоста. В этом случае вы должны использовать IP-адрес локального хоста 127.0.0.1.

Записи, показанные выше, дадут вам несколько имен хостов, с которыми можно поэкспериментировать.

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

Добавить файлы зоны переадресации в named.conf

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

Теперь перезапустите named, чтобы изменения вступили в силу. Протестируйте свой сервер имен, используя команды dig и nslookup, чтобы получить IP-адреса для хостов, которые вы настроили в файле зоны переадресации. Обратите внимание, что хост не обязательно должен существовать в сети, чтобы команды dig и nslookup возвращали IP-адрес.

Использование корневых серверов имен

Когда я сделал это, первый вызов для разрешения внешнего адреса для Amazon занял 3857 мс, пока данные были найдены и возвращены. Последующие результаты выполнения того же запроса составили 1 мс, что показывает преимущество локального кэширования результатов преобразователя. Обратите внимание на числа 1800, 300 и 60 в строках раздела ответов и 1831 в строках раздела полномочий — это TTL (время жизни) в секундах. Если вы выполните поиск несколько раз, эти числа будут меняться, показывая количество времени, которое осталось для хранения записей в локальном кэше.

Создание файла обратной зоны

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

Вы также можете назвать файл обратной зоны /var/named/25.168.192.in-addr.arpa, что соответствует старым соглашениям. На самом деле вы можете назвать его как угодно, потому что вы явно укажете на него в файле named.conf, но использование одного из двух соглашений облегчит другим следить за вашей работой.

Добавить обратную зону в named.conf:

Листинг 7. Добавление этого раздела в файл named.conf включает обратный поиск.

Добавьте раздел из листинга 7 в файл /etc/named.conf, чтобы указать на новую обратную зону. Теперь перезагрузите named и протестируйте свою обратную зону, используя команды из листинга 8. Ваши результаты должны выглядеть примерно так, как показано ниже.

Листинг 8. После перезапуска named вы должны увидеть результаты, подобные этим, при обратном просмотре IP-адреса в обратной зоне.

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

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

На данный момент у вас есть работающий сервер имен, использующий BIND. Однако внешние хосты пока не могут использовать этот сервер имен, поскольку брандмауэр еще не должен быть настроен на разрешение запросов DNS.

Настройка IPTables для DNS

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

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

Добавьте правило в свой брандмауэр с помощью firewalld или IPTables, которое разрешает входящие пакеты через порт 53 (домен) для UDP, и сохраните новый набор правил. Не забудьте вставить новое правило после строки -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT, поэтому для этого вам придется подсчитать количество строк INPUT в таблице фильтров. Число 7 в следующей команде означает, что это правило будет вставлено в позицию номер 7 в существующих правилах INPUT.

Вы можете сохранить новые правила брандмауэра, если хотите, и вы бы сделали это, если бы это была постоянная установка, а не лабораторный проект. Затем проверьте это на одном из других ваших хостов, используя команду из листинга 9 ниже. Аргумент @epc указывает команде dig использовать указанный сервер имен с именем хоста epc. Вы должны заменить либо IP-адрес только что созданного DNS-сервера, либо разрешимое имя хоста в вашей сети, указывающее на ваш новый сервер имен. Конечно, вы всегда можете добавить это имя хоста с его IP-адресом в файл /etc/hosts хоста, который вы используете для удаленного тестирования.

Листинг 9. Тестирование преобразователя имен, созданного вами на другом хосте в той же сети.

Очистка

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

Восстановите исходный файл /etc/hosts.
Остановите имя на узле распознавателя, используемом для этого экспериментального проекта.
Отключить указанную службу.
Удалите файлы зоны.
Восстановите исходный файл named.conf.
Восстановите исходный файл resolv.conf.

Заключительные мысли

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

Обратите внимание, что хотя мой маленький EeePC работает со 100% загрузкой ЦП для Seti@Home, он очень быстро отвечает на запросы преобразователя. Вы должны иметь возможность попробовать этот проект на любом доступном хосте Linux с незначительным эффектом. Я надеюсь, что многие из вас попытаются настроить свой собственный сервер имен и поэкспериментировать с ним. Особенности установки вашего сервера имен будут зависеть от деталей вашего хоста и сети.

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

Но вместо того, чтобы говорить о проблемах, мне интересно выяснить – почему это хорошо, что DNS децентрализован?

почему хорошо, что DNS децентрализован?

Одна из причин – масштабируемость: децентрализованная структура DNS упрощает масштабирование и повышает устойчивость к сбоям. Я нахожу действительно удивительным, что DNS все еще хорошо масштабируется, несмотря на то, что ему почти 40 лет. Это очень важно, но этот пост не об этом.

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

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

вы можете использовать 2 типа DNS-серверов

Существует 2 основных типа DNS-серверов, которые вы можете использовать:

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

DNS — это не статическая база данных

Я часто встречал метафору DNS с "телефонной книгой", где доменные имена похожи на имена, а IP-адреса - на номера телефонов.

Какую запись вы получите в ответ на запрос DNS, может зависеть от:

где вы находитесь в мире (возможно, вы получите IP-адрес сервера, который физически ближе к вам!)
если вы находитесь в корпоративной сети (где вы можете разрешать внутренние доменные имена)
считает ли доменное имя «плохим» ваш преобразователь DNS (оно может быть заблокировано!)
предыдущий запрос DNS (возможно, преобразователь DNS выполняет балансировку нагрузки на основе DNS, чтобы каждый раз выдавать вам другой IP-адрес)
независимо от того, используете ли вы авторизованный портал Wi-Fi в аэропорту (перед входом в систему Wi-Fi в аэропорту будет по-разному разрешать записи DNS, он отправит вам специальный IP-адрес для перенаправления)
буквально что угодно

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

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

Эти причины не расположены в каком-то определенном порядке.

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

Для ясности: существует множество причин не запускать собственный авторитетный сервер имен — я не использую свой собственный и не пытаюсь убедить вас в этом. Требуется время на обслуживание, ваш сервис может быть не таким надежным и т. д.

причина: безопасность

[Существует] риск того, что злоумышленник получит доступ к изменению DNS через сотрудников службы поддержки вашего поставщика, которые хотят только помочь.Или быть заблокированным от вашего DNS (возможно, из-за его отсутствия). Внутри компании может быть проще проводить аудит и проверять содержимое.

причина: вам нравится запускать bind/nsd

Одна из причин, по которой упомянули несколько человек, заключалась в том, что «я привык писать файлы зон и запускать bind или nsd , мне проще это сделать».

Если вам нравится интерфейс bind/nsd, но вы не хотите управлять своим собственным сервером, несколько человек упомянули, что вы также можете получить преимущества bind, запустив «скрытый первичный» сервер, на котором хранятся записи, но обслуживать все фактические DNS-запросы с «дополнительного» сервера. Вот несколько страниц, которые я нашел о настройке вторичного DNS из NS1 и cloudflare и Dyn в качестве примера.

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

причина: вы можете использовать новые типы записей

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

причина: пользовательский интерфейс

Вам может не понравиться пользовательский интерфейс (или API, или отсутствие API) используемой вами службы DNS. Это в значительной степени связано с причиной «вам нравится работать с BIND» — возможно, вам нравится интерфейс файла зоны!

причина: вы можете исправить проблемы самостоятельно

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

причина: сделать что-то странное и нестандартное

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

У Replit есть сообщение в блоге о том, почему они создали собственный авторитетный DNS-сервер для обработки карт маршрутизации 10.0.0.1.nip.io и 10.0.0.1.
Я написал собственный DNS-сервер для путаницы с DNS

причина: экономия денег

Похоже, что авторитетные серверы имен обычно взимают плату за миллион DNS-запросов. Например, на первый взгляд кажется, что Route 53 взимает около 0,50 долларов США за миллион запросов, а NS1 — около 8 долларов США за миллион запросов.

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

причина: вы можете сменить регистратора

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

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

причина: гео DNS

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

Это услуга, предлагаемая многими авторитетными службами серверов имен, для этого вам не нужно писать свою собственную.

причина: избегать атак типа "отказ в обслуживании", направленных против кого-то еще

причина: хранить всю конфигурацию в одном месте

Один человек упомянул, что ему нравится хранить всю свою конфигурацию (записи DNS, let’s encrypt, nginx и т. д.) в одном месте на одном сервере.

дикая причина: использовать DNS как VPN

Очевидно, iodine — это авторитетный DNS-сервер, который позволяет вам туннелировать трафик через DNS, если вы находитесь в сети, которая позволяет вам связываться с внешним миром только через VPN.

причины запуска распознавателя

причина: конфиденциальность

Если кто-то может видеть все ваши запросы DNS, значит, у него есть полный список всех доменов, которые вы (или все сотрудники вашей организации) посещаете! Вы можете предпочесть сохранить это в тайне.

причина: блокировка вредоносных сайтов

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

Несколько примеров распознавателей, которые вы можете запустить самостоятельно (или просто использовать):

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

причина: получить динамическое проксирование в nginx

Вот интересная история из этого твита:

Я записал DNS-сервер в приложение, а затем установил его в качестве резолвера nginx, чтобы получить динамическое проксирование серверной части без необходимости использования nginx для запуска lua. Nginx отправляет DNS-запрос в приложение, приложение запрашивает Redis и отвечает соответствующим образом. Это отлично сработало для того, что я делал.

причина: избегайте вредоносных распознавателей

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

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

причина: разрешение внутренних доменов

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

причина: избегайте MITM-запросов на ваши DNS-запросы

это пока все

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

Спасибо Мари и Камалю за обсуждение этого поста, а также всем в Твиттере, кто указал причины

Вам также может понравиться Recurse Center, мое самое любимое сообщество программистов (мои посты о нем)

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

Я добился этого методом проб и ошибок, и теперь он почти не требует обслуживания, хотя у меня дома нет статического IP-адреса.

Здесь я рассказываю о том, как (и почему) я продолжаю упорствовать в этом стремлении.

Обзор

Это обзор настройки:

Вот как я настроил свой DNS. я:

получил домен от авторитетного источника (в моем случае это домен .tk)
настроить связующие записи, чтобы откладывать DNS-запросы к моим серверам имен
настроить серверы имен со статическими IP-адресами
настроить средство динамического обновления DNS из дома

Пошаговое описание того, как я это сделал:

1) Настройте два виртуальных частных сервера (VPS)

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

Если вам не посчастливилось иметь их у себя, вы можете настроить их в облаке. Я использовал этот сайт, но там много. NB Я спросил их, и их IP-адреса являются статическими для каждого VPS. Я использую самый дешевый облачный VPS (1$ в месяц) и устанавливаю там Debian.

ПРИМЕЧАНИЕ. Замените любое упоминание DNSIP1 и DNSIP2 ниже первым и вторым статическими IP-адресами, которые вы получили.

Войти и установить пароль root

SSH для подключения к серверам и установите надежный пароль root.

2) Настроить домены

Вам потребуется два домена: один для ваших DNS-серверов и один для приложения, работающего на вашем хосте.

Я использую dot.tk для получения бесплатных одноразовых доменов. В этом случае я могу настроить DNS-домен myuniquedns.tk и домен сайта myuniquesite.tk.

Что бы вы ни выбрали, замените домен DNS, когда увидите YOURDNSDOMAIN ниже. Точно так же замените домен приложения, когда увидите YOURSITEDOMAIN ниже.

3) Настройте «связующую» запись

Если вы используете dot.tk, как описано выше, то для управления доменом YOURDNSDOMAIN вам потребуется настроить «связующую» запись.

Это означает, что текущий орган управления доменом (dot.tk) должен подчиняться вашим серверам имен (двум серверам, которые вы настроили) для этого конкретного домена. В противном случае он продолжает ссылаться на домен .tk для IP-адреса.

Подробнее см. здесь.

Еще одно хорошее объяснение здесь.

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

У dot.tk есть веб-интерфейс для настройки связующей записи, поэтому я использовал его.

Там вам нужно перейти в «Управление доменами» => «Управление доменом» => «Инструменты управления» => «Зарегистрировать Glue Records» и заполнить форму.

Ваши два хоста будут называться ns1.YOURDNSDOMAIN и ns2.YOURDNSDOMAIN , а связующие записи будут указывать на любой из IP-адресов.

Примечание. Возможно, вам придется подождать несколько часов (или дольше), чтобы изменения вступили в силу. Если вы действительно не уверены, подождите один день.

Купить пакет здесь

4) Установите привязку на DNS-серверах

На компьютере с Debian (например) и от имени пользователя root введите:

подходящая установка bind9

bind — это программное обеспечение сервера доменных имен, которое вы будете использовать.

5) Настройте привязку на DNS-серверах

А теперь самое интересное.

Здесь есть две части с двумя задействованными файлами: named.conf.local и файл db.YOURDNSDOMAIN.

Они оба находятся в папке /etc/bind. Перейдите туда и отредактируйте эти файлы.

Часть 1 — named.conf.local

В этом файле перечислены зоны (домены), обслуживаемые вашими DNS-серверами.

Он также определяет, является ли этот экземпляр привязки «главным» или «подчиненным». Я предполагаю, что ns1.YOURDNSDOMAIN является «главным», а ns2.YOURDNSDOMAIN — «подчиненным».

Часть 1а — мастер

На master/ ns1.YOURNDSDDOMAIN файл named.conf.local должен выглядеть следующим образом:

Журналирование внизу является необязательным (я думаю). Я добавил это некоторое время назад, и я оставлю это здесь для интереса. Я не знаю, о чем идет речь в разделе о зоне 14.127.

Часть 1b — раб

На подчиненном устройстве / ns2.YOURNDSDDOMAIN файл named.conf.local должен выглядеть следующим образом:

Часть 2 – db.YOURDNSDOMAIN

Теперь мы подошли к сути — ваша база данных DNS хранится в этом файле.

На главном сервере / ns1.YOURDNSDOMAIN файл db.YOURDNSDOMAIN выглядит следующим образом:

На ведомом сервере/ ns2.YOURDNSDOMAIN все очень похоже, но в строке SOA ns1, а в строке IN NS наоборот. Я не могу вспомнить, нужен ли этот разворот или нет…:

Несколько замечаний по вышеизложенному:

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

6) Копировать ключи ssh

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

ПРИМЕЧАНИЕ. Это не совет по безопасности. Используйте на свой страх и риск.

Сначала проверьте, не сгенерирован ли уже ключ ssh:

Если это возвращает файл, все настроено. В противном случае введите:

и примите значения по умолчанию.

Затем, когда вы настроите ключ, скопируйте свой идентификатор ssh на серверы имен:

Ввод пароля root для каждой команды.

7) Создайте сценарий обновления IP

Теперь подключитесь по ssh к обоим серверам и поместите этот скрипт в /root/update_ip.sh :

Сделайте его исполняемым, запустив:

chmod +x /root/update_ip.sh

Построчно:

Эта строка выдает ошибку, если IP-адрес не передается в качестве аргумента скрипта.

sed -i "s/^(.*) IN A (.*)$/1 IN A $1/" /etc/bind/db.ВАШ DNSDOMAIN

Заменяет IP-адрес содержимым первого аргумента скрипта.

sed -i "s/.*Serial$/ $(date +%Y%m%d%H); Serial/" /etc/bind/db.ВАШDNSDOMAIN

Увеличивает «серийный номер»

Перезапустите службу привязки на хосте.

8) Cron — ваш динамический DNS

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

Вот необработанная запись cron:

Пошаговое объяснение этой команды:

Это скручивает сайт "какой у меня IP-адрес" и помещает вывод в /tmp/ip.tmp

Это отличает содержимое /tmp/ip.tmp от /tmp/ip (который еще не создан и содержит последний обновленный IP-адрес). Если возникает ошибка (т. е. на DNS-сервере есть новый IP-адрес для обновления), то запускается подоболочка. Это перезаписывает IP-адрес, а затем подключается по ssh к

Тот же процесс повторяется для DNSIP2 с использованием отдельных файлов ( /tmp/ip.tmp2 и /tmp/ip2 ).

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

Это дешево

Стоимость этого остается равной стоимости двух серверов имен (24 долл. США в год), независимо от того, сколькими доменами я управляю и что с ними делаю.

Обучение

Благодаря этому я многому научился, возможно, гораздо большему, чем любой другой курс.

Больше контроля

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

Купить пакет здесь

Если вам понравился этот пост, вам также могут понравиться:

Если вам понравилось, купите мне кофе, чтобы побудить меня делать больше.

Читайте также: