Debian DNS не работает

Обновлено: 21.11.2024

Файл /etc/resolv.conf — это основной файл конфигурации для библиотеки преобразователя имен DNS. Преобразователь — это набор функций в библиотеке C, которые обеспечивают доступ к системе доменных имен Интернета (DNS). Функции настроены на проверку записей в файле /etc/hosts или на нескольких DNS-серверах имен, или на использование базы данных узла Network Information Service (NIS).

В современных системах Linux, использующих systemd (диспетчер системы и служб), службы DNS или разрешения имен предоставляются локальным приложениям через службу systemd-resolved. По умолчанию эта служба имеет четыре различных режима обработки разрешения доменных имен и использует файл-заглушку DNS systemd (/run/systemd/resolve/stub-resolv.conf) в режиме работы по умолчанию.

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

Если вы выполните следующую команду ls для файла /etc/resolv.conf, вы увидите, что этот файл является символической ссылкой на файл /run/systemd/resolve/stub-resolv.conf.

К сожалению, поскольку файл /etc/resolv.conf косвенно управляется службой разрешения systemd, а в некоторых случаях — сетевой службой (с помощью сценариев инициализации или NetworkManager), любые изменения, внесенные пользователем вручную, не могут быть сохранены. навсегда или только на время.

В этой статье мы покажем, как установить и использовать программу resolvconf для установки постоянных DNS-серверов имен в файле /etc/resolv.conf в дистрибутивах Debian и Ubuntu Linux.

Зачем вам нужно редактировать файл /etc/resolv.conf?

Основная причина может заключаться в том, что системные настройки DNS настроены неправильно или вы предпочитаете использовать определенные серверы имен или свои собственные. Следующая команда cat показывает сервер имен по умолчанию в файле /etc/resolv.conf в моей системе Ubuntu.

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

То же самое происходит, когда вы запускаете команду ping.

Поэтому, когда пользователь пытается вручную установить серверы имен, изменения не действуют долго или отменяются после перезагрузки. Чтобы решить эту проблему, вы можете установить и использовать утилиту reolvconf, чтобы сделать изменения постоянными.

Чтобы установить пакет resolvconf, как показано в следующем разделе, вам необходимо сначала вручную установить следующие серверы имен в файле /etc/resolv.conf, чтобы вы могли получить доступ к FQDM серверов репозитория Ubuntu в Интернете.< /p>

Установка resolvconf в Ubuntu и Debian

Сначала обновите пакеты системного программного обеспечения, а затем установите resolvconf из официальных репозиториев, выполнив следующие команды.

После завершения установки resolvconf systemd инициирует автоматический запуск и включение службы resolvconf.service. Чтобы проверить, работает ли он, выполните следующую команду.

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

Настройка постоянных DNS-серверов имен в Ubuntu и Debian

Затем откройте файл конфигурации /etc/resolvconf/resolv.conf.d/head.

и добавьте в него следующие строки:

Сохраните изменения и перезапустите resolvconf.service и systemd-resolved или перезагрузите систему.

Теперь, когда вы проверяете файл /etc/resolv.conf, записи сервера имен должны храниться там постоянно. Отныне у вас не будет проблем с разрешением имен в вашей системе.

Я надеюсь, что эта короткая статья помогла вам настроить постоянные DNS-серверы имен в ваших системах Ubuntu и Debian. Если у вас есть какие-либо вопросы или предложения, поделитесь ими с нами в разделе комментариев ниже.

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

Если вы цените то, что мы делаем здесь, в TecMint, вам следует подумать о следующем:

TecMint – это самый быстрорастущий и пользующийся наибольшим доверием сайт сообщества, где можно найти любые статьи, руководства и книги по Linux в Интернете. Миллионы людей посещают TecMint! для поиска или просмотра тысяч опубликованных статей, доступных всем БЕСПЛАТНО.

Если вам нравится то, что вы читаете, купите нам кофе (или 2) в знак признательности.

Мы благодарны за вашу бесконечную поддержку.

7 ответов 7

Сначала вам нужно немного узнать о том, как работает разрешение имен в Ubuntu, начиная с Ubuntu 12.04.

Стефан Грабер в прошлом году разместил в своем блоге некоторую информацию об этом. Самое важное, что нужно знать, это то, что и Ubuntu Server, и Ubuntu Desktop используют resolvconf для управления файлом resolv.conf. Это означает, что вам больше не нужно напрямую редактировать файл /etc/resolv.conf; вместо этого вы должны настроить утилиту настройки сетевого интерфейса, чтобы предоставить правильную информацию для resolvconf. Для Ubuntu Server утилита настройки сетевого интерфейса называется ifup и настраивается в файле /etc/network/interfaces. Для Ubuntu Desktop утилитой настройки сетевого интерфейса является NetworkManager. Это то, что вы используете.

NetworkManager настраивается с помощью индикатора сети > Изменить соединения. Однако для сетевых интерфейсов, настроенных с помощью DHCP, обычно нет необходимости изменять какие-либо настройки вручную. Обычно происходит то, что (удаленный) DHCP-сервер предоставляет NetworkManager как IP-адрес для локального интерфейса, так и адрес (удаленного) DNS-сервера имен для использования. NetworkManager запускает экземпляр пересылающего сервера имен, который прослушивает локально по адресу 127.0.1.1. Этот адрес, 127.0.1.1, отправляется в resolvconf, который помещает сервер имен 127.0.1.1 в /etc/resolv.conf. NetworkManager также предоставляет (удаленный) IP-адрес сервера имен DNS, предоставляемого DHCP, серверу имен переадресации. Таким образом, программа, работающая в локальной системе, просит преобразователь преобразовать имя хоста в IP-адрес; преобразователь запрашивает локальный сервер имен пересылки по адресу 127.0.1.1; пересылающий сервер имен запрашивает удаленные серверы имен, о которых ему было сказано, получает ответ и отправляет его обратно вверх по цепочке.

NetworkManager взаимодействует с процессом переадресации сервера имен по шине D-Bus. Вы можете увидеть, что NetworkManager сообщил серверу имен переадресации, выполнив команду

В этой первой части двухчастного введения в поиск и устранение неполадок DNS вы узнаете, как разобраться и найти проблему.

Опубликовано: 29 апреля 2020 г. | Глен Ньюэлл

Дополнительные ресурсы по Linux

DNS и просмотр веб-страниц

DNS используется, когда вы вводите имя в браузере, чтобы перейти на веб-сайт. Например, давайте посмотрим на адрес:

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

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

Давайте попробуем другое: бегемот — это хост в моей лаборатории, который выполняет обработку для Folding at Home.

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

Это (NXDOMAIN) — код ошибки, означающий, что преобразователь понятия не имеет, где искать гигантское имя хоста. Я попытаюсь получить дополнительную информацию с помощью команды dig.

Это заголовок, который представляет собой сводку того, что делает команда dig. Мы видим код операции: QUERY , что означает, что это ответ на запрос, затем мы снова видим этот ответ NXDOMAIN. Затем он сообщает нам, что был один запрос без ответа, и запрос был представлен одному полномочному ( AUTHORITY ) и одному другому типу преобразователя DNS ( ADDITIONAL ). К чему это приводит, так это к тому, что никто не знает, кто этот сервер и где его найти.

Здесь у нас есть дополнительная информация, в том числе информация, которую мы запросили для записи A, или основная запись для сервера (это значение по умолчанию, если мы не указываем тип записи). Например, мы также могли искать запись MX (почта) или CNAME (имя, указывающее на другое имя).

Попробуем еще раз после того, как добавим суффикс локального домена леса :

Ага! Теперь копаем :

Обратите внимание на статус NOERROR. Похоже, нам удалось получить ответ от локального DNS-сервера.

В этом выводе отображается запись A для behemoth вместе с содержимым этой записи.

Давайте посмотрим на домен леса:

Здесь мы видим, что Start of Authority для домена леса — это сервер с именем io , поэтому, если по какой-то причине нам нужно изменить или подтвердить информацию в домене леса, мы должны сделать это там.

Это немного о понимании DNS и начале обучения использованию команд dig и host для устранения неполадок. Вскоре у нас будет более подробное руководство, а также несколько советов по настройке собственного локального DNS-сервера!

[ Хотите больше для своей сети? Загрузите бесплатную электронную книгу по автоматизации сети с помощью Ansible. ]

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

Например:
Компьютер 1:
ОС: Debian 10
имя хоста: debian
ip-адрес: 192.168.1.70

Компьютер 2:
ОС: Linux Mint 19.2 Tina
имя хоста: mint
ip-адрес: 192.168.1.79

Локальный маршрутизатор:
IP-адрес: 192.168.1.254

Я могу пропинговать Mint из Debian, используя:

Кажется, что от маршрутизатора получен правильный ответ, но запрос повторяется несколько раз. И в конечном итоге терпит неудачу. Есть идеи, в чем здесь может быть проблема?

Вы включили общий доступ на обеих машинах? Можете ли вы пропинговать Google с машины Mint? Вы также можете попробовать пропинговать саму машину монетного двора и установить, что вы получите обратно.
Я бы также проверил маршрутизатор, чтобы узнать, заблокирован ли исходящий IP-адрес монетного двора. Проверьте также настройки брандмауэра, возможно, он блокирует исходящие сообщения Mint, но вряд ли это произойдет..

Машина монетного двора не заблокирована. Он получает ответ DNS от маршрутизатора. Итак, теперь у него есть IP-адрес debian. Но все равно жалуется, что имя неизвестно. Когда на самом деле это известно или должно быть из ответа. Для меня это указывает, возможно, на проблему с самой службой разрешения DNS, а не на проблему с блокировкой трафика.

К сожалению, вы не показываете запросы для нелокальных имен, но то, что я вижу здесь в сети для успешно разрешенных имен, это

То есть поменяв местами OPT и A.

Mint использует systemd-resolved, и кажется правдоподобным, что ваш маршрутизатор «особенный» или даже просто глючит, и что systemd-resolved отказывается отвечать. Очевидно, что мы должны компенсировать то, что у вас работает в других системах, и самым простым тестом будет ненадолго отключить systemd-resolved:

или перезагрузите компьютер. Если у вас все работает, то мы можем, по крайней мере, быть уверены, что это (комбинация) systemd-resolved (и ваш маршрутизатор).

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

В любом случае. сначала просто попробуйте.

Я также включил файл wireshark, связанный со связанным изображением, в исходное сообщение (mint2.pcapng — с включенным systemd-resolved).

С удалением systemd-resolve что теперь обрабатывает разрешение DNS?

Что я могу сделать сейчас, чтобы определить, вызывает ли проблема мой маршрутизатор или проблема решается systemd?

Я совершенно уверен, что это комбинация; на самом деле вполне уверен, что на вашем маршрутизаторе работает старая версия dnsmasq, поскольку они обычно работают, и у него действительно есть проблемы с EDNS, то есть с OPT. К сожалению, я нахожусь в разгар перестройки системы и не могу легко протестировать вещи, но я ожидаю, что именно параметры edns0 в стандартном /run/systemd/resolve/stub-resolv.conf являются причиной вашего маршрутизатор для отключения.

Легко проверить, по крайней мере, действительно ли проблема заключается в добавленной опции. То есть снова включите systemd-resolved:

удалить/закомментировать dns=default в разделе [main] файла /etc/NetworkManager/NetworkManager.conf и

Однако на этот раз вместо того, чтобы связывать /etc/resolv.conf с /run/systemd/resolve/stub-resolv.conf, вы предоставляете то же самое содержимое, в котором отсутствует только строка options edns0:

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

и установите глобальную переменную среды RES_OPTIONS= (т. е. пустую), например, в /etc/profile ( man resolv.conf ) и перезагрузитесь, но это не проверено.

Во время поиска в Google я наткнулся на несколько указаний на то, что проблема или проблема, очень похожая на нее, НЕ присутствует в апстриме systemd-resolved; специфичен для Ubuntu systemd 2.37, которую мы используем. Использует ли ваша система Debian 10 systemd >= 2.40? Если это так, вы могли бы наоборот включить systemd-resolved на нем, как указано выше --- без редактирования/перезапуска NetworkManager, если Debian или ваша установка не используют его, с ln -s и без установки RES_OPTIONS= --- и посмотрите, есть ли проблема в этой системе в этот момент.

Что касается более общего вопроса: концептуально каждая программа выполняет свое собственное разрешение DNS и что-то вроде, например. копать действительно делает.Обычно они ссылаются на системный распознаватель, часть системной библиотеки, которая связывается с DNS-серверами, настроенными в /etc/resolv.conf; systemd-resolved просто вставляет себя как своего рода кеширующий прокси/ретранслятор между указанным системным распознавателем и вашим вышестоящим сервером(ами), который он получает из своих собственных файлов конфигурации или, в случае NetworkManager, из NetworkManager/ dhclient через D-Bus.

В Ubuntu dnsmasq раньше делал/был похож, а systemd-resolved, как ни удивительно, сам по себе не является полностью злом. Чего он явно не делает, так это делает что-то вроде опций edns0 необязательными/настраиваемыми, но если эта реальная проблема действительно связана с Ubuntu или Ubuntu 18.04, я бы сказал, что мы не можем жаловаться на это слишком громко.

но теперь DNS-запрос отправляется на 75.153.171.122 DNS-сервер моего интернет-провайдера в обход моего локального маршрутизатора 192.168.1.254 . Разве он не должен использовать маршрутизатор, поскольку он указан первым?

Запрос отправляется на вышестоящий сервер(ы); Суть здесь, по-видимому, в том, что вы не должны иметь свой сервер интернет-провайдера в качестве вышестоящего сервера на вашем хосте, в первую очередь, только на вашем маршрутизаторе. То есть хост -> 192.168.1.254 -> 75.153.171.122.

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

Я нашел настройку в маршрутизаторе, чтобы исправить эту конфигурацию. DNS2 был настроен на передачу DNS из WAN-подключения. Я изменил его, чтобы он указывал на шлюз.

Однако мой вопрос больше касался приоритета DNS. Несмотря на то, что маршрутизатор устанавливал DNS2 в качестве вышестоящего DNS-сервера, не должен ли мой компьютер использовать DNS1 (т.е. мой локальный маршрутизатор) в качестве DNS-сервера вместо использования сервера DNS2?

В ходе некоторых локальных тестов я больше не видел, чтобы записи OPT отправлялись с «options edns0», удаленными из /etc/resolv.conf. НЕ участвовать, так что нет, я не верю, что EDNS не будет для вас основной проблемой.

Тем не менее, если вы уверены, что тестируете правильно, я не могу предложить ничего другого, кроме как оставить systemd-resolved отключенным --- который вы проверили на работоспособность, так почему вы этого не делаете? Если дело в том, что вы хотите его локальное кеширование: у меня из-за не связанных с этим проблем были некоторые проблемы с DNS, и я избавился от них, отключив также systemd-resolved, после чего оказалось, что Ubuntu/Mint все еще полностью готов к переключению обратно на маска DNS; кажется, он установлен по умолчанию.

Отредактируйте /etc/NetworkManager/NetworkManager.conf, чтобы вставить «dns=dnsmasq» в раздел [main], при необходимости создайте файл, например, /etc/NetworkManager/dnsmasq.d/cache-size.conf, состоящий из

чтобы иметь локальный кеш DNS на 1000 имен (150 — это значение по умолчанию для dnsmasq, но 0 — это значение по умолчанию для Ubuntu/Mint, если вы не будете вмешиваться таким образом), и

Лично я пока не вижу причин возвращаться к systemd-resolved; установка dnsmasq намного быстрее для одного.

Я, безусловно, ценю вашу помощь в поиске обходного пути, чтобы заставить все работать на данный момент. Я заинтересован в том, чтобы продолжить это, чтобы определить основную причину проблемы, чтобы, если это проблема с systemd-resolved, ее можно было исправить для меня и, возможно, для других. И если это проблема с маршрутизатором (т. е. разворот OPT A), я буду рад возложить вину на него и оставить это в покое. Является ли это обращение нарушением протокола DNS? Может быть, я неправильно истолковал, но похоже, что вы не хотите делать такой вывод. А если вы не знаете, у кого я могу спросить?

Является ли это обращение нарушением протокола DNS? Возможно, я неправильно интерпретировал, но кажется, что вы не хотите делать такой вывод.

Да, несколько неохотно. В частности, насколько я знаю, это нарушение, но я, когда смотрю на ваш mint.pcapng wireshark, на самом деле не рвет на ответ; кажется, декодирует его разумно --- даже если с фактическим ответом A в дополнительном разделе RR, а не в разделе обычного ответа RR. Это кажется по меньшей мере странным; вполне вероятно, что это обычная ошибка в вашем маршрутизаторе, но я бы не считал себя экспертом по DNS на уровне проводных сетей; нужно было бы копаться в RFC, чтобы заявить об этом вне всякого (какого-либо) сомнения, теперь, когда wireshark не мигает большим красным «опасно! опасность!» знак.

В своем последнем сообщении вы указали, что что-то все еще отправляет запросы OPT даже без "options edns0" в /etc/resolve.conf. Этот файл, как сказано, является файлом конфигурации для распознавателя glibc, и если вы видите, что OPT-запросы отправляются, например, просто пропингуйте, когда оператор options удален, что мне кажется не имеет особого смысла. Желательно сначала убедиться, что там происходит.

Это сказано.Вероятность того, что проблема не связана с вашим маршрутизатором, составляет примерно 2 %. Ваш маршрутизатор (вероятно) не будет единственным в своем роде, но я бы предположил, исходя из его поведения в отношении EDNS, что он старше, и может предположить, исходя из срабатывания системного разрешения, что он не получил широкого распространения. Ну, очень широко. Параметр EDNS, как было указано где-то выше, довольно новый, поэтому отчеты об ошибках могут приветствоваться в любом случае --- после того, как вы убедитесь, что он не относится к версии Ubuntu 2.37, о которой я, как я уже упоминал, видел некоторые признаки ранее.

О, кстати, при поиске я заметил запрос .local, отправляемый вверх по течению, теперь, когда я использую dnsmasq, а не systemd-resolved. То есть: если кто-то использует этот поток, чтобы также переключиться на dnsmasq, лучше всего дополнительно сделать дамп файла, например. local.conf в /etc/NetworkManager/dnsmasq.d/, состоящий из

.local — это стандартный локальный суффикс mDNS; .home и .lan — это (OpenWrt/DD-WRT) локальные домены по умолчанию, которые часто используют маршрутизаторы. Не стесняйтесь добавлять «domain/» для любого другого домена, который вы не хотите передавать по сети.

Надеюсь, это должно подтвердить, что я правильно следовал вашим инструкциям.
1) systemd-resolved включен и работает
2) удален dns=default в /etc/NetworkManager/NetworkManager.conf
3) удалена ссылка resolv.conf
4) resolv .conf больше не содержит параметров edns0

Прилагается захват wireshark при запуске $ ping debian
** Примечание: переименуйте файл в .pcapng

Я вижу такое же поведение. EDNS все еще используется? Есть ли способ проверить, используется ли EDNS, даже если опции edns0 больше нет? Или есть способ явно отключить EDNS в дополнение к простому исключению его из файла конфигурации NetworkManager?

Похоже, что (ваш) systemd-resolved все еще использует EDNS; что 127.0.0.53 -> восходящий и наоборот по-прежнему использует EDNS, даже если вы, скорее всего, не увидите OPT-трафик к самому 127.0.0.53 (для которого вам нужно выбрать «lo» или, лучше, «all» в качестве вашего интерфейс захвата); в настоящее время не может перепроверить здесь. Нет, насколько я понимаю, нет (очевидного) способа повлиять на это, что меня ничуть не удивило бы. Проклятая вещь, столь же непрозрачная или просто ненастраиваемая, как и все остальное, выходящее из этого уголка Linux-пространства, - вот что побудило меня избавиться от нее, как указано выше, и пересмотреть это только в том случае, если я серьезно к. Боюсь сказать, что это также означает, что я сам оставлю это на вышеуказанных шагах с 1 по 4 в качестве совета.

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