Нужно ли прописывать dns в локальной сети
Запуск собственного DNS-сервера — отличный способ повысить быстродействие вашей сети, снизить зависимость от общедоступной инфраструктуры и воспользоваться дополнительными функциями, такими как маршрутизация имени хоста. Вот как настроить DNS-сервер на Linux-машине с помощью Dnsmasq.
Зачем нужен собственный DNS?
Наличие собственного DNS-сервера позволяет централизовать настройки в одном месте вместо того, чтобы применять их индивидуально в / etc / hosts на каждом устройстве. Они будут применяться ко всему, что вы подключаетесь к своей сети, включая встроенное оборудование, которое не предоставляет другого способа настроить свой стек маршрутизации.
Собственный DNS-сервер также может повысить производительность и обеспечить дополнительный уровень устойчивости. Широкомасштабные сбои DNS не являются чем-то неслыханным; Использование настраиваемого сервера с долговечным кешем для критически важных служб, с которыми вы взаимодействуете, может помочь вам избежать простоев у выбранного вышестоящего провайдера.
Заключение
DNS — сложная тема, но Dnsmasq упрощает запуск базового сервера. Здесь очень много больше настроек который вы можете изучить, когда у вас заработает основная функциональность. Они позволяют фильтровать запросы, управлять ретрансляторами и прокси, запускать сценарии при возникновении событий и настраивать другие типы записей DNS, такие как результаты MX для почтовых серверов.
После запуска Dnsmasq обычно не требует большого ручного вмешательства. Вы можете отслеживать журналы с помощью службы dnsmasq status или systemctl status dnsmasq. Теперь вы готовы использовать свой собственный DNS-сервер, максимизируя производительность и позволяя использовать внутренние доменные имена для доступа к устройствам в локальной сети.
Одна из сложностей в понимании DNS заключается в его децентрализованности. Существуют тысячи (а может, сотни тысяч?) авторитетных серверов имён и по крайней мере 10 миллионов резолверов. На них работает множество разного ПО! Из-за того, что на разных серверах выполняется своё ПО, в работе DNS присутствует большая несогласованность, что может вызывать кучу раздражающих проблем.
Но вместо того, чтобы обсуждать проблемы, я хочу разобраться, почему децентрализация DNS — это хорошо?
Причины для создания резолвера
Причина: конфиденциальность
Если кто-то может видеть все ваши операции DNS-поиска, то у него будет полный список доменов, которые вы (или кто-то из вашей организации) посещаете! Возможно, вы захотите сохранить их конфиденциальность.
Причина: блокировка вредоносных сайтов
Если вы создали собственный резолвер, то вы можете отказаться резолвить DNS-запросы (просто не возвращая никаких результатов) для доменов, которые вы считаете «плохими».
Вот несколько примеров резолверов, которые вы можете создать сами (или просто использовать):
-
блокирует рекламодателей. блокирует домены, занимающиеся вредоносными программами/фишингом/шпионским ПО. Похоже, у Cloudflare есть похожий сервис.
- Думаю, существует также ПО для корпоративной безопасности, блокирующее DNS-запросы доменов, хостящих вредоносные программы.
- DNS — это не статичная база данных. Он очень динамичен, и ответы иногда могут в реальном времени зависеть от IP-адреса, с которого пришёл запрос, текущей нагрузки на контент серверов и т. д. Всё это сложно делать, в реальном времени, если вы не делегируете обслуживание таких записей сущности, принимающей подобные решения.
- Делегирование управления DNS сильно упрощает управление доступом. Всё ниже среза зоны (zone cut) контролируется человеком, управляющим делегированным сервером, поэтому ответственность за имя хоста подразумевается в делегировании DNS.
Причина: получить динамическое проксирование в nginx
Вот отличная история из этого твита:
Я написал DNS-сервер в виде приложения, а затем сделал его резолвером для nginx, чтобы можно было получить динамическое проксирование бэкенда без необходимости запуска lua в nginx. Nginx отправляет DNS-запрос приложению, приложение запрашивает redis и отвечает соответствующим образом. Для моих целей такое решение сработало очень неплохо.
Причина: избежать злонамеренных резолверов
У некоторых ISP есть DNS-резолверы, делающие плохие вещи, например, резолвящие несуществующие домены в контролируемые ими IP, которые показывают рекламу или странную поисковую страницу, которую они могут контролировать.
Чтобы избежать этого, можно использовать или контролируемый вами резолвер, или другой резолвер, которому вы доверяете.
Причина: резолвинг внутренних доменов
Можно сделать то же самое в домашней сети, или для доступа к локальным сервисам, или просто чтобы получить локальные адреса для сервисов, находящихся в публичном Интернете.
Причина: избежать MITM своих DNS-запросов
DNS с Dnsmasq
Dnsmasq — это легкий DNS-сервер, входящий в состав большинства дистрибутивов Linux. Кроме того, его очень просто настроить.
Перед тем, как начать, стоит подумать о том, какие функции вам нужен ваш DNS-сервер. В этом руководстве мы рассмотрим настройку Dnsmasq с локальным кэшированием, некоторыми маршрутами пользовательских доменов и Google 8.8.8.8 в качестве нашего восходящего DNS-провайдера.
Схема маршрутизации будет выглядеть так:
Вам не нужно будет вносить какие-либо изменения в конфигурацию на ваших клиентских устройствах. Все, что находится за вашим маршрутизатором, в конечном итоге будет делать DNS-запросы через Dnsmasq. Однако стоит отметить, что все популярные настольные и мобильные операционные системы поддерживают настройку DNS-сервера, поэтому вы можете настроить отдельные устройства для использования Dnsmasq, не включая его на уровне маршрутизатора.
Чем хороша децентрализация DNS?
Одна из причин — это масштабируемость: децентрализованная структура DNS упрощает его масштабирование и делает его более устойчивым к сбоям. Мне кажется по-настоящему удивительным то, что DNS продолжает масштабироваться, несмотря на то, что ему почти 40 лет. Это очень важно, но наш пост не об этом.
Вместо этого я хотела бы поговорить о следующем: децентрализованность означает, что мы можем управлять тем, как работает DNS. Мы можем добавить новые серверы в огромный запутанный клубок DNS-серверов! Серверы, которыми можно управлять!
Сопоставление имен хостов IP-адресам
Есть несколько разных способов сопоставить имена хостов с их IP-адресами. Самый простой — добавить записи в существующий файл вашего сервера / etc / hosts. Dnsmasq автоматически загружает правила из этого файла как часть своей конфигурации по умолчанию.
Откройте / etc / hosts и добавьте свои маршруты в конец файла. Сначала идет IP-адрес, а затем имя, которое нужно назначить:
192.168.0.101 веб-сервер 192.168.0.105 gateway.lan
Что такое DNS и домены в сети?
DNS-сервер обеспечивает преобразование ip-адреса в доменное имя и наоборот, получая данные для преобразования из собственной базы данных – то есть, все DNS-сервера в мире хранят информацию обо всех компьютерах и серверах в информационной сети. Достигается это “разграничением обязанностей” – структура DNS в сети включает себя домены и поддомены, зоны и узлы.
Что касается DNS, то каждый поддомен управляется собственным DNS-сервером, условно называемым “зоной”, а каждый сетевой компьютер, принтер или сервер – узлом. Зона ответственна только за компьютеры в своей сети, и хранит информацию только об этих ресурсах
Если из вышестоящей DNS-зоны [DNS-1] понадобится сделать запрос в нижестоящую [DNS-2] – то сервер DNS-1 обратится непосредственно к DNS-2, который уже перешлет запрос на нужный хост [узел].
Что такое DNS?
Это увеличивает накладные расходы на каждый ваш запрос. Несмотря на то, что ваше устройство будет кэшировать ответы DNS, при посещении новых доменов DNS будет возвращаться до начала фактического запроса. Это происходит на уровне сетевого стека ОС, невидимым для вас как пользователя.
Интернет-провайдеры обычно используют DNS-серверы. Вы, вероятно, полагаетесь на сервер вашего интернет-провайдера, если используете настройки по умолчанию на вашем маршрутизаторе и устройствах. Другие общедоступные DNS-серверы доступны у таких поставщиков, как Cloudflare а также Google.
Тестирование вашего сервера
Перезапустите Dnsmasq, чтобы применить все ваши изменения:
перезапуск службы sudo dnsmasq
Убедитесь, что сервер работает правильно:
статус службы sudo dnsmasq
Вы должны увидеть, что активный (работает) отображается зеленым цветом. Если вы этого не сделаете, проверьте строки журнала в нижней части информации о состоянии, чтобы выяснить, что не так.
Теперь вы готовы протестировать свой сервер. Вы можете делать попытки поиска DNS вручную с помощью инструмента dig. Возможно, вам сначала потребуется установить пакет dnsutils.
Настройка вашей сети
Последний шаг — настроить сетевой маршрутизатор для поиска DNS через сервер Dnsmasq. В шаги для этого будет варьироваться в зависимости от используемого вами оборудования маршрутизации.
Как только вы найдете страницу с правильными настройками, установите IP-адрес вашего сервера (192.168.0.1 в этом руководстве) в качестве основного DNS-сервера маршрутизатора. Рекомендуется настроить общедоступного поставщика DNS, например Google 8.8.8.8, в качестве вторичного сервера. Это гарантирует, что у вас по-прежнему будет доступ в Интернет, если ваш DNS-сервер выйдет из строя и отключится.
Теперь все устройства, подключенные к вашему маршрутизатору, будут делать DNS-запросы через ваш экземпляр Dnsmasq. Они смогут подключаться к вашим устройствам по назначенным им именам, таким как веб-сервер и gateway.lan, и смогут воспользоваться преимуществами кэширования DNS на сетевом уровне.
Какие dns сервера прописать в роутере?
В принципе, существуют несколько надежных адресов, которые можно запомнить или записать, и «в случае чего» спокойно использовать.
Одним из таких «адресов», которые можно внести в настройки dns на роутере является 8.8.8.8
Этот адрес должен решить вопрос стабильности доступа к DNS серверу, однако «выжать» максимум скорости загрузки страниц с его помощью не получится.
Для этого стоит выяснить, какой DNS сервер находится ближе всего к вашему участку всемирной сети и прописать его на роутере.
При этом узнать «оптимальный» dns сервер для роутера можно с помощью специальной программы от Google под названием Namebench.
Скачайте данный софт на свой сетевой компьютер, откройте файл, нажмите кнопку extract и в появившемся окне – кнопку start benchmark.
Далее программа начнёт поэтапно опрашивать список всех DNS серверов, находящихся в её базе и определит, который из них наиболее подходит по скоростным характеристикам для вашего конкретного местоположения.
Эта операция может занять несколько минут.
По результатам данных тестов программа загрузит страничку в браузере, где справа вверху будут перечислены рекомендуемые серверы: первичный, вторичный и ещё один дополнительный – их-то и нужно внести в настройки dns на роутере.
В зависимости от модели роутера, путь к настройкам DNS может варьироваться, однако данная операция всегда осуществляется через Web-интерфейс и искать нужную вкладку следует или в «Общих настройках» или в «Настройках интернет-соединения».
Подробное изложение принципов настройки DNS с примером настройки сервера имен. СТАНДАРТЫ DNS ФОРМАТ ЗАПИСЕЙ В ФАЙЛАХ БАЗЫ DNS ТИПЫ РЕСУРСОВ SOA (НАЧАЛО ПОЛНОМОЧИЙ) NS (СЕРВЕР ИМЕН) A (АДРЕС) CNAME (КАНОНИЧЕСКОЕ
Подробное изложение принципов настройки DNS с примером настройки сервера имен.
Среди администраторов сетей бытует мнение, что DNS следует использовать только при наличии подключения к Internet. Но DNS позволяет упростить администрирование локальных сетей TCP/IP независимо от того, имеют они выход в Internet или нет.
При отсутствии DNS добавление компьютера в локальную сеть приводит к тому, что в файл hosts каждого хоста необходимо ввести информацию о новом компьютере. Это нетрудно, если машин в сети немного. А если их десятки или сотни?
При использовании DNS вся процедура сводится к добавлению одной-двух строк в файлы базы DNS на первичном сервере имен. После этого хосты сети будут распознавать новый компьютер по имени автоматически.
Если по каким-либо причинам необходимо изменить IP-адрес или имя хоста, то с DNS сделать это довольно просто. Кроме того, использование DNS значительно облегчает процедуру подключения корпоративной сети к Internet.
СТАНДАРТЫ DNS
Настройка базы DNS задается в специальных текстовых файлах на серверах имен. Форматы записей в этих файлах регламентируются стандартами, изложенными в документах RFC (Request For Comments). Они разрабатываются "законодательным" органом Internet - IETF (Internet Engineering Task Force). Однако сам набор файлов и порядок их загрузки на серверах имен RFC не регламентируется. Для этого существует стандарт de facto под названием BIND (Berkley Internet Name Domain). Данная спецификация была разработана в университете Беркли и впервые реализована в BSD Unix. Подавляющее большинство серверов имен поддерживают спецификацию BIND.
Многие версии программного обеспечения серверов имен имеют административные утилиты, упрощающие настройку и управление базами DNS. Тем не менее администраторы сетей, как правило, предпочитают не пользоваться ими, а работать напрямую с файлами базы DNS. Хотя это несколько усложняет администрирование, но в то же время дает максимальную гибкость и полный контроль при управлении DNS.
В общем случае порядок запуска серверов имен следующий: сначала создаются файлы базы DNS (напрямую или через административные утилиты), а затем запускается сервис DNS (в Unix - демон named, в NetWare - программа NAMED.NLM).
ФОРМАТ ЗАПИСЕЙ В ФАЙЛАХ БАЗЫ DNS
В файлах базы DNS серверов имен используется так называемый формат записи стандартных ресурсов (Standard Resource Record Format). Выглядит этот формат следующим образом:
Каждая составляющая здесь является полем записи и отделена от других пробелами или знаками табуляции.
- имя описываемого ресурса. Оно зависит от поля и может обозначать домен, зону управления, имя хоста и т. д. Если поле пустое, то в качестве него используется последнее заданное поле (в предыдущих записях).
- время жизни (в секундах). Определяет, как долго клиент DNS будет хранить запись в кэш-памяти. Если данное поле пустое, то в качестве берется значение поля , задаваемое в записи SOA (см. ниже).
описание класса используемых протоколов. Для Internet (TCP/IP) значение этого поля - IN. Если поле пустое, то в качестве него используется последний заданный класс.
- поле, задающее тип ресурса записи. Возможные значения этого поля приведены в разделе "Типы ресурсов".
- поле, устанавливающее данные текущего ресурса. Его содержание зависит от поля . Поле может быть составным, т. е. состоять из нескольких полей.
Следующие символы в записях имеют специальное значение (ниже перечислены некоторые из этих символов).
. Отдельно стоящая точка в поле обозначает текущий домен.
@ Отдельно стоящий символ "@" в поле обозначает текущий исходный домен.
( ) Скобки используются для размещения поля на нескольких строках (когда поле занимает несколько строк).
* Метасимвол. Заменяет любой набор символов.
; Символ комментария. От этого символа и до конца строки информация игнорируется.
Примечание. Следует знать, что в записях ресурсов доменное имя, не заканчивающееся точкой, считается относительным. При обработке оно прибавляется к текущему домену. Поэтому, когда задается полное имя, его необходимо заканчивать точкой.
ТИПЫ РЕСУРСОВ
Тип ресурса задается в поле записи ресурса.
Типов ресурсов множество. Полный их список можно узнать в соответствующих RFC (см. "Дополнительную информацию"). Ниже приводятся наиболее используемые типы.
SOA | Начало полномочий (управления) сервера имен. |
NS | Сервер имен. |
A | Адрес хоста. |
CNAME | Каноническое имя. Используется для задания псевдонимов. |
HINFO | Информация о хосте. |
MX | Почтовый шлюз. |
PTR | Указатель. |
Рассмотрим каждый из этих типов.
SOA (НАЧАЛО ПОЛНОМОЧИЙ)
Запись с ресурсом типа SOA обозначает начало зоны управления сервера имен. Зона управления действует до следующей записи SOA. На Распечатке 1 дается формат записи SOA, а также пример использования.
Здесь поле является составным и включает поля ,
Обозначает имя домена зоны управления.
Имя первичного сервера имен зоны.
Номер версии зоны. Когда производятся изменения в зоне, то это число необходимо увеличить. Именно по данному полю ориентируется вторичный сервер имен, определяя необходимость обновления информации по зоне.
Время в секундах, по прошествии которого вторичный сервер проверяет необходимость обновления информации по зоне.
Время в секундах для повторного обращения вторичного сервера зоны, если ранее попытка обращения к первичному серверу была неудачной.
Предел времени в секундах. Если вторичный сервер не может получить доступ к первичному в течение этого времени, то он будет считать информацию по зоне устаревшей.
Значение TTL в записях ресурсов данной зоны по умолчанию, т. е. когда поле пустое.
NS (СЕРВЕР ИМЕН)
Запись с ресурсом типа NS обозначает имя хоста, являющегося первичным сервером имен для домена. На Распечатке 2 дается формат и пример использования записи NS.
A (АДРЕС)
Запись с ресурсом типа A служит для задания сетевого адреса хоста. На Распечатке 3 приводится формат и пример использования записи A. Здесь - доменное имя хоста, а - его IP-адрес.
CNAME (КАНОНИЧЕСКОЕ ИМЯ)
Запись с ресурсом типа CNAME применяется для указания псевдонима хоста. Формат и пример использования записи CNAME приведены на Распечатке 4. обозначает псевдоним, а - официальное (каноническое) имя хоста.
HINFO (ИНФОРМАЦИЯ О ХОСТЕ)
Запись с ресурсом типа HINFO служит для хранения информации о хосте, в частности об аппаратной платформе и операционной системе компьютера. На Распечатке 5 представлен формат и пример использования записи HINFO. Поле обозначает доменное имя хоста, - аппаратную платформу, - ОС хоста. Значения полей и стандартизированы, их следует брать из RFC 1700. Но можно применять и свои варианты, поскольку данный RFC сильно устарел (там нет ПК старше 386, а также Windows NT, Windows 95 и т. д.).
MX (ПОЧТОВЫЙ ШЛЮЗ)
Для отдельных хостов или всего домена запись с ресурсом типа MX позволяет определить почтовый шлюз - компьютер, куда будет направляться электронная почта, предназначенная для этих хостов. Формат и пример использования записи MX представлены на Распечатке 6. Поле обозначает домен или имя хоста, для которого устанавливается почтовый шлюз. - имя хоста почтового шлюза.
Что такое делегирование?
Когда вы создаёте собственную локальную сеть с выходом в интернет, обязанность расшифровки доменных имён для абонентов данной сети ложится на маршрутизатор, который объединяет все функциональные узла вашей «локалки».
По умолчанию роутеры запрашивают «имя» нужного сетевого IP у DNS сервера интернет-провайдера. При этом данная операция называется делегированием и происходит автоматически без «вмешательства» администратора данной сети.
Кроме того, даже при полной функциональности каждого звена данной сети, каждая операция делегирования отнимает лишнее время на передачу запроса и ответа (от вашего компьютера к одному из основных DNS-серверов и обратно).
Соответственно, имеет смысл прописать dns на роутере вручную – т.е. настроить делегирование напрямую, минуя все сервера-посредники.
На этом всё
Мне показалось важным исследование этих вопросов, потому что DNS — это сложная и запутанная система. Думаю, многие люди с трудом могут найти мотивацию к изучению таких сложных тем и они не понимают, почему вся эта сложность полезна.
DNS (domain name service) – это краеугольный камень удобной работы в сети, эдакая «прослойка» между сложным миром IP-адресов и понятным пользователю «буквенным» именам сайтов.
Начиная
Мы предполагаем, что у вас уже есть работающая машина Linux, готовая для размещения Dnsmasq. Dnsmasq не особо ресурсоемкий — если у вас мало клиентских устройств, он легко будет работать на Raspberry Pi.
У вашего хозяина должен быть Статический IP назначенный. С этого момента IP 192.168.0.1 относится к серверу Dnsmasq.
Убедитесь, что Dnsmasq установлен:
Файл конфигурации Dnsmasq обычно находится в /etc/dnsmasq.conf. Это предварительно заполнено начальными настройками. Для эффективной работы Dnsmasq в сценарии локальной сети необходимо внести некоторые изменения. Запустите sudo nano /etc/dnsmasq.conf, чтобы открыть файл, затем используйте сочетание клавиш Ctrl + W, чтобы найти и раскомментировать следующие строки:
Чтобы настроить исходящий DNS-сервер, добавьте новую строку в файл конфигурации:
сервер = 8.8.8.8 сервер = 4.4.4.4
Это указывает Dnsmasq пересылать неразрешенные запросы в 8.8.8.8. Если этот сервер недоступен, вместо него будет использоваться 4.4.4.4. Эти адреса являются первичными и вторичными преобразователями для службы DNS Google.
Затем настройте размер кеша. По умолчанию это относительно низкое значение — 150 кэшированных запросов. Увеличение этого параметра позволит Dnsmasq обрабатывать больше запросов из кеша, уменьшая задержку в сети. Найдите строку размера кеша, раскомментируйте ее и измените ее значение:
размер кеша = 1000
Сохраните и закройте файл сейчас.
Можно создать два типа DNS-серверов
Существует два основных типа DNS-серверов, которые вы можете создать:
- Если у вас есть домен, то вы можете создать авторитетный сервер имён для этого домена.
- Если у вас есть компьютер (или компания с кучей компьютеров), то вы можете создать резолвер, резолвящий DNS для этих компьютеров.
DNS — это не статичная база данных
Я часто слышу, что DNS сравнивают с «телефонной книгой»: доменные имена — это фамилии, а IP-адреса — телефонные номера.
Запись, которую вы получите в ответ на DNS-запрос, зависит от следующих аспектов:
- Вашего местонахождения в мире (вы можете получить IP-адрес сервера, который физически ближе к вам!).
- Нахождения в корпоративной сети (в которой вы можете резолвить внутренние доменные имена).
- Считается ли доменное имя «плохим» вашим резолвером DNS (оно может быть заблокировано!).
- Предыдущий DNS-запрос (возможно, резолвер DNS выполняет балансировку нагрузки на основе DNS, чтобы каждый раз выдавать вам другой IP-адрес).
- Используете ли вы captive portal WiFi в аэропорту (прежде чем вы выполните вход, WiFi аэропорта резолвит записи DNS по-другому, он отправит вам специальный IP для перенаправления).
- И почти всё, что угодно.
Причины для создания авторитетного сервера имён
Для решения некоторых из перечисленных ниже задач вам необязательно создавать собственный авторитетный сервер имён, вы просто можете выбрать авторитетный сервер имён, имеющий нужные вам функции.
Надо сказать, что есть много причин не создавать собственный авторитетный сервер имён — у меня нет своего сервера и я не пытаюсь вас убедить, что он вам нужен. Обслуживание сервера требует времени, ваш сервис может быть не таким надёжным, и т. п.
Причина: безопасность
Существует опасность того, что атакующий получить доступ к изменению 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-сервер в локальной сети можно на конкретном примере.
Предположим, у вас есть офис с сетью из 20-ти компьютеров для работников, отдельный сервер с базой данных [serv1], и отдельная машина с ролью DHCP-маршрутизатора и DNS-сервера [serv2]
Если же вы захотите присвоить каждому компьютеру и устройству в сети своё имя, понадобится настраивать DNS.
К счастью, всё для настройки клиенсткой части DNS предусмотрено в ОС Windows и большинстве Linux-систем, и вам нужно только прописать авторитетным DNS IP-адрес локального DNS-сервера для каждого сетевого компьютера – обратите внимание, не сервера провайдера или Google, а именно той DNS-машинки, что крутится в локальной сети.
К примеру, в ОС Windows добавить машину в сеть домена можно в “Свойствах Компьютера”, где уже прописано Имя компьютера (например,”comp1-andrey” или “annaPC”).
Зачастую при самостоятельном подключении роутера пользователи неожиданно для себя обнаруживают в настройках маршрутизатора вкладку «DNS сервер» и устремляются на просторы всемирной сети в поисках разыскивать, как прописать dns на роутере.
Однако прежде чем «лезть в дебри» и самостоятельно изменять настройки dns на роутере, нужно разобраться, что это за «зверь» такой – dns, и зачем вообще нужен dns-сервер.
Более подробно данный вопрос мы рассматривали в статье как работает dns в локальной сети, здесь же остановимся только на основных его «характеристиках».
Итак, DNS (или domain name system) – это один из протоколов, обеспечивающих прикладной уровень компьютерных сетей.
Он был разработан, чтобы заменить чрезмерно длинные и неудобоваримые сетевые адреса (IP) доменными именами – лэйблами для соответствующих адресов.
Таким образом, основной задачей DNS сервера является «раздача» доменных имён и присвоение этих лэйблов IP-адресам устройств, подключенных на вверенном ему участке сети.
Разумеется, на просторах интернета «работает» достаточно много основных DNS серверов – для разных регионов и континентов. При этом все остальные сервера запрашивают у них расшифровку доменов (перевод доменных имён в IP-адреса).
Читайте также: