Как сделать DNS-сервер в локальной сети
Обновлено: 02.07.2024
DNS (служба доменных имен) — это служба, обеспечивающая преобразование доменного имени в IP-адрес для компьютеров в Интернете.
Все эти компьютеры имеют общедоступное доменное имя, присвоенное Интернет-организацией ICANN (Интернет-корпорация по присвоению имен и номеров).
Записи доменных имен и IP-адресов хранятся на DNS-серверах, расположенных во многих местах.
Для домашних сетей службы DNS обычно предоставляются их интернет-провайдером (интернет-провайдером).
Устройства домашней сети и DNS
Устройства домашней сети, такие как компьютеры, не имеют общедоступного доменного имени и, следовательно, не имеют или не нуждаются в записи в глобальной базе данных DNS.
Так как же найти устройства в домашней сети, если, например, вам нужен доступ к локальной папке или принтеру?
Ну, DNS — не единственный вариант разрешения имен, возможны и другие методы, которые используются. Доступные методы: широковещательная рассылка, хосты, победы и т. д. Подробнее см. в разделе о разрешении локальных имен в домашних сетях.
Однако с ростом использования интеллектуальных устройств становится популярным использование локального DNS-сервера для локального разрешения имен.
DNS-сервер DNSMasq
DNSMasq — это бесплатный DNS- и DHCP-сервер для небольших компьютерных сетей, который входит в состав большинства дистрибутивов Linux.
В моей домашней установке он установлен на raspberry pi 3, который я также использую в качестве сервера MQTT и также запускаю сетевые потоки node-red.
Понимание процесса разрешения имен DNS
Когда вы вводите веб-адрес в веб-браузере, веб-браузер сначала будет использовать протокол DNS для связи с DNS-сервером, настроенным для этого устройства.
DNS-сервер ответит на запрос разрешения IP-адресом веб-сайта или возвратит сообщение о том, что не найдено.
После того как браузер получит IP-адрес веб-сайта, он сможет к нему подключиться.
Если процесс DNS завершается сбоем, в браузере отображается не найденный сервер.
Этот процесс одинаков для всех приложений. электронная почта, Skype и т. д. Все они используют DNS, работающий в фоновом режиме.
Адреса DNS-серверов
Адреса DNS-серверов обычно присваиваются клиентскому компьютеру DHCP-сервером, но также могут быть назначены вручную (см. пример в руководстве «Статический IP-адрес в Windows 10»).
Для резервирования обычно назначаются два адреса DNS-сервера.
В Windows вы можете просмотреть адреса с помощью команды ipconfig.
Настройка и использование собственного локального DNS-сервера
Процесс использования собственного локального DNS-сервера для разрешения локальных имен выглядит следующим образом:
Установка DNSMasq
Перед установкой DNSMasq важно, чтобы у вашего компьютера был фиксированный IP-адрес.
Это можно сделать локально, отредактировав файл dhcp.conf или воспользовавшись сетевой утилитой GUI.
Однако лучше всего настроить его на уровне маршрутизатора.
Почти все маршрутизаторы позволяют назначать фиксированный IP-адрес устройству.
Для установки в Linux (например, Ubuntu, Raspberry Pi) используйте:
Настройка DNSMasq
Как и почти все приложения Linux, конфигурация осуществляется через текстовый файл /etc/dnsmasq.
Способ его настройки заключается в том, что все локальные DNS-запросы обрабатываются непосредственно сервером DNSMasq, а другие, предназначенные для внешних ресурсов, перенаправляются на DNS-серверы, которые вы обычно используете. Это показано на диаграмме ниже:
Хотя DNSMasq можно использовать как DHCP-сервер, я использую его просто как DNS-сервер, поэтому конфигурация DHCP не используется.
Хотя вы можете использовать файл /etc/dnsmasq.conf и раскомментировать нужные вам настройки, я предпочитаю использовать свои собственные и копировать исходный файл для безопасного хранения.
Домен в локальной сети
Хотя на самом деле он вам не нужен, я думаю, что лучше его использовать. Приложение G. Частные пространства имен DNS рекомендуют эти имена для внутренних сетей
Обратите внимание, что вы не должны использовать .local, так как он используется mDNS.
Пример файла конфигурации
Это файл конфигурации, который я использую в своей сети.
На снимке экрана выше видно, что я использую доменное имя .home. Таким образом, все мои машины будут иметь вид name.home, это вы можете увидеть в файле hosts (показано позже).
Вы можете ускорить DNS-запросы для своей домашней сети, увеличив размер кэша с помощью
По умолчанию 150 записей. Вы даже можете использовать большое число, так как каждая запись занимает всего 100 байт, но я не уверен, что вы заметите разницу.
Файл hosts
DNSMasq использует локальный локальный файл хоста для имен машин, поэтому вам нужно будет отредактировать его, указав имена ваших локальных машин. Ниже приведен мой текущий файл hosts.
Если вы внесете изменения в файл hosts, вам потребуется перезапустить DNSMasq, чтобы эти изменения вступили в силу.
Следующие команды вам пригодятся:
Тестирование DNSMasq
Прежде чем настраивать клиентов для его использования, необходимо проверить, работает ли он должным образом.
Для этого используйте инструмент nslookup. Следующий снимок экрана сделан на компьютере с Windows 10.
Первое, что я делаю, это выбираю сервер DNSMasq с IP-адресом 192.168.1.21, а затем просто ввожу несколько имен, которые, как я знаю, настроены, а затем проверяю внешние доменные имена с помощью Google.
Настройка клиентов
Самый простой и рекомендуемый способ — использовать DHCP-сервер для назначения DNS-адреса.
Поскольку назначены два адреса, вы назначите локальный адрес и адрес интернет-сервера.
Затем вам нужно подождать, пока клиенты обновят свой IP-адрес, и они подберут DNS-сервер.
Распространенные вопросы и ответы
В1. Действительно ли необходим локальный DNS-сервер?
A1- Нет, не для большинства домашних сетей?
Вопрос 2. Ускорит ли это мою работу в Интернете?
A2- Да, так как многие адреса будут кэшироваться локально.
Вопрос 3 – Нужно ли это для домашней автоматизации?
A3 Нет, но так будет проще.
В4. Что произойдет, если мой локальный DNS-сервер недоступен?
A4- Клиенты будут использовать общедоступный DNS-сервер, который вы настроили
В5. Почему бы просто не использовать MDNS?
A6 Это было бы идеально, но не все клиенты поддерживают его.
Обзор
Наличие локального DNS-сервера очень полезно при наличии большого количества локальных компьютеров и активности в локальной сети.
Это также будет важно для устройств домашней автоматизации, использующих IP.
Кроме того, он также должен ускорить работу в Интернете, поскольку использует локальный кеш.
Однако это требует настройки другого оборудования и не рекомендуется для нетехнических специалистов.
У меня есть небольшая домашняя сеть, которая только что стала больше (новая соседка по комнате, моя соседка по комнате получила ноутбук (поверх ее компьютера), мои друзья приходят с ноутбуками и т. д.).
Я хочу запустить локальный DNS-сервер для поиска информации в моей локальной сети (fileserver.local, windowsTV.local, machineA.local, machineB.local, appletv.local). Раньше у меня была бизнес-линия со статическим IP-адресом, и я запускал bind/named внутри. Однако теперь у меня есть обычный аккаунт.
DNS-серверы моего интернет-провайдера постоянно меняются (по каким-то причинам мой интернет-провайдер не любит долго сохранять один и тот же диапазон IP-адресов). Мне нужно, чтобы мой локальный DNS автоматически обновлялся, чтобы использовать DNS моего интернет-провайдера для внешнего трафика, но иметь возможность поддерживать внутренний DNS-сервер (обновление файла hosts создает проблемы с каждой новой машиной поверх восстановления существующих машин с win7 или Ubuntu 9.04).
Кроме того, DNS-серверы My ISP часто выходят из строя или перестают отвечать на запросы. Существуют ли какие-либо надежные открытые DNS-серверы (я не хочу перенастраивать их каждый день), которые я мог бы использовать в качестве основного, а если они не сработают, то использовать моих интернет-провайдеров?
ОБНОВЛЕНИЕ: Также ищу, чтобы каждая рабочая станция могла использовать dhcp для подключения, но вместо того, чтобы получать DNS-серверы провайдера, получаю свой внутренний.
Я согласен, но я ищу общее решение. каждый вопрос сам по себе будет иметь правильный ответ, но может не совпадать, я пытаюсь найти решение обеих проблем, которое работает вместе.
@RoyRico Вы когда-нибудь находили хорошее решение? Я пытаюсь сделать то же самое с маршрутизатором Tomato и натыкаюсь на стены во всех направлениях.
15 ответов 15
Если вы хотите, чтобы внутренние поддельные домены работали, вы не можете настраивать на своих рабочих станциях какие-либо DNS-серверы, кроме своих собственных. После того, как вы настроите BIND, он сможет работать сам по себе, и вам вообще не понадобятся ни поставщики услуг Интернета, ни какие-либо другие неавторизованные DNS-серверы.
Однако хороший пользователь сети, если это возможно, будет перенаправлять в кэш DNS своего интернет-провайдера. Нагрузка на корневые DNS-серверы ужасна.Особенно для небольших сайтов, таких как этот, потому что он не будет масштабироваться, если каждое домашнее хозяйство решит пойти напрямую. (Если вы беспокоитесь о несанкционированном доступе к провайдеру, используйте DNSSEC).
@sourcejedi, вы неправильно понимаете, что на самом деле делает кеширующий DNS-сервер.. он, конечно, не работает с корневыми серверами, он беспокоит их только раз в неделю.
Есть и другая причина, по которой вам следует перенаправлять на DNS-серверы вашего интернет-провайдера. вы будете выглядеть для них обычным клиентом. Если вы этого не сделаете, и они увидят, что у вас есть система, которая отправляет DNS-запросы по всему миру, они решат, что вы используете DNS-сервер, и могут просто бросить вам в лицо правило брандмауэра и облить вас водой. Вы будете изо всех сил пытаться понять, что сломалось, и, возможно, потратите часы, пытаясь понять, когда это произойдет.
В дополнение к мнению @milli, DNS вашего интернет-провайдера также может переопределить разрешение некоторых доменов на их частные машины с более быстрым/кэшированным/неизмеряемым контентом. Использование общедоступного DNS может нарушить работу этих служб или привести к дополнительным расходам.
В основном вам нужно запустить собственный сервер DHCP и DNS. У вас уже есть собственный DHCP-сервер, если у вас есть обычный маршрутизатор, который выдает частные IP-адреса.
Ваш DHCP-сервер должен быть настроен на выдачу IP-адреса вашего маршрутизатора в качестве адреса шлюза и IP-адреса вашего DNS-сервера в качестве адреса DNS-сервера, разумеется.
Ваш DNS-сервер должен быть настроен на локальное разрешение неофициального домена верхнего уровня, например .local , а затем перенаправлять любые другие запросы на другой DNS. В BIND вам нужно добавить раздел forwarders < > в файл `/etc/bind/named.conf.options', который содержит общедоступные DNS-серверы, которые вы хотите использовать для разрешения нелокальных адресов. Как предполагают другие комментарии, если вы не хотите перенаправлять на DNS-серверы вашего интернет-провайдера, вы можете использовать OpenDNS, общедоступные DNS-серверы Google или 4.2.2.1/4.2.2.2 (я забыл, кто это делает).
Если у вас есть собственный DNS-сервер, вам нужен ящик, который будет включен все время, так как все DNS-запросы в вашей домашней сети будут проходить через него. Этому ящику нужен фиксированный IP-адрес в вашей домашней подсети. Убедитесь, что он не может быть заблокирован DHCP, а сама коробка не должна получать IP-адрес через DHCP. Если ваш DHCP настроен, например, на раздачу адресов от 192.168.1.1 до 192.168.1.100, дайте вашему DNS-серверу IP-адрес 192.168.1.101. В обычной ситуации с домашними маршрутизаторами вам просто нужно указать маршрутизатору, что DNS-сервер — 192.168.1.101, и перезагрузить компьютер.
Если вы можете запустить локальный DNS на своем широкополосном маршрутизаторе, прекрасно, но DNS-серверу может быть полезен большой объем оперативной памяти для кэширования запросов, в зависимости от того, какое программное обеспечение DNS вы используете. В моей сети я просто использую прямой BIND. Похоже, у вас может быть небольшой опыт в этом, и для меня это отлично работает.
Процесс преобразования имени компьютера или доменного имени в IP-адрес известен как разрешение имен, а для служб в Интернете это выполняется службой, называемой преобразованием доменных имен (DNS).
DNS (системы доменных имен) – это система разрешения имен для компьютеров, расположенных в Интернете.
Службы DNS предоставляются Google и другими провайдерами, такими как ваш интернет-провайдер (интернет-провайдер).
Имена компьютеров и доменные имена —
Имя компьютера не имеет структуры и часто используется в домашних сетях Windows. например рабочая станция6
Доменные имена не распространены в домашних сетях, поскольку в домашних сетях обычно не так много устройств и нет локальной службы DNS.
Разрешение имени
Однако в домашних сетях принято использовать имена при доступе к службам на других компьютерах в домашней сети.
При просмотре других компьютеров в сетевом окружении они перечислены по имени, а не по IP-адресу.
Компьютеры с Windows имеют несколько методов разрешения имен, и при разрешении имени компьютер с Windows может попробовать несколько разных методов.
- Файл локальных узлов
- Кэш имен Netbios
- Трансляция
Файл локальных хостов
В Windows XP, Windows 7 файл hosts находится в папке c:\windows\system32\drivers\etc\,
Примечание. Он может быть скрыт, поэтому вам потребуется включить просмотр скрытых файлов, чтобы увидеть его, и вам может потребоваться открыть его от имени администратора.
Вот пример основного файла хоста:
Кэш имен Netbios
Когда машина Windows разрешает имя, она временно сохраняет его в памяти.
Это означает, что если вы снова получите доступ к этому компьютеру, ему не нужно будет снова разрешать имя.
Вы можете просмотреть этот кэш с помощью команды nbtstat.
Трансляция
Это основной метод разрешения имен в домашней сети Windows.
Машина просто спрашивает все другие машины, есть ли у них конкретное имя, и если да, то они отвечают своим IP-адресом.
Вещание не работает через маршрутизаторы, но обычно это не проблема в домашних сетях, поскольку в них есть только один маршрутизатор, обращенный к Интернету, и поэтому он не влияет на разрешение имен в домашней сети.
Другие методы
в других руководствах вы можете встретить упоминания файла LMhosts и Wins.
LMhosts — это, по сути, файл hosts, но для имен Windows. Он требует настройки и обычно не используется. Он находится в той же папке, что и файл hosts.
Выигрывает в Windows, эквивалентной DNS, и требует сервера, на котором работает служба, и опять же обычно не используется
Многоадресная рассылка DNS. Многоадресная рассылка DNS — это новое дополнение к разрешению имен, которое недавно было добавлено во все операционные системы, включая Windows. Вероятно, в будущем этот механизм станет стандартным. См. Общие сведения о многоадресных DNS и обнаружении служб. (скоро)
Распространенные вопросы и ответы
В. Могу ли я установить и настроить собственный локальный DNS-сервер для разрешения локальных имен?
A- Да, но это не простая задача. В Linux (Pi) популярным выбором является DNSMasq.
В. Что происходит в смешанных сетях, например в Windows и Linux?
A- Это зависит от того, как они настроены. На приведенном ниже снимке экрана показано, что я могу пропинговать raspberry pi со своего компьютера с Windows.
Однако это может не работать с Pi на Windows. Если нет, то вам нужно отредактировать файл /etc/nsswitch
изменить:
hosts: files mdns4_minimal [NOTFOUND=return] dns
на
hosts: файлы mdns4_minimal [NOTFOUND=return ] DNS побеждает
и установите libnss-winbind
используя:
См. конец этой темы
Локальное доменное имя Домашняя сеть
Домен верхнего уровня .local зарезервирован для домашних сетей и используется MDNS (многоадресная DNS).
Если вы настраиваете собственный локальный DNS-сервер, список рекомендуемых имен выглядит следующим образом: (Приложение G. Частный DNS)
Для домашних сетей лучше всего подходит домен .home.
В. Что такое доменное имя .local?
A- Это зарезервированное доменное имя используется службой mdns.
В предыдущей статье этой серии, состоящей из двух частей, "Введение в 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 с незначительным эффектом. Я надеюсь, что многие из вас попытаются настроить свой собственный сервер имен и поэкспериментировать с ним. Особенности установки вашего сервера имен будут зависеть от деталей вашего хоста и сети.
Читайте также: