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

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

From ArchWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Ссылки по теме

- Настройка сети
- 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#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 — система распознавания 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-адрес отправителя), "условное перенаправление" как термин используется именно для перенаправлений при "запросе домена".

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

- Руководство сетевого администратора Linux
- Справочник Debian
- RFC:7706 — снижение времени доступа к корневым серверам при запуске на петлевом устройстве
- Domain name system overview — Диаграмма DNS
- Альтернативные службы DNS

Categories:

- Domain Name System (Русский)
- Network configuration (Русский)