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

Ссылки по теме
Настройка сети
DNS over HTTPS servers
Состояние перевода:
На этой странице представлен перевод статьи
Domain name resolution
. Дата последней синхронизации: 10 июля 2021. Вы можете
помочь
синхронизировать перевод, если в английской версии произошли
изменения
.
Доменное имя
— символьное представление 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
, читает файл
/etc/resolv.conf
, см.
resolv.conf(5)
.
systemd
предоставляет три службы NSS для разрешения имён:
nss-resolve(8)
— кэширующий распознаватель-заглушка DNS, подробнее в статье
systemd-resolved
;
nss-myhostname(8)
— разрешение имён без редактирования
/etc/hosts
, подробнее в статье
Настройка сети#Разрешение имён в локальной сети
;
nss-mymachines(8)
— разрешение имён для локальных контейнеров
systemd-machined(8)
.
Разрешение доменных имён с 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
. Подробности можно найти в соответствующих статьях:
dhcpcd#/etc/resolv.conf
netctl#/etc/resolv.conf
NetworkManager#/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-северов разработаны собственные утилиты:
knot
—
khost(1)
и
kdig(1)
.
Unbound
—
unbound-host(1)
.
BIND
—
dig(1)
,
host(1)
,
nslookup(1)
, а также набор
dnssec-
утилит.
Производительность
В распознавателе 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 (
RFC:9230
) — система распознавания DNS-имён, которая призвана решить некоторые проблемы приватности. Подробнее см.
статью Cloudflare
.
Сторонние службы DNS
Примечание
Перед использованием DNS-службы какой-либо компании обязательно изучите её политику в отношении приватности и то, как обрабатываются пользовательские данные. Данные представляют некоторую ценость и могут быть проданы третьей стороне.
Существует целый
DNS-служб
от независимых производителей; для некоторых из них также разработаны специализированные программы.
cloudflared
— DNS-клиент с поддержкой DNS over HTTPS от Coudflare.
https://developers.cloudflare.com/1.1.1.1/dns-over-https/cloudflared-proxy
||
cloudflared
dingo
— DNS-клиент с поддержкой DNS over HTTPS от Google.
https://github.com/pforemski/dingo
||
dingo-git
AUR
[
ссылка недействительна
: package not found]
opennic-up
— позволяет автоматизировать обновление DNS-серверов с помощью серверов OpenNIC.
https://github.com/kewlfft/opennic-up
||
opennic-up
AUR
nextdns
— Консольный DNS-over-HTTPS клиент для NextDNS.
https://github.com/nextdns/nextdns
||
nextdns
AUR
С помощью
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
coredns
AUR
или
coredns-bin
AUR
?
?
?
?
?
?
?
Да
?
Deadwood
(
MaraDNS
recursor)
maradns
AUR
Нет
Да
Да
Нет
Нет
Да
Нет
Нет
Нет
dnscrypt-proxy
dnscrypt-proxy
Нет
Нет
Да
Нет
Нет
Сервер
Распознаватель
Нет
Да
dnsmasq
dnsmasq
Частично
1
Нет
Да
Да
Да
Да
Нет
Нет
Нет
Knot Resolver
knot-resolver
Нет
Да
Да
Да
Нет
Да
Нет
Да
Сервер
pdnsd
pdnsd
Да
Да
Стойкий
Нет
Да
Да
Нет
Нет
Нет
PowerDNS Recursor
powerdns-recursor
Нет
Да
Да
Да
Да
Да
Нет
Нет
Нет
Rescached
rescached-git
AUR
Нет
Нет
Да
Нет
Да
Да
Нет
Нет
Ограниченно
2
SmartDNS
smartdns
Нет
Нет
Да
Нет
?
Да
Нет
Распознаватель
Распознаватель
Stubby
stubby
Нет
Нет
Нет
Да
Нет
Сервер
Нет
Распознаватель
Нет
systemd-resolved
systemd
Нет
Нет
Да
Да
Да
Распознаватель и
сервер (ограниченно)
Нет
Распознаватель
Нет
Unbound
unbound
Частично
Да
Да
3
Да
Да
Да
Сервер
Да
Сервер
Из
Википедии
: dnsmasq имеет ограниченную поддержку авторитативности, предназначенную главным образом для внутренних сетей, а не открытого Интернета.
Только перенаправление, если сам Rescached получил DoH-запрос
[5]
.
Unbound может использовать
Redis
в качестве бэкэнда для стойкого кэширования.
Авторитативные серверы
Название
Пакет
DNSSEC
Географическая
балансировка
gdnsd
gdnsd
Нет
Да
Knot DNS
knot
Да
Да
MaraDNS
maradns
AUR
Нет
?
NSD
nsd
Нет
Нет
PowerDNS
powerdns
Да
Да
Условное перенаправление
Существует возможность настроить систему на использование определённого DNS-распознавателя для разрешения некоторых доменных имён. Например, очень удобно при подключении к VPN-сети запросы к ней же разрешать с помощью её собственного DNS, в то время как запросы к остальному интернету будут по прежнему разрешаться стандартным распознавателем. Также это можно использовать в локальных сетях.
Для реализации условного перенаправления понадобится
локальный распознаватель
, потому что glibc такую функцию не поддерживает.
В динамическом окружении (ноутбуки и в некоторой степени настольные компьютеры) необходимо настроить ваш распознаватель на основе сети(-ей), к которой(-ым) вы подключены. Проще всего это сделать с помощью
openresolv
, поскольку он поддерживает
нескольких абонентов
. Некоторые
сетевые менеджеры
также поддерживают этот механизм, либо через openresolv, либо через настройку распознавателя напрямую. Так, в NetworkManager
реализовано условное перенаправление без openresolv
.
Примечание
Хотя перенаправление можно выполнять не только на основе доменных имён, но и по другим условиям (например, IP-адрес отправителя), "условное перенаправление" как термин используется именно для перенаправлений при "запросе домена".
Смотрите также
Руководство сетевого администратора Linux
Справочник Debian
RFC:7706
— снижение времени доступа к корневым серверам при запуске на петлевом устройстве
Domain name system overview
— Диаграмма DNS
Альтернативные службы DNS