Domain name resolution (Русский)

From ArchWiki
Jump to navigation Jump to search
Состояние перевода: На этой странице представлен перевод статьи Domain name resolution. Дата последней синхронизации: 3 февраля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Доменное имя — символьное представление IP-адреса в системе доменных имён (Domain Name System, DNS). В статье рассмотрена настройка разрешения (resolution) доменных имён.

Name Service Switch

Name Service Switch (NSS) — функциональность стандартной библиотеки Си (glibc), на основе которой выполняется разрешение доменных имён при вызове getaddrinfo(3). NSS объединяет управление базами данных различных служб, позволяя настраивать порядок поиска в этих базах с помощью файла nsswitch.conf(5). За разрешение доменных имён отвечает база данных hosts, для которой glibc предлагает следующие службы:

systemd предоставляет три службы NSS для разрешения имён:

Разрешение доменных имён с NSS

Базы данных NSS можно опрашивать утилитой getent(1). Разрешение доменного имени через NSS выполняется следующим образом:

$ getent hosts доменное_имя
Примечание: Хотя большинство программ выполняет разрешение имён через NSS, некоторые читают файлы /etc/resolv.conf и/или /etc/hosts напрямую. Подробнее см. Настройка сети#Разрешение имён в локальной сети.

Распознаватель glibc

Распознаватель glibc считывает файл /etc/resolv.conf при каждом разрешении имени, определяя сервер доменных имён и используемые опции.

В файле resolv.conf(5) перечислены сервера имён и настройки. Сервера используются в порядке перечисления, сверху вниз. Можно указать до трёх серверов. Строки, начинающиеся с символа решётки (#), игнорируются.

Примечание: Распознаватель glibc не кэширует ответы на запросы и не проверяет DNSSEC. Выбрать распознаватель с кэшированием (для экономии времени) или с поддержкой DNSSEC можно в разделе #DNS-серверы.

Перезапись файла /etc/resolv.conf

Сетевые менеджеры иногда перезаписывают файл /etc/resolv.conf. Подробности можно найти в соответствующих статьях:

Помешать программам изменять файл /etc/resolv.conf можно с помощью защиты от записи, атрибутом неизменяемости:

# chattr +i /etc/resolv.conf
Совет: Если у вас есть несколько процессов, которые желают выполнять запись в /etc/resolv.conf, то используйте resolvconf.

Ограничение времени поиска

Если поиск выполняется слишком медленно (например, при работе pacman или в браузере), попробуйте задать тайм-аут с небольшим значением. По истечении тайм-аута распознаватель выбирает следующий сервер имён из списка. Добавьте следующую строку в /etc/resolv.conf:

options timeout:1

Задержка при разрешении имени с IPv6

Из-за неправильной настройки DNS-сервера или межсетевого экрана может возникать пятисекундная задержка при попытке выполнить разрешение имени двумя запросами, A и AAAA [1]. Добавьте следующую опцию в /etc/resolv.conf, чтобы решить проблему:

options single-request

Имена в локальном домене

Чтобы имена локальных хостов можно было указывать без доменного имени, добавьте следующую строку в файл /etc/resolv.conf (домен замените на необходимый):

domain example.org

Теперь при работе, например, ssh можно сослаться на локальный хост строкой вида mainmachine1 (вместо mainmachine1.example.org); в то же время другим командам (например, drill) всё ещё может требоваться полное имя домена.

Утилиты

С помощью специализированных DNS-утилит можно отправлять запросы конкретным DNS-серверам и/или запросы к записям DNS/DNSSEC определённого типа. NSS при этом не используется, поскольку в утилитах такого рода обычно имеется собственная реализация протокола DNS.

Например, для сбора DNS-информации можно использовать утилиту drill(1) из пакета ldns. Следующая команда запросит TXT-запись домена у указанного сервера имён:

$ drill @сервер_имён TXT домен

Если DNS-сервер не указать, то drill будет отправлять запросы одному из указанных в /etc/resolv.conf серверов.

Совет: Для некоторых DNS-северов разработаны собственные утилиты:

Производительность

В распознавателе glibc отсуствует кэширование ответов. Если кэширование всё же необходимо, то либо используйте systemd-resolved, либо запустите локальный кэширующий DNS-сервер. Во втором случае сервер будет работать как локальный сервер имён — добавьте адреса 127.0.0.1 и ::1 в файл /etc/resolv.conf (или в /etc/resolvconf.conf при работе через openresolv).

Совет:
  • Утилиты drill и dig выводят время, затраченное на запрос к серверу.
  • На маршрутизаторах часто установлен собственный распознаватель, который выступает в качестве DNS-сервера для локальной сети; он же обычно предоставляет и DNS-кэш.
  • Если переключение между серверами происходит слишком медленно, попробуйте уменьшить тайм-аут.

Приватность и безопасность

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

Если вы всё же рассчитываете на некоторую конфиденциальность, то в первую очередь необходимо выбрать DNS-сервер, которому можно доверять. Сервера имён предоставляются как интернет-провайдерами, так и сторонними компаниями. Также можно запустить собственный рекурсивный сервер имён, но это, само собой, потребует некоторых дополнительных усилий. Если вы используете DHCP-клиент в недоверенной сети, убедитесь, что ваш распознаватель настроен на использование статических серверов, потому что иначе запросы будут отправляться на неизвестный посторонний сервер. Обезопасить соединение с удалённым DNS-сервером можно с помощью шифрования по протоколам DNS over TLS (RFC 7858), DNS over HTTPS (RFC 8484) и DNSCrypt, при условии, что и выбранный upstream-сервер, и ваш распознаватель одновременно поддерживают конкретный протокол. В качестве отдельного решения можно использовать специализированную программу для шифрования соединяний, — например, stunnel. Для проверки подлинности ответов (в самом ли деле они приходят от авторитативного сервера имён) можно использовать DNSSEC (опять же при условии, что он поддерживается и сервером, и вашим распознавателем).

DNS в приложениях

Некоторые клиентские программы, например, крупнейшие веб-браузеры, начали реализовывать DNS over HTTPS [2], [3]. С одной стороны, шифрование сообщений является неоспоримым плюсом; в то же время такие программы часто отправляют запросы "мимо" системного распознавателя [4].

Firefox предоставляет настройки для включения/отключение DNS over HTTPS и выбора сервера имён.

Chromium включает DoH, если сервера имён, используемые системным распознавателем, его поддерживают. Подробнее (в т.ч. о том, как отключить DoH) см. этот пост.

Также разработчики Mozilla предложили отключать DNS в приложениях, если системный распознаватель не может выполнить разрешение имени специального домена use-application-dns.net. В настоящее время эта проверка реализована только в Firefox.

Oblivious DNS

Oblivious DNS — система распознавания DNS-имён, которая призвана решить некоторые проблемы приватности. Подробнее см. статью Cloudflare.

Сторонние службы DNS

Примечание: Перед использованием DNS-службы какой-либо компании обязательно изучите её политику в отношении приватности и то, как обрабатываются пользовательские данные. Данные представляют некоторую ценость и могут быть проданы третьей стороне.

Существует целый DNS-служб от независимых производителей; для некоторых из них также разработаны специализированные программы.

  • cloudflared — DNS-клиент с поддержкой DNS over HTTPS от Coudflare.
https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy || cloudflaredAUR, cloudflared-binAUR
  • dingo — DNS-клиент с поддержкой DNS over HTTPS от Google.
https://github.com/pforemski/dingo || dingo-gitAUR
  • opennic-up — позволяет автоматизировать обновление DNS-серверов с помощью серверов OpenNIC.
https://github.com/kewlfft/opennic-up || opennic-upAUR
  • nextdns — Консольный DNS-over-HTTPS клиент для NextDNS.
https://github.com/nextdns/nextdns || nextdnsAUR

С помощью 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 bind Да Да Да Да Да Да Нет stunnel#DNS over TLS Нет
CoreDNS corednsAUR или coredns-binAUR ? ? ? ? ? ? ? ? ?
Deadwood (MaraDNS recursor) maradnsAUR Нет Да Да Нет Нет Да Нет Нет Нет
dnscrypt-proxy dnscrypt-proxy Нет Нет Да Нет Нет Сервер Распознаватель Нет Да
dnsmasq dnsmasq Частично1 Нет Да Да Да Да Нет Нет Нет
Knot Resolver knot-resolver Нет Да Да Да Нет Да Нет Да Сервер
pdnsd pdnsd Да Да Стойкий Нет Да Да Нет Нет Нет
PowerDNS Recursor powerdns-recursor Нет Да Да Да Да Да Нет Нет Нет
Rescached rescached-gitAUR Нет Нет Да Нет Да Да Нет Нет Ограниченно2
SmartDNS smartdns Нет Нет Да Нет ? Да Нет Распознаватель Распознаватель
Stubby stubby Нет Нет Нет Да Нет Сервер Нет Распознаватель Нет
systemd-resolved systemd Нет Нет Да Да Да Распознаватель и сервер (ограниченно) Нет Распознаватель Нет
Unbound unbound Частично Да Да3 Да Да Да Сервер Да Сервер
  1. Из Википедии: dnsmasq имеет ограниченную поддержку авторитативности, предназначенную главным образом для внутренних сетей, а не открытого Интернета.
  2. Только перенаправление, если сам Rescached получил DoH-запрос [5].
  3. Unbound может использовать Redis в качестве бэкэнда для стойкого кэширования.

Авторитативные серверы

Название Пакет DNSSEC Географическая
балансировка
gdnsd gdnsd Нет Да
Knot DNS knot Да Да
MaraDNS maradnsAUR Нет ?
NSD nsd Нет Нет
PowerDNS powerdns Да Да

Условное перенаправление

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

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

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

Примечание: Хотя перенаправление можно выполнять не только на основе доменных имён, но и по другим условиям (например, IP-адрес отправителя), "условное перенаправление" как термин используется именно для перенаправлений при "запросе домена".

Смотрите также