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

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

Чем хороша децентрализация DNS?

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

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

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

Можно создать два типа DNS-серверов

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

1. Если у вас есть домен, то вы можете создать авторитетный сервер имён для этого домена.
2. Если у вас есть компьютер (или компания с кучей компьютеров), то вы можете создать резолвер, резолвящий DNS для этих компьютеров.

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

Я часто слышу, что DNS сравнивают с «телефонной книгой»: доменные имена — это фамилии, а IP-адреса — телефонные номера.

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

Запись, которую вы получите в ответ на DNS-запрос, зависит от следующих аспектов:

• Вашего местонахождения в мире (вы можете получить IP-адрес сервера, который физически ближе к вам!).
• Нахождения в корпоративной сети (в которой вы можете резолвить внутренние доменные имена).
• Считается ли доменное имя «плохим» вашим резолвером DNS (оно может быть заблокировано!).
• Предыдущий DNS-запрос (возможно, резолвер DNS выполняет балансировку нагрузки на основе DNS, чтобы каждый раз выдавать вам другой IP-адрес).
• Используете ли вы captive portal WiFi в аэропорту (прежде чем вы выполните вход, WiFi аэропорта резолвит записи 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-сервер для обработки маршрутизации;
• nip.io сопоставляет 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-серверы являются общими. Это значит, что если кто-то нападёт на DNS-сервер google.com или какого-то другого сайта и окажется, что вы используете тот же авторитетный DNS-сервер, то на вас это тоже может повлиять, хотя и атака не нацелена на вас. Примером может служить эта DDoS-атака на Dyn в 2016 году.

Причина: хранение всей конфигурации в одном месте

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

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

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

Причины для создания резолвера

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

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

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

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

Вот несколько примеров резолверов, которые вы можете создать сами (или просто использовать):

• Pi-Hole блокирует рекламодателей.
• Quad9 блокирует домены, занимающиеся вредоносными программами/фишингом/шпионским ПО. Похоже, у Cloudflare есть похожий сервис.
• Думаю, существует также ПО для корпоративной безопасности, блокирующее DNS-запросы доменов, хостящих вредоносные программы.
• DNS — это не статичная база данных. Он очень динамичен, и ответы иногда могут в реальном времени зависеть от IP-адреса, с которого пришёл запрос, текущей нагрузки на контент серверов и т. д. Всё это сложно делать, в реальном времени, если вы не делегируете обслуживание таких записей сущности, принимающей подобные решения.
• Делегирование управления DNS сильно упрощает управление доступом. Всё ниже среза зоны (zone cut) контролируется человеком, управляющим делегированным сервером, поэтому ответственность за имя хоста подразумевается в делегировании DNS.

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

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

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

Причина: избежать злонамеренных резолверов

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

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

Причина: резолвинг внутренних доменов

Возможно, у вас есть внутренняя сеть с доменами (например,
blah.corp.yourcompany.com), которые отсутствуют в публичном Интернете. Создание собственного резолвера для машин во внутренней сети позволяет получать доступ к этим доменам.

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

Причина: избежать MITM своих DNS-запросов

Один человек сказал:

На моём LAN-маршрутизаторе работал резолвер, использующий DNS через HTTPS для передачи вверх по потоку, чтобы IoT и другие устройства, не поддерживающие DoH или DoT, не распространяли наружу DNS открытым текстом.

На этом всё

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