Ubuntu не разрешает имена

Обновлено: 02.07.2024

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

Конфигурация DNS-сервера

У каждого хоста должен быть список IP-адресов DNS-серверов, и в большинстве случаев этот список поступает из аренды DHCP. Чтобы узнать, с какими DNS-серверами настроен ваш Linux-сервер, вы должны просмотреть файл «/etc/resolv.conf» следующим образом:

Серверы имен: 8.8.8.8, 192.168.0.1

Это DNS-серверы, используемые для разрешения веб-адресов. Вы можете перечислить до трех, и распознаватель будет пробовать каждый из них, один за другим, пока не найдет тот, который работает. Вы можете узнать DNS-сервер Google 8.8.8.8, а 192.168.0.1 — мой домашний маршрутизатор, который также работает как DNS-сервер.

Конечно, вам придется настроить DHCP-сервер, чтобы он предоставлял всю эту информацию при каждом запросе DHCP. Но вы также можете отредактировать /etc/resolv.conf и изменить эти значения. Имейте в виду, что они будут перезаписаны в следующий раз, когда будет предоставлена новая аренда DHCP, если вы не укажете статическую IP-конфигурацию на агенте (мы расскажем об этом в следующем посте).

Как разрешить URL

Теперь давайте посмотрим, как мы можем проверить, работает ли DNS. Мы также расскажем, как протестировать определенные DNS-серверы, чтобы увидеть, работают ли они и, если да, то насколько быстро они работают.

Для этого существует несколько команд, но ниже я рассмотрю наиболее распространенные из них. Если какие-либо из следующих команд недоступны на вашем хосте Linux, установите их с помощью следующей команды:

Синтаксис и вывод следующие:

Все эти команды могут выполнять обратный поиск, если вы укажете IP-адрес следующим образом:

Если вы хотите протестировать определенный DNS-сервер (кроме перечисленных в вашем файле /etc/resolv.conf), вы можете добавить его IP-адрес в конце команды следующим образом:

nslookup

nslookup очень похож на host, но с одной изюминкой. В своей базовой форме он разрешает адрес точно так же, как хост, хотя вывод немного отличается:

Как видите, nslookup сообщает нам, какой сервер использовался для поиска (8.8.8.8 в первом запросе выше и 1.0.0.1 во втором).

Изюминка заключается в том, что nslookup имеет интерактивный режим, который можно использовать, просто набрав «nslookup» без каких-либо аргументов. С этого момента вы можете просто ввести веб-страницу, которую хотите разрешить, и нажать Enter. Таким образом, вы можете разрешать несколько страниц без необходимости постоянно набирать «nslookup». Чтобы выйти из интерактивного режима перемещения, введите «exit» или нажмите Ctrl-C.

dig означает сбор информации о домене. Единственное отличие синтаксиса от предыдущих двух команд заключается в том, что при указании DNS-сервера вы используете символ «@»:

Как видите, команда dig гораздо более подробная, чем две предыдущие команды. Я не собираюсь разбирать каждую строку вывода; самое важное отличие состоит в том, что dig предоставил время, необходимое для выполнения этого запроса («Время запроса:»). dig — единственный, кто делает это из коробки.

Вы видите, что это заняло всего 17 миллисекунд. Конечно, мой домашний роутер не сможет разрешить все, что ему подбрасывают, тем не менее, он намного быстрее для закешированного адреса (что ожидаемо).

Я подключил Raspberry Pi 4 под управлением Ubuntu 20.04 к своей локальной сети через Wi-Fi.

С моего ноутбука я могу подключиться к Raspberry Pi по протоколу SSH:

Вместо того, чтобы каждый раз вводить этот IP-адрес, я хотел бы иметь возможность подключиться к нему по SSH, используя имя хоста: rasp01 . Я нашел это руководство:

За этим я следил. После перезагрузки Raspberry Pi и входа в систему у меня есть это:

Но когда я пытаюсь использовать это имя хоста при подключении SSH к Raspberry Pi с моего ноутбука в той же локальной сети (также с Ubuntu), я получаю следующее:

Что я упускаю?

Где пользователь, по-видимому, в конце концов заставил его работать с *.local.

Кроме того, Raspberry Pi 4 станет частью Raspberry Picluster, где я установлю docker/kubernetes (лабораторное развлечение). По моему опыту, сетевое взаимодействие уже становится довольно сложным, если в него добавить только Docker, что также подтверждается этой статьей:

С этой точки зрения было бы "проще" установить собственный внутренний DNS:

Я предполагаю, что у вас есть маршрутизатор с DHCP, у большинства из них есть опция резервирования DHCP, чтобы вы могли исправить IP-адрес, или, если у вас есть диапазон для DHCP, вы можете установить статический на своем рашпиле.

2 ответа 2

Просто установите avahi-daemon на Raspberry Pi.

Авахи-демон в основном устанавливает имя хоста многоадресной рассылки на Raspberry Pi, которое должно транслироваться по вашей локальной сети:

«Демон Avahi mDNS/DNS-SD реализует архитектуру Apple Zeroconf (также известную как «Rendezvous» или «Bonjour»).Демон регистрирует локальные IP-адреса и статические службы, используя mDNS/DNS-SD, и предоставляет два API-интерфейса IPC для локальных программ, чтобы использовать кеш записей mDNS, поддерживаемый демоном avahi».

Установить его довольно просто:

Так и должно быть! Тогда любое имя хоста этого устройства может быть доступно в вашей сети по адресу [hostname].local . Просто пропингуйте его с другого устройства в вашей сети следующим образом:

И вы должны увидеть, что он соответствует IP-адресу этого устройства. Если вы не видите, что он появляется сразу, подождите минуту или около того и снова пропингуйте. И, возможно, перезапустите службу Avahi следующим образом:

И вам должно быть хорошо.

Как правило, редактирование файла Hosts ( /etc/hosts/ ) — ужасно неуклюжий способ сделать это. Это требует ручного вмешательства, и если IP-адрес изменится, угадайте, что? Больше ручного вмешательства. Авахи — это то, что вам нужно.

Отлично, похоже, это правильный путь. Я добавил обновление к своему вопросу, так как моя настройка немного усложняется, и мне было интересно, действительно ли настройка внутреннего выделенного DNS-сервера будет лучше (см. обновленный вопрос)?

@u123 Avahi проще. Вам просто нужно установить Avahi на каждом узле, и он просто автоматически установит имя хоста [node].local, которое будет транслироваться в сети. Напротив, выделенный DNS-сервер потребует от вас не только настройки этого DNS-сервера, но и вручную установки записей для каждого узла в кластере. Avahi не рекомендуется использовать только в том случае, если вы создаете узлы в реальном мире. Avahi в основном предназначен для локальных сетей, а DNS-серверы в основном предназначены для более крупной интернет-инфраструктуры. Для кластера Raspberry Pi в локальной сети? Авахи полностью.

Хорошо, на самом деле я не возражаю против дополнительных хлопот, так как это домашняя лаборатория/учебный проект. В конце концов я также хотел бы проверить, могу ли я подключиться к кластеру из Интернета, будет ли запуск Avahi в моей локальной сети конфликтовать с этим вариантом использования?

@u123 Я ответил на ваш вопрос так, как вы заявили и представили: «Я подключил Raspberry Pi 4 под управлением Ubuntu 20.04 к моей локальной сети через Wi-Fi». Как я уже объяснял, метод Avahi решит проблемы, с которыми вы сталкиваетесь в своей локальной сети. Метод DNS — вот что это такое. Если у вас есть новый вопрос, вам нужно опубликовать новый вопрос. Я не могу помочь вам дальше. Вы должны использовать то, что вам нужно использовать. Если вы чувствуете, что такой ответ помог вам, обязательно проголосуйте за него. Если это ответ, который решил вашу проблему, обязательно отметьте его как таковой. Удачи в ваших начинаниях!

В IP-сетях нет универсального метода поиска локального имени хоста — существует существует несколько протоколов, но они больше похожи на надстройки. Часто их нужно включать вручную, особенно в Linux.

Обычно ваш домашний маршрутизатор предоставляет внутренний DNS. Если Pi использует DHCP, он будет объявлять свое имя хоста при отправке запроса на аренду DHCP — большинство домашних маршрутизаторов затем публикуют его в локальном домене DNS (например, .home или .lan или что-то подобное).

В корпоративных сетях и пользовательских DHCP-серверах такая автоматическая регистрация обычно отсутствует.

Обратите внимание, что этот метод не работает со статическими IP-адресами (используйте резервирование DHCP, если хотите) и не определяет автоматически изменения имени хоста. Поэтому, если вы только что переименовали Pi, вам необходимо перезапустить его DHCP-клиент и получить новую аренду.

Это также требует, чтобы другие компьютеры знали суффикс поиска DNS, который использует DNS вашего маршрутизатора. Он также автоматически извлекается с маршрутизатора через DHCP, но его необходимо настроить вручную, если хост использует статический адрес.

Другой вариант – многоадресный DNS (mDNS). Это тот, который использует .local . Чтобы это работало в Linux, вам необходимо установить avahi-daemon и libnss-mdns на все устройства, которые будут участвовать.

mDNS также является стандартной частью macOS и доступен для Windows 10 после изменения реестра.

Как следует из названия, mDNS использует многоадресные пакеты. Они не всегда надежны в сети Wi-Fi, а некоторые беспроводные сети полностью блокируют их. Убедитесь, что ваш маршрутизатор не работает.

LLMNR очень похож на mDNS, но не использует суффикс домена. Он в основном используется Windows, но также поддерживается systemd-resolved в Linux. Вы можете запустить оба, если хотите.

(Есть также NetBIOS, который Windows использовала в прошлом. Когда-то он был очень распространенным (хотя и ненадежным), но теперь стал редкостью после удаления SMBv1. Samba поддерживает его, но не беспокойтесь.)

Большинство маршрутизаторов имеют возможность постоянно назначать аренду DHCP определенным устройствам. (Это можно назвать «статической арендой» или «резервированием», но у него не всегда есть конкретное имя.) Если вы хотите, чтобы Pi всегда был 192.168.3.14 или каким-то другим, это можно сделать.

systemd — это проект бесплатного программного обеспечения, целью которого является создание строительных блоков пользовательского пространства для системы Linux.Их наиболее известным компонентом является система инициализации, способная запускать несколько служб параллельно, что сокращает время загрузки вашего компьютера с Linux. Если у вас есть серверы с Ubuntu (xenial или bionic), вы уже используете systemd в качестве процесса инициализации — PID 1.

Несмотря на то, что первое может звучать великолепно, systemd уже много лет подвергается резкой критике со стороны части сообщества открытого исходного кода. Я не буду углубляться в эти жалобы, но отмечу одну из них: systemd заново изобретает множество подсистем, которые не нуждаются в исправлении, что приводит к тонкой несовместимости с существующей инфраструктурой.

Одной из этих подсистем является разрешение имен, то есть то, как ваш сервер преобразует доменные имена в сетевые адреса. systemd поставляется со своей собственной реализацией: systemd-resolved. Ubuntu включил systemd-resolved в версию 16.10, и теперь он присутствует в текущей версии LTS — 18.04.

systemd-resolved предоставляет локальным приложениям интерфейс к DNS. Помимо реализации распознавателя, он добавляет несколько возможностей, таких как кэширование DNS и проверка DNSSEC. systemd-resolved может использоваться приложениями тремя способами:

Хм, это начинает казаться сложным… не так ли? На одном и том же сервере поведение разрешения имен может различаться в зависимости от приложения и конфигурации. И все может стать сложнее.

Давайте быстро посмотрим, как обычно выполняется разрешение имен в системах Linux.

Если вы когда-либо настраивали систему в Linux, вы знаете, что преобразователь имен настраивается в /etc/resolv.conf. Обычно он состоит из списка серверов имен, которые запрашиваются по порядку. Вот и все. Раньше системный администратор настраивал этот файл и двигался дальше.

Но затем более динамичная среда стала «новой нормой». В частности, для рабочих столов Linux и облачных вычислений требовались динамические сетевые среды, поэтому статический файл конфигурации для разрешения имен в таких случаях не подходил. Поэтому такие приложения, как resolvconf, использовались (и используются) для динамического обновления /etc/resolv.conf на основе внешней информации. resolvconf предназначен не для использования вручную, а из другого программного обеспечения для настройки, такого как ifup, ifdown, dhclient или dnsmasq.

Как это связано с systemd-resolved? Ну, тут у нас больше сложностей. systemd-resolved может быть поставщиком /etc/resolv.conf или использовать этот файл. Это зависит от режима совместимости, установленного системным администратором. По сути, вы либо полагаетесь на 127.0.0.53 для разрешения имен, либо используете systemd-resolve, чтобы разрешить приложениям обходить systemd-resolved, либо позволяете другим пакетам управлять /etc/resolv.conf.

Хорошо, вы, должно быть, в данный момент запутались... Позвольте мне объяснить проблему, из-за которой возникла эта запись в блоге, и я буду использовать ее в качестве примера, чтобы пройтись по этим конфигурациям.

Проблема, с которой столкнулся наш клиент на сервере Ubuntu 18.04 облачного провайдера, заключалась в следующем:

Хорошо, хост не найден. Попробуем решить:

Хм… работает — происходит что-то странное. Какие DNS-серверы используются?

127.0.0.53: слушатель-заглушка systemd-resolved.
1.1.1.1 и 1.0.0.1: преобразователь Clouflare.

Поскольку 127.0.0.53 является первым сервером имен в /etc/resolv.conf, он должен обрабатывать DNS-запросы в первую очередь. Как настроено разрешение systemd?

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

Да, он работает, и заглушка прослушивает соответствующие порты — udp/53 и tcp/53. Но подождите, мы уже видели, что приложения также могут взаимодействовать с systemd-resolved посредством API D-Bus или glibc. Если бы dirmngr и хост использовали разные подходы, мы могли бы сделать вывод, что один из них выявляет проблему, а другой — нет.

На самом деле dirmngr использует getaddrinfo() из glibc, но host является частью BIND и напрямую обрабатывает DNS-запросы. Я проверил это, разобрав код с помощью objdump (пакет binutils), но вместо этого я мог просмотреть исходный код. Обрабатываются ли вызовы dirmngr системой systemd-resolved напрямую? Чтобы ответить на этот вопрос, мы должны проверить, содержит ли директива hosts: в /etc/nsswitch.conf ключевое слово «разрешить». Однако мы видим, что на исследуемом сервере это не так.

Таким образом, мы можем предположить, что systemd-resolved обрабатывает запросы dirmngr, когда они достигают 127.0.0.53. В случае истечения времени ожидания последнего, вместо этого будут опрошены серверы Cloudflare.

Тогда почему команда gpg не может разрешить имя хоста? Что на самом деле происходит под капотом? Сетевой трафик расскажет нам. Давайте перехватим DNS-запросы и ответы с помощью tcpdump, пока мы запускаем gpg.

На предыдущем снимке экрана мы можем наблюдать разные фазы.

Запись на этапе 3 оказывается RRSIG — она содержит цифровые подписи записей ресурсов, которые используются в процессе аутентификации DNSSEC. На данный момент systemd-resolved не поддерживает запросы к этим (и связанным с ними) записям при определенных условиях. Мы можем легко проверить это, заставив 127.0.0.53 разрешить запрос RRSIG (это не удается). Если тот же запрос обслуживается сервером имен DNS Cloudflare, он выполняется успешно:

Наконец-то у нас есть кое-что, объясняющее, почему не удалось запустить gpg. Однако до сих пор неясно, почему время ожидания всех запросов истекло, поскольку на записи A и AAAA были успешно даны ответы. Давайте продолжим разбираться в этом.

Почему systemd-resolved выполняет 3 запроса параллельно? Давайте проверим его статус:

1.0.0.1 и 1.1.1.1: серверы имен Cloudflare в качестве глобальных DNS-серверов. Они берутся из /etc/resolv.conf, как мы видели ранее.
8.8.8.8 и 8.8.4.4: DNS-серверы Google для запросов, проходящих через интерфейс eth0. Они поступают из внешних источников, в частности, с DHCP-сервера.
8.8.8.8 и 8.8.4.4: то же, что и выше, но для интерфейса eth1.

Три параллельных запроса соответствуют ожидаемому поведению systemd-resolved: один для глобального сервера имен и еще один для сетевого интерфейса. Кто настраивает Cloudflare в качестве глобального сервера имен? Вернемся к /etc/resolv.conf:

Какой странный конфиг! Вам не кажется? Обратите внимание на конфликтующие настройки:

Вы используете systemd-resolved, и он использует конфигурации DNS для каждого интерфейса с DHCP-сервера. Такой DHCP-сервер перечисляет внешние DNS-серверы — от Google.
Но /etc/resolv.conf управляется resolvconf . Это должно означать, что системный администратор хочет использовать последний режим совместимости systemd-resolved в отношении /etc/resolv.conf. Однако, поскольку 127.0.0.53 указан как сервер имен, systemd-resolved берет на себя управление разрешением имен.
Но resolvconf включает дополнительные (но другие) внешние DNS-серверы — от Cloudflare — для ваших глобальных настроек разрешения имен.

Этот конфигурационный кошмар вместе с ошибкой RRSIG, которую мы обсуждали ранее, приводит к тому, что ваша система ломается очень тонким, трудным для отладки, трудным для понимания способом. В частности, когда некоторые запросы ожидают ответа от некоторых вышестоящих DNS-серверов, но systemd-resolved получает запрос, который он не поддерживает (например, поиск записи RRSIG), кажется, что процесс разрешения имен полностью терпит неудачу.

На мой взгляд, настройки, выбранные облачным провайдером, ошибочны (с точки зрения удобства сопровождения) и должны быть исправлены. Даже если они работали, они не имели большого смысла и усложняли и без того сложную настройку. Провайдер должен выбрать четкую политику — либо использовать 127.0.0.53 в качестве единственного сервера имен, либо избавиться от systemd-resolved — и придерживаться ее.

DNS — важнейший компонент Интернета, и он гораздо сложнее, чем может показаться на первый взгляд. Ради дополнительной функциональности systemd-resolved усложняет его. По словам автора systemd-resolved:

resolved не должен быть DNS-сервером, он должен быть достаточно хорошим, чтобы libc-подобные DNS-клиенты могли разрешать свои данные

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

В этой статье я попытался помочь вам преодолеть трудности, связанные с отслеживанием реальной проблемы у реального поставщика услуг. Если вы считаете, что я что-то не так, просто напишите мне, и я буду рад обновить этот пост. Привет, и не забудьте зарегистрироваться ниже, если вы хотите, чтобы мы отправляли вам электронное письмо, когда мы публикуем больше материалов 😀

При использовании Ubuntu 12.04/12.10 и более поздних версий/производных (включая мой текущий дистрибутив Linux Mint для настольных ПК) у меня периодически возникали проблемы с программами, разрешающими IP-адреса хостов в локальной сети. Они легко решаются с помощью нескольких настроек конфигурации.

Примечание. Это старая статья, и ее содержание устарело. Я не использовал ни Ubuntu, ни Linux Mint в гневе несколько лет, а системы инициализации SystemV/Upstart в Ubuntu и производные операционные системы были заменены на Systemd.

маска DNS

Первая проблема, которую я заметил, была случайной. Если бы я хотел подключиться по SSH к удаленному хосту в своей сети, я бы иногда видел следующее:

Похоже, это проблема с dnsmasq. Когда я бежал:

В результатах я увидел, что DNS-запрос был разрешен 127.0.0.1. Другими словами, мой рабочий стол с Linux Mint сам разрешал DNS-запросы. Я мог бы подтвердить это с помощью:

Это ясно показывает, что dnsmasq прослушивает порт 53 (и TCP, и UDP).dnsmasq — это облегченный DHCP-сервер и кэширующий DNS-сервер.

dnsmasq по умолчанию настроен на использование DNS-серверов, указанных в /etc/resolv.conf, для разрешения DNS-запросов. Почему он периодически выходит из строя, я не уверен. Кажется, что проще всего отключить его, чего можно добиться, отредактировав файл network manager.conf

Найдите следующую строку:

И закомментируйте это следующим образом:

Сохраните файл и закройте редактор. Изменение не вступит в силу, пока NetworkManager или сама рабочая станция не будут перезапущены. Вы можете использовать следующую команду для перезапуска NetworkManager:

Авахи

Avahi — это сетевая служба, которая позволяет узлам публиковать службы, а также обнаруживать другие узлы и службы, доступные в локальной сети.

По умолчанию Ubuntu и ее производные настроены на использование Avahi для разрешения запросов DNS. Это может привести к конфликту с разрешением DNS-запросов для доменов верхнего уровня .local. Я лично не использую .local , но, к сожалению, домен AD, который я администрирую, использует. Поэтому это вызывает проблемы, когда я получаю удаленный доступ к хостам в домене моей компании через VPN.

Мой личный выбор — не полагаться на Avahi (и, в свою очередь, на mDNS, DNS-SD). Если я настрою службу в своей локальной сети, я создам необходимые записи DNS на своем DNS-сервере.

Сначала я предотвратил запуск avahi-demon при запуске с помощью следующей команды:

Это просто останавливает выскочку Ubuntu от запуска avahi-deamon. Чтобы это изменение сразу же вступило в силу, вам нужно остановить авахи-демона с помощью:

Следующий шаг — редактирование файла конфигурации коммутатора службы имен и удаление ссылки на mdns4_minimal. Я обычно редактирую свой следующим образом:

На этом изменения, которые я вношу, чтобы сделать разрешение DNS-запросов в Linux Mint максимально надежным, заканчиваются.

Читайте также: