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

Jump to content
Toggle the table of contents

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

6 languages

- Deutsch
- English
- Français
- 日本語
- Português
- 中文（简体）

From ArchWiki

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

- Настройка сети
- 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-gitAUR[ссылка недействительна: package not found]

- 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 (Русский)

Hidden category:

- Pages with broken package links