Domain name resolution (Русский)
Доменное имя — символьное представление IP-адреса в системе доменных имён (Domain Name System, DNS). В статье рассмотрена настройка разрешения (resolution) доменных имён.
Name Service Switch
Name Service Switch (NSS) — функциональность стандартной библиотеки Си (glibc), на основе которой выполняется разрешение доменных имён при вызове getaddrinfo(3). NSS объединяет управление базами данных различных служб, позволяя настраивать порядок поиска в этих базах с помощью файла nsswitch.conf(5). За разрешение доменных имён отвечает база данных hosts, для которой glibc предлагает следующие службы:
- files — читает файл
/etc/hosts, см. hosts(5); - dns — распознаватель glibc, читает файл , см. resolv.conf(5).
systemd предоставляет три службы NSS для разрешения имён:
- — кэширующий распознаватель-заглушка DNS, подробнее в статье systemd-resolved;
- — разрешение имён без редактирования
/etc/hosts, подробнее в статье Настройка сети#Разрешение имён в локальной сети; - — разрешение имён для локальных контейнеров systemd-machined(8).
Разрешение доменных имён с NSS
Базы данных NSS можно опрашивать утилитой getent(1). Разрешение доменного имени через NSS выполняется следующим образом:
$ getent hosts доменное_имя
Распознаватель glibc
Распознаватель glibc считывает файл при каждом разрешении имени, определяя сервер доменных имён и используемые опции.
В файле resolv.conf(5) перечислены сервера имён и настройки. Сервера используются в порядке перечисления, сверху вниз. Можно указать до трёх серверов. Строки, начинающиеся с символа решётки (), игнорируются.
Перезапись файла /etc/resolv.conf
Сетевые менеджеры иногда перезаписывают файл . Подробности можно найти в соответствующих статьях:
Помешать программам изменять файл можно с помощью защиты от записи, атрибутом неизменяемости:
# chattr +i /etc/resolv.conf
Ограничение времени поиска
Если поиск выполняется слишком медленно (например, при работе pacman или в браузере), попробуйте задать тайм-аут с небольшим значением. По истечении тайм-аута распознаватель выбирает следующий сервер имён из списка. Добавьте следующую строку в :
options timeout:1
Задержка при разрешении имени с IPv6
Из-за неправильной настройки DNS-сервера или межсетевого экрана может возникать пятисекундная задержка при попытке выполнить разрешение имени двумя запросами, A и AAAA . Добавьте следующую опцию в , чтобы решить проблему:
options single-request
Имена в локальном домене
Чтобы имена локальных хостов можно было указывать без доменного имени, добавьте следующую строку в файл (домен замените на необходимый):
domain example.org
Теперь при работе, например, ssh можно сослаться на локальный хост строкой вида (вместо ); в то же время другим командам (например, drill) всё ещё может требоваться полное имя домена.
Утилиты
С помощью специализированных DNS-утилит можно отправлять запросы конкретным DNS-серверам и/или запросы к записям DNS/DNSSEC определённого типа. NSS при этом не используется, поскольку в утилитах такого рода обычно имеется собственная реализация протокола DNS.
Например, для сбора DNS-информации можно использовать утилиту из пакета . Следующая команда запросит TXT-запись домена у указанного сервера имён:
$ drill @сервер_имён TXT домен
Если DNS-сервер не указать, то drill будет отправлять запросы одному из указанных в серверов.
- knot — khost(1) и kdig(1).
- Unbound — unbound-host(1).
- BIND — dig(1), host(1), nslookup(1), а также набор
dnssec-утилит.
Производительность
В распознавателе glibc отсуствует кэширование ответов. Если кэширование всё же необходимо, то либо используйте systemd-resolved, либо запустите локальный кэширующий DNS-сервер. Во втором случае сервер будет работать как локальный сервер имён — добавьте адреса и ::1 в файл (или в при работе через openresolv).
Приватность и безопасность
В базовом протоколе DNS шифрование сообщений не предусмотрено. По этой причине ни конфиденциальность запросов, ни целостность/подлинность ответов никак не проверяется и не гарантируются. В итоге ваши запросы могут быть "подслушаны", а ответы — изменены, например, при работе в недоверенной сети или при наличии у вашего интернет-провайдера некоего злого умысла. Помимо перечисленных проблем, существует такое явление как перехват DNS со стороны DNS-сервера.
Если вы всё же рассчитываете на некоторую конфиденциальность, то в первую очередь необходимо выбрать DNS-сервер, которому можно доверять. Сервера имён предоставляются как интернет-провайдерами, так и сторонними компаниями. Также можно запустить собственный рекурсивный сервер имён, но это, само собой, потребует некоторых дополнительных усилий. Если вы используете DHCP-клиент в недоверенной сети, убедитесь, что ваш распознаватель настроен на использование статических серверов, потому что иначе запросы будут отправляться на неизвестный посторонний сервер. Обезопасить соединение с удалённым DNS-сервером можно с помощью шифрования по протоколам DNS over TLS (RFC 7858), DNS over HTTPS (RFC 8484) и DNSCrypt, при условии, что и выбранный upstream-сервер, и ваш распознаватель одновременно поддерживают конкретный протокол. В качестве отдельного решения можно использовать специализированную программу для шифрования соединяний, — например, stunnel. Для проверки подлинности ответов (в самом ли деле они приходят от авторитативного сервера имён) можно использовать DNSSEC (опять же при условии, что он поддерживается и сервером, и вашим распознавателем).
DNS в приложениях
Некоторые клиентские программы, например, крупнейшие веб-браузеры, начали реализовывать DNS over HTTPS , . С одной стороны, шифрование сообщений является неоспоримым плюсом; в то же время такие программы часто отправляют запросы "мимо" системного распознавателя .
Firefox предоставляет настройки для включения/отключение DNS over HTTPS и выбора сервера имён.
Chromium включает DoH, если сервера имён, используемые системным распознавателем, его поддерживают. Подробнее (в т.ч. о том, как отключить DoH) см. этот пост.
Также разработчики Mozilla предложили отключать DNS в приложениях, если системный распознаватель не может выполнить разрешение имени специального домена . В настоящее время эта проверка реализована только в Firefox.
Oblivious DNS
Oblivious DNS — система распознавания DNS-имён, которая призвана решить некоторые проблемы приватности. Подробнее см. статью Cloudflare.
Сторонние службы DNS
Существует целый DNS-служб от независимых производителей; для некоторых из них также разработаны специализированные программы.
- nextdns — Консольный DNS-over-HTTPS клиент для NextDNS.
С помощью dnsperftest можно замерить производительность наиболее популярных распознавателей для вашего географического расположения. На сайте dnsperf.com приведено глобальное сравнение производительности резличных провайдеров.
DNS-серверы
DNS-серверы делятся на авторитативные и рекурсивные. Если сервер не принадлежит к одному из этих двух типов, то он представляет из себя так называемый распознаватель-заглушку (stub resolver); его назначение — просто перенаправлять запросы к некоему рекурсивному серверу имён. Заглушки обычно используются для DNS-кэширования на хосте или в локальной сети. Обратите внимание, что то же самое можно получить и установив полноценный сервер имён. В данном разделе представлено сравнение доступных DNS-серверов, более подробное сравнение можно найти в статье Comparison of DNS server software.
| Название | Пакет | Возможности | resolvconf | Поддерживаемые протоколы | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Авторитативный | Рекурсивный | Кэш | Проверка DNSSEC | DNS | DNSCrypt | DNS over TLS | DNS over HTTPS | |||
| BIND | Да | |||||||||
| CoreDNS | или | ? | ? | ? | ? | ? | ? | ? | ? | |
| Deadwood (MaraDNS recursor) | ||||||||||
| dnscrypt-proxy | Сервер | |||||||||
| dnsmasq | Частично1 | Да | ||||||||
| Knot Resolver | ||||||||||
| pdnsd | Да | |||||||||
| PowerDNS Recursor | Да | |||||||||
| Rescached | rescached-gitAUR | 2 | ||||||||
| SmartDNS | ? | |||||||||
| Stubby | Сервер | |||||||||
| systemd-resolved | systemd | Нет | ||||||||
| Unbound | Частично | 3 | Да | Сервер | Сервер | |||||
- Из Википедии: dnsmasq имеет ограниченную поддержку авторитативности, предназначенную главным образом для внутренних сетей, а не открытого Интернета.
- Только перенаправление, если сам Rescached получил DoH-запрос .
- Unbound может использовать Redis в качестве бэкэнда для стойкого кэширования.
Авторитативные серверы
| Название | Пакет | DNSSEC | Географическая балансировка |
|---|---|---|---|
| gdnsd | |||
| Knot DNS | |||
| MaraDNS | ? | ||
| NSD | |||
| PowerDNS |
Условное перенаправление
Существует возможность настроить систему на использование определённого DNS-распознавателя для разрешения некоторых доменных имён. Например, очень удобно при подключении к VPN-сети запросы к ней же разрешать с помощью её собственного DNS, в то время как запросы к остальному интернету будут по прежнему разрешаться стандартным распознавателем. Также это можно использовать в локальных сетях.
Для реализации условного перенаправления понадобится локальный распознаватель, потому что glibc такую функцию не поддерживает.
В динамическом окружении (ноутбуки и в некоторой степени настольные компьютеры) необходимо настроить ваш распознаватель на основе сети(-ей), к которой(-ым) вы подключены. Проще всего это сделать с помощью openresolv, поскольку он поддерживает нескольких абонентов. Некоторые сетевые менеджеры также поддерживают этот механизм, либо через openresolv, либо через настройку распознавателя напрямую. Так, в NetworkManager реализовано условное перенаправление без openresolv.
Смотрите также
- Руководство сетевого администратора Linux
- Справочник Debian
- RFC:7706 — снижение времени доступа к корневым серверам при запуске на петлевом устройстве
- Domain name system overview — Диаграмма DNS
- Альтернативные службы DNS