Зарегистрируйтесь в локальном днс субъекта или добавьте в ветку hosts
Обновлено: 03.07.2024
В этом приложении описываются распространенные проблемы и ошибки, связанные с libvirt, а также инструкции по их устранению.
Найдите ошибку в таблице ниже и перейдите по соответствующей ссылке в разделе "Решение", чтобы получить подробные сведения об устранении неполадок.
Таблица А.1. Распространенные ошибки libvirt
Гость может общаться с другими гостями, но не может подключиться к хост-компьютеру после настройки на использование сетевого интерфейса macvtap (или type='direct').
А.19.1. libvirtd не удалось запустить
Примечание
Эта строка по умолчанию закомментирована, чтобы libvirt не создавал лишние сообщения журнала. После диагностики проблемы рекомендуется еще раз прокомментировать эту строку в файле /etc/libvirt/libvirtd.conf.
Справочная страница libvirtd показывает, что отсутствующий файл cacert.pem используется в качестве полномочий TLS, когда libvirt запускается в режиме прослушивания соединений TCP/IP. Это означает, что передается параметр --listen.
Примечание
Для получения дополнительной информации о сертификатах ЦС и настройке системной аутентификации см. главу "Управление сертификатами и центрами сертификации" в Руководстве по идентификации домена, аутентификации и политике Red Hat Enterprise Linux 7.
Не используйте TLS; вместо этого используйте голый TCP. В /etc/libvirt/libvirtd.conf установите listen_tls = 0 и listen_tcp = 1. Значения по умолчанию: listen_tls = 1 и listen_tcp = 0 .
Не передавайте параметр --listen. В /etc/sysconfig/libvirtd.conf измените переменную LIBVIRTD_ARGS.
А.19.2. URI не удалось подключиться к гипервизору
А.19.2.1. Не удается прочитать сертификат ЦС
Сообщение об ошибке вводит в заблуждение относительно фактической причины. Эта ошибка может быть вызвана целым рядом факторов, например неверно указанным URI или ненастроенным подключением.
При указании qemu://system или qemu://session в качестве URI подключения virsh пытается подключиться к системе или сеанс соответственно. Это связано с тем, что virsh распознает текст после второй косой черты как хост.
Используйте три косые черты для подключения к локальному хосту. Например, если указать qemu:///system, virsh подключится к экземпляру system libvirtd на локальном хосте.
URI правильный (например, qemu[+tls]://server/system ), но сертификаты неправильно настроены на вашем компьютере. Информацию о настройке TLS см. на веб-сайте основной ветки разработки libvirt.
А.19.2.2. не удалось подключиться к серверу по адресу 'host:16509': в соединении отказано
Демон libvirt не прослушивает порты TCP даже после изменения конфигурации в /etc/libvirt/libvirtd.conf:
А.19.2.3. Ошибка аутентификации
Если аутентификация завершается ошибкой даже при использовании правильных учетных данных, возможно, аутентификация SASL не настроена.
Отредактируйте файл /etc/libvirt/libvirtd.conf и задайте для параметра auth_tcp значение sasl . Чтобы проверить:
А.19.2.4. Разрешение отклонено
А.19.3. Ошибка загрузки PXE (или DHCP) в гостевой системе
Гостевая виртуальная машина запускается успешно, но затем либо не может получить IP-адрес от DHCP, либо загружается с использованием протокола PXE, либо и то, и другое. Существует две распространенные причины этой ошибки: установленное для моста длительное время задержки пересылки и когда пакет iptables и ядро не поддерживают правила изменения контрольной суммы.
Это наиболее распространенная причина этой ошибки. Если гостевой сетевой интерфейс подключается к мостовому устройству, на котором включен STP (протокол связующего дерева), а также установлена длительная задержка пересылки, мост не будет пересылать сетевые пакеты с гостевой виртуальной машины на мост, пока не будет достигнуто хотя бы это число. секунд задержки пересылки прошло с момента подключения гостя к мосту. Эта задержка позволяет мосту отслеживать трафик от интерфейса и определять MAC-адреса за ним, а также предотвращать зацикливание пересылки в топологии сети.
Если задержка пересылки больше времени ожидания PXE- или DHCP-клиента гостя, операция клиента завершится ошибкой, и гость либо не сможет загрузиться (в случае PXE), либо не сможет получить IP-адрес (в случае в случае DHCP).
В этом случае измените задержку пересылки на мосту на 0, отключите STP на мосту или и то, и другое.
Примечание
Это решение применимо только в том случае, если мост используется не для соединения нескольких сетей, а просто для соединения нескольких конечных точек с одной сетью (наиболее распространенный вариант использования мостов, используемых libvirt).
Если у гостя есть интерфейсы, подключающиеся к виртуальной сети, управляемой libvirt, отредактируйте определение сети и перезапустите ее. Например, отредактируйте сеть по умолчанию с помощью следующей команды:
Примечание
delay='0' и stp='on' являются настройками по умолчанию для виртуальных сетей, поэтому этот шаг необходим только в том случае, если конфигурация по умолчанию была изменена.
Если гостевой интерфейс подключен к хост-мосту, настроенному вне libvirt, измените настройку задержки.
Добавьте или отредактируйте следующие строки в файле /etc/sysconfig/network-scripts/ifcfg-name_of_bridge, чтобы включить STP с задержкой в 0 секунд:
Примечание
Если name_of_bridge не является корневым мостом в сети, задержка этого моста в конечном итоге будет сброшена до времени задержки, настроенного для корневого моста. Чтобы этого не произошло, отключите STP на name_of_bridge.
Гость пытается получить IP-адрес от DHCP-сервера, работающего непосредственно на узле.
iptables 1.4.10 была первой версией, в которую было добавлено расширение libxt_CHECKSUM. Это происходит, если в журналах libvirtd появляется следующее сообщение:
Важно
Если все остальные три условия в этом списке также не выполняются, приведенное выше предупреждающее сообщение можно игнорировать, и оно не является признаком каких-либо других проблем.
При возникновении этих условий UDP-пакеты, отправляемые с хоста гостю, имеют невычисленные контрольные суммы. Из-за этого UDP-пакеты хоста кажутся недействительными для гостевого сетевого стека.
Чтобы решить эту проблему, отмените любой из четырех пунктов выше. Лучшее решение — обновить iptables хоста и ядро до iptables-1.4.10 или новее, если это возможно. В противном случае наиболее конкретным решением является отключение драйвера vhost-net для этого конкретного гостя. Для этого отредактируйте гостевую конфигурацию с помощью этой команды:
Если проблема все еще не решена, проблема может быть связана с конфликтом между firewalld и сетью libvirt по умолчанию.
Чтобы это исправить, остановите firewalld с помощью команды service firewalld stop, а затем перезапустите libvirt с помощью команды service libvirtd restart.
Примечание
Кроме того, если файл /etc/sysconfig/network-scripts/ifcfg-имя_сети настроен правильно, вы можете убедиться, что гость получит IP-адрес, используя команду dhclient от имени пользователя root на гость.
А.19.4. Гость может получить доступ к внешней сети, но не может получить доступ к хосту при использовании интерфейса macvtap
Гостевая виртуальная машина может взаимодействовать с другими гостями, но не может подключаться к хост-машине после настройки на использование сетевого интерфейса macvtap (также известного как type='direct').
Даже если вы не подключаетесь к агрегатору портов виртуального Ethernet (VEPA) или коммутатору с поддержкой VN-Link, интерфейсы macvtap могут быть полезны. Установка режима моста для такого интерфейса позволяет гостевой системе напрямую подключаться к физической сети очень простым способом без проблем с настройкой (или несовместимости с NetworkManager), которые могут сопровождать использование традиционного хост-устройства моста.
Однако, когда гостевая виртуальная машина настроена на использование сетевого интерфейса type='direct', такого как macvtap, несмотря на то, что у нее есть возможность общаться с другими гостями и другими внешними хостами в сети, гость не может общаться со своими хост.
Эта ситуация на самом деле не является ошибкой — это определенное поведение macvtap. Из-за того, что физический Ethernet хоста подключен к мосту macvtap, трафик на этот мост от гостей, который перенаправляется на физический интерфейс, не может быть возвращен обратно в стек IP хоста. Кроме того, трафик из стека IP хоста, который отправляется на физический интерфейс, не может быть возвращен обратно на мост macvtap для пересылки гостям.
Используйте libvirt для создания изолированной сети и создайте второй интерфейс для каждой гостевой виртуальной машины, подключенной к этой сети. Затем хост и гости могут напрямую общаться через эту изолированную сеть, сохраняя при этом совместимость с NetworkManager .
Процедура А.8. Создание изолированной сети с помощью libvirt
Добавьте и сохраните следующий XML-код в файле /tmp/isolated.xml. Если сеть 192.168.254.0/24 уже используется в вашей сети, вы можете выбрать другую сеть.
Рисунок А.3. Изолированный сетевой XML
Используя virsh edit name_of_guest, отредактируйте конфигурацию каждого гостя, использующего macvtap для своего сетевого подключения, и добавьте новое в раздел, аналогичный следующему (обратите внимание, что эта строка не является обязательной):< /p>
Рисунок А.4. XML устройства интерфейса
Теперь гости могут связаться с хостом по адресу 192.168.254.1, а хост сможет связаться с гостями по IP-адресу, который они получили от DHCP (или вы можете вручную настроить IP-адреса для гостей). ). Поскольку эта новая сеть изолирована только для хоста и гостей, все остальные сообщения от гостей будут использовать интерфейс macvtap. Для получения дополнительной информации см. Раздел 23.17.8, «Сетевые интерфейсы».
А.19.5.Не удалось добавить правило для исправления контрольных сумм ответов DHCP в сети 'default'
Если проблема, с которой вы столкнулись, заключается в том, что гостевые виртуальные машины не могут получить IP-адреса через DHCP, это сообщение можно игнорировать.
Если это так, см. раздел A.19.3, «Сбой загрузки PXE (или DHCP) на гостевой системе» для получения дополнительной информации об этой ситуации.
А.19.6. Не удалось добавить мост br0 порт vnet0: нет такого устройства
Оба сообщения об ошибках показывают, что устройство-мост, указанное в определении гостя (или домена), не существует.
Чтобы убедиться, что мостовое устройство, указанное в сообщении об ошибке, не существует, используйте команду оболочки ip addr show br0 .
Используйте virsh либо для редактирования настроек существующего моста или сети, либо для добавления устройства моста в конфигурацию хост-системы.
Используйте virsh edit name_of_guest, чтобы изменить определение для использования уже существующего моста или сети.
Для libvirt версии 0.9.8 и выше устройство-мост можно создать с помощью команды virsh iface-bridge. Это создает мостовое устройство br0 с подключенным eth0 , физическим сетевым интерфейсом, который установлен как часть моста:
Необязательно: при необходимости удалите этот мост и восстановите исходную конфигурацию eth0 с помощью этой команды:
Для более старых версий libvirt можно вручную создать мостовое устройство на хосте. Инструкции см. в разделе 6.4.3, «Сетевые мосты с помощью libvirt».
А.19.7. Миграция завершается с ошибкой: невозможно определить адрес
Во время переноса libvirtd, запущенный на целевом хосте, создает URI из адреса и порта, через которые он ожидает получить данные миграции, и отправляет их обратно в libvirtd, работающий на исходном хосте.
В этом случае хосту назначения ( 192.168.122.12 ) присвоено имя 'newyork'. По какой-то причине libvirtd, запущенный на этом хосте, не может преобразовать имя в IP-адрес, который можно было бы отправить обратно и при этом по-прежнему использовать. По этой причине он вернул имя хоста 'newyork', надеясь, что исходный libvirtd справится с разрешением имени более успешно. Это может произойти, если DNS настроен неправильно или в файле /etc/hosts имя хоста связано с локальным петлевым адресом ( 127.0.0.1 ).
Обратите внимание, что адрес, используемый для переноса данных, не может быть автоматически определен из адреса, используемого для подключения к целевому libvirtd (например, из qemu+tcp://192.168.122.12/system ). Это связано с тем, что для связи с целевым libvirtd исходному libvirtd может потребоваться использовать сетевую инфраструктуру, отличную от типа, который требуется virsh (возможно, работающему на отдельной машине).
Лучшее решение — правильно настроить DNS, чтобы все хосты, участвующие в миграции, могли разрешать все имена хостов.
Если DNS нельзя настроить для этого, список всех хостов, используемых для миграции, можно добавить вручную в файл /etc/hosts на каждом из хостов. Однако трудно поддерживать согласованность таких списков в динамической среде.
Если имена хостов нельзя сделать разрешимыми каким-либо образом, virsh migrate поддерживает указание хоста миграции:
Назначение libvirtd примет URI tcp://192.168.122.12 и добавит автоматически сгенерированный номер порта. Если это нежелательно (например, из-за настроек брандмауэра), номер порта можно указать в этой команде:
Еще один вариант — использовать туннельную миграцию. Туннелированная миграция не создает отдельного соединения для данных миграции, а вместо этого туннелирует данные через соединение, используемое для связи с целевым libvirtd (например, qemu+tcp://192.168.122.12/system ):
А.19.8. Сбой переноса из-за невозможности разрешить доступ к пути к диску: нет такого файла или каталога
Гостевая виртуальная машина (или домен) не может быть перенесена, так как libvirt не может получить доступ к образу(ам) диска:
По умолчанию миграция передает только состояние памяти запущенного гостевого компьютера (например, состояние памяти или процессора). Хотя образы дисков не переносятся во время переноса, они должны оставаться доступными по одному и тому же пути для обоих хостов.
Настройте и подключите общее хранилище в одном месте на обоих хостах. Самый простой способ сделать это — использовать NFS:
Процедура A.9. Настройка общего хранилища
Настройте сервер NFS на узле, который будет использоваться в качестве общего хранилища. Сервер NFS может быть одним из хостов, участвующих в переносе, при условии, что все задействованные хосты обращаются к общему хранилищу через NFS.
Смонтируйте экспортированный каталог в общем месте на всех хостах, на которых работает libvirt. Например, если IP-адрес сервера NFS — 192.168.122.1, смонтируйте каталог с помощью следующих команд:
Примечание
Невозможно экспортировать локальный каталог с одного хоста с помощью NFS и смонтировать его по тому же пути на другом хосте — каталог, используемый для хранения образов дисков, должен быть смонтирован из общего хранилища на обоих хостах.Если это не настроено правильно, гостевая виртуальная машина может потерять доступ к своим образам дисков во время миграции, потому что демон libvirt исходного хоста может изменить владельца, разрешения и метки SELinux на образах дисков после того, как он успешно мигрирует гостя к месту назначения. .
Если libvirt обнаружит, что образы дисков смонтированы из общего хранилища, эти изменения не будут внесены.
А.19.9. При запуске libvirtd отсутствуют гостевые виртуальные машины
Существуют различные возможные причины этой проблемы. Выполнение этих тестов поможет определить причину этой ситуации:
Если вы используете машину AMD, убедитесь, что модули ядра kvm_amd вместо этого вставлены в ядро, используя аналогичную команду lsmod | grep kvm_amd в корневой оболочке.
Примечание
Хотя это редкость, поддержка виртуализации KVM может быть скомпилирована в ядро. В этом случае модули не нужны.
Включите расширения виртуализации в конфигурации прошивки вашего оборудования в настройках BIOS. Дополнительную информацию см. в документации по оборудованию.
Например, это сообщение показывает, что URI подключен к гипервизору VirtualBox, а не QEMU, и выявляет ошибку конфигурации для URI, который в противном случае настроен для подключения к гипервизору QEMU. Если бы URI правильно подключался к QEMU , вместо этого появилось бы то же сообщение, что и:
Эта ситуация возникает, когда присутствуют другие гипервизоры, с которыми libvirt может общаться по умолчанию.
А.19.10. Распространенные ошибки XML
Инструмент libvirt использует XML-документы для хранения структурированных данных. Множество распространенных ошибок возникает с документами XML, когда они передаются в libvirt через API. Несколько распространенных ошибок XML, включая ошибочные теги XML, недопустимые значения и отсутствующие элементы, подробно описаны ниже.
А.19.10.1. Редактирование определения домена
Хотя это не рекомендуется, иногда необходимо отредактировать XML-файл гостевой виртуальной машины (или домена) вручную. Чтобы получить доступ к гостевому XML для редактирования, используйте следующую команду:
Эта команда открывает файл в текстовом редакторе с текущим определением гостевой виртуальной машины. После завершения редактирования и сохранения изменений XML перезагружается и анализируется libvirt. Если XML правильный, отображается следующее сообщение:
Важно
При использовании команды редактирования в virsh для редактирования XML-документа сохраните все изменения перед выходом из редактора.
После сохранения XML-файла используйте команду xmllint, чтобы проверить правильность формата XML, или команду virt-xml-validate, чтобы проверить наличие проблем с использованием:
Если ошибки не возвращаются, XML-описание правильно сформировано и соответствует схеме libvirt. Хотя схема не учитывает все ограничения, исправление обнаруженных ошибок улучшит устранение неполадок.
Эти документы содержат определения состояний и конфигураций для гостей. Эти документы создаются автоматически и не должны редактироваться вручную. Ошибки в этих документах содержат имя файла поврежденного документа. Имя файла допустимо только на хост-компьютере, указанном в URI, который может видеть компьютер, на котором была запущена команда.
Ошибки в файлах, созданных libvirt, случаются редко. Тем не менее, одним из возможных источников этих ошибок является более ранняя версия libvirt — в то время как более новые версии libvirt всегда могут читать XML, сгенерированный более ранними версиями, более старые версии libvirt могут быть сбиты с толку элементами XML, добавленными в более новой версии.
А.19.10.2. Ошибки синтаксиса XML
Синтаксические ошибки обнаруживаются синтаксическим анализатором XML. Сообщение об ошибке содержит информацию для определения проблемы.
Этот пример сообщения об ошибке от синтаксического анализатора XML состоит из трех строк: первая строка обозначает сообщение об ошибке, а две следующие строки содержат контекст и расположение XML-кода, содержащего ошибку. Третья строка содержит индикатор, показывающий примерное местонахождение ошибки на строке выше:
Это имя файла документа, содержащего ошибку. Имена файлов в круглых скобках являются символическими именами для описания документов XML, проанализированных из памяти, и не соответствуют напрямую файлам на диске. Имена файлов, не заключенные в круглые скобки, являются локальными файлами, находящимися в целевом объекте соединения.
В этой статье описаны способы устранения проблемы, из-за которой IP-адрес регистрирует запись A для имени хоста в своей основной зоне DNS-суффиксов. Эта проблема возникает после снятия флажка «Зарегистрировать адрес этого подключения в DNS».
Применимо к: Windows 2000
Исходный номер базы знаний: 275554
Эта статья относится к Windows 2000. Поддержка Windows 2000 заканчивается 13 июля 2010 г. Центр решений по окончанию поддержки Windows 2000 — это отправная точка для планирования стратегии перехода с Windows 2000. Дополнительную информацию см. в Microsoft Политика жизненного цикла поддержки.
Симптомы
В Windows 2000 снимите флажок Зарегистрировать адрес этого подключения в DNS в разделе Дополнительные параметры TCP/IP для сетевого интерфейса. В этом случае IP-адрес может зарегистрировать запись A для имени хоста в своей основной зоне суффикса DNS.
Например, такое поведение может возникнуть, если у вас есть следующая конфигурация:
Причина
По умолчанию, если служба DNS установлена на компьютере под управлением Windows 2000, она прослушивает все сетевые интерфейсы, настроенные с использованием TCP/IP. Когда DNS заставляет интерфейс прослушивать DNS-запросы, интерфейс пытается зарегистрировать запись A хоста в зоне, которая соответствует его основному суффиксу DNS. Интерфейс пытается зарегистрировать запись A хоста независимо от параметров, настроенных в свойствах TCP/IP. Такое поведение является преднамеренным и может иметь место при следующих обстоятельствах:
- Служба DNS установлена на сервере, конфигурацию которого вы пытаетесь изменить.
- Зона DNS, соответствующая основному DNS-суффиксу сервера, может динамически обновляться.
Разрешение
Разрешение, описанное в этой статье, работает только на рядовых серверах, на которых работает DNS в домене. Это не решает эту проблему на компьютерах контроллера домена. Дополнительные сведения о том, как решить эту проблему на контроллере домена, см. в разделе Проблемы разрешения имен и подключения на сервере маршрутизации и удаленного доступа, на котором также работает DNS или WINS.
Чтобы запретить DNS-серверу регистрировать запись A для определенного интерфейса в своей основной зоне DNS-суффиксов, используйте один из следующих методов.
Способ 1
Этот раздел, метод или задача содержат инструкции по изменению реестра. Однако при неправильном изменении реестра могут возникнуть серьезные проблемы. Поэтому убедитесь, что вы внимательно выполните следующие действия. Для дополнительной защиты создайте резервную копию реестра перед его изменением. Затем вы можете восстановить реестр, если возникнет проблема. Дополнительные сведения о резервном копировании и восстановлении реестра см. в разделе Резервное копирование и восстановление реестра в Windows.
Настройте службу DNS для публикации определенных IP-адресов в зоне DNS. Для этого внесите следующие изменения в реестр:
- Адрес публикации: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
- Тип данных: REG_SZ
- Диапазон: IP-адрес [IP-адрес]
- Значение по умолчанию: пусто
Эта модификация указывает IP-адреса, которые вы хотите опубликовать для компьютера. DNS-сервер создает записи A только для адресов из этого списка. Если эта запись отсутствует в реестре или ее значение пусто, DNS-сервер создает запись A для каждого IP-адреса компьютера.
Эта запись предназначена для компьютеров с несколькими IP-адресами, из которых вы хотите опубликовать только часть. Как правило, это предотвращает возврат DNS-сервером частного сетевого адреса в ответ на запрос, если компьютер имеет корпоративный сетевой адрес.
DNS считывает записи реестра только при запуске. Вы можете изменять записи во время работы DNS-сервера с помощью консоли DNS. Если вы измените записи, отредактировав реестр, изменения вступят в силу только после перезапуска DNS-сервера.
DNS-сервер не добавляет эту запись в реестр. Вы можете добавить его, отредактировав реестр или воспользовавшись программой, которая редактирует реестр.
Метод 2
Удалить интерфейс из списка интерфейсов, прослушиваемых DNS-сервером. Для этого выполните следующие действия:
- Запустите консоль управления DNS (MMC).
- Щелкните правой кнопкой мыши DNS-сервер и выберите "Свойства".
- Выберите вкладку "Интерфейсы".
- В разделе "Прослушивать" установите флажок "Только следующие IP-адреса".
- Введите IP-адреса, которые вы хотите, чтобы сервер прослушивал. Включите только IP-адреса интерфейсов, для которых вы хотите, чтобы запись A хоста была зарегистрирована в DNS.
- Нажмите "ОК" и закройте консоль управления DNS.
Статус
Microsoft подтвердила, что проблема связана с продуктами, перечисленными в начале этой статьи.
Подробнее
Дополнительную информацию о том, как отключить динамическую регистрацию, см. в разделе Как включить или отключить обновления DNS в Windows 2000 и Windows Server 2003.
Раздел реестра для отключения динамического обновления службы DHCP-клиента:
- Путь: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DisableDynamicUpdate
- Тип данных: REG_DWORD
- Диапазон: 0–1
- Значение по умолчанию: 0
Этот раздел реестра не решает проблему, описанную в этой статье. Если DNS-сервер прослушивает определенный интерфейс, регистрируется запись A хоста для этого интерфейса.
Если вы удалите IP-адрес из списка прослушивающих интерфейсов DNS-сервера, сервер больше не будет принимать DNS-запросы, отправленные на этот IP-адрес. Этот параметр иногда используется в ситуациях, когда DNS-сервер также является контроллером домена и имеет интерфейс, подключенный к несвязанной сети. Для такой конфигурации убедитесь, что клиентские компьютеры Active Directory не направляют никаких запросов интерфейсу, к которому они не могут получить доступ.
Как правило, доменное имя представляет собой IP-адрес и связано с ним в системе доменных имен (DNS). В этой статье объясняется, как настроить разрешение доменных имен и разрешать доменные имена.
Содержание
Переключение службы имен
Эту статью или раздел необходимо расширить.
Переключатель службы имен (NSS) является частью библиотеки GNU C Library ( glibc ) и поддерживает API getaddrinfo(3), используемый для разрешения доменных имен. NSS позволяет предоставлять системные базы данных отдельными службами, порядок поиска которых может быть настроен администратором в nsswitch.conf(5) . Базой данных, отвечающей за разрешение доменных имен, является база данных hosts, для которой glibc предлагает следующие услуги:
- файлы: читает файл /etc/hosts, см. hosts(5)
- dns: сопоставитель glibc, который читает /etc/resolv.conf , см. resolv.conf(5)
systemd предоставляет три службы NSS для разрешения имени хоста:
Разрешение доменного имени с помощью NSS
К базам данных NSS можно обращаться с помощью getent(1) . Доменное имя может быть разрешено через NSS с использованием:
Распознаватель Glibc
Распознаватель glibc читает файл /etc/resolv.conf для каждого разрешения, чтобы определить серверы имен и используемые параметры.
Перезапись /etc/resolv.conf
Сетевые менеджеры склонны перезаписывать /etc/resolv.conf , подробности см. в соответствующем разделе:
Чтобы предотвратить перезапись файла /etc/resolv.conf программами, его также можно защитить от записи, установив неизменяемый атрибут файла:
Ограничить время поиска
Если вы сталкиваетесь с очень долгим поиском имени хоста (может быть, в pacman или во время просмотра), часто помогает определить небольшой тайм-аут, после которого используется альтернативный сервер имен. Для этого поместите следующее в /etc/resolv.conf .
Поиск имени хоста задерживается из-за IPv6
Если вы испытываете 5-секундную задержку при разрешении имен хостов, это может быть связано с неправильным поведением DNS-сервера/брандмауэра и предоставлением только одного ответа на параллельный запрос A и AAAA.[1] Вы можете исправить это, установив следующую опцию в /etc/resolv.conf:
Локальные доменные имена
Чтобы иметь возможность использовать имена хостов локальных компьютеров без полного доменного имени, добавьте в /etc/resolv.conf строку с локальным доменом, например:
Утилиты поиска
Для запроса определенных DNS-серверов и записей DNS/DNSSEC можно использовать специальные утилиты поиска DNS. Эти инструменты сами реализуют DNS и не используют NSS.
ldns предоставляет Drill(1) , инструмент, предназначенный для извлечения информации из DNS.
Например, чтобы запросить у определенного сервера имен с помощью drill записи TXT домена:
Если не указан DNS-сервер, drill будет использовать серверы имен, определенные в /etc/resolv.conf .
- knot предоставляет khost(1) и kdig(1) . имеет несвязанный-хост(1) . имеет dig(1), host(1), nslookup(1) и набор инструментов dnssec-.
Производительность преобразователя
Распознаватель Glibc не кэширует запросы. Чтобы реализовать локальное кэширование, используйте systemd-resolved или настройте локальный кэширующий DNS-сервер и используйте его в качестве сервера имен, установив 127.0.0.1 и ::1 в качестве серверов имен в /etc/resolv.conf или в /etc/resolvconf. .conf при использовании openresolv.
- Утилиты drill или diglookup сообщают о времени запроса.
- Маршрутизатор обычно устанавливает собственный преобразователь кэширования в качестве DNS-сервера сети, таким образом обеспечивая DNS-кэш для всей сети.
- Если переключение на следующий DNS-сервер занимает слишком много времени, попробуйте уменьшить время ожидания.
Конфиденциальность и безопасность
Протокол DNS не зашифрован и не обеспечивает конфиденциальность, целостность или аутентификацию, поэтому, если вы используете ненадежную сеть или злонамеренного интернет-провайдера, ваши DNS-запросы могут быть перехвачены, а ответы могут быть изменены. Кроме того, DNS-серверы могут осуществлять перехват DNS.
DNS уровня приложения
Забывчивый DNS
Oblivious DNS – это система, которая решает ряд проблем с конфиденциальностью DNS. См. статью Cloudflare для получения дополнительной информации.
Сторонние службы DNS
Примечание. Прежде чем использовать стороннюю службу DNS, ознакомьтесь с ее политикой конфиденциальности, чтобы узнать, как обрабатываются пользовательские данные. Пользовательские данные имеют ценность и могут быть проданы другим сторонам.
DNS-серверы
DNS-серверы могут быть авторитетными и рекурсивными. Если они не являются ни тем, ни другим, они называются резолверами-заглушками и просто перенаправляют все запросы на другой рекурсивный сервер имен.Преобразователи-заглушки обычно используются для внедрения кэширования DNS на локальном хосте или в сети. Обратите внимание, что того же можно добиться и с полноценным сервером имен. В этом разделе сравниваются доступные DNS-серверы. Более подробное сравнение см. в Википедии: Сравнение программного обеспечения DNS-серверов.
Эту статью или раздел необходимо расширить.
Только авторизованные серверы
Условная переадресация
При запросе определенных доменных имен можно использовать определенные преобразователи DNS. Это особенно полезно при подключении к VPN, так как запросы к сети VPN разрешаются DNS VPN, в то время как запросы к Интернету по-прежнему будут разрешаться вашим стандартным преобразователем DNS. Его также можно использовать в локальных сетях.
Чтобы реализовать это, вам нужно использовать локальный преобразователь, потому что glibc его не поддерживает.
В динамической среде (ноутбуки и, в некоторой степени, настольные компьютеры) вам необходимо настроить резолвер в зависимости от сетей, к которым вы подключены. Лучший способ сделать это — использовать openresolv, поскольку он поддерживает несколько подписчиков. Некоторые сетевые менеджеры поддерживают его либо через openresolv, либо путем непосредственной настройки распознавателя. NetworkManager поддерживает условную переадресацию без openresolv.
Примечание. Хотя для переадресации можно использовать и другие условия (например, исходный IP-адрес), "условная переадресация" используется для условия "запрошен домен".
DNS (система доменных имен) необходима для преобразования доменных имен и имен хостов в IP-адреса. Таким образом, IP-адрес 192.168.2.100 назначается, например, имени хоста jupiter. Перед настройкой собственного сервера имен ознакомьтесь с общей информацией о DNS в Разделе 19.3, «Разрешение имен». Следующие примеры конфигурации относятся к BIND, DNS-серверу по умолчанию.
DNS-сервер — это сервер, на котором хранится информация об имени и IP-адресе домена. У вас может быть первичный DNS-сервер для основной зоны, дополнительный сервер для подчиненной зоны или подчиненный сервер без каких-либо зон для кэширования.
Главная зона включает все узлы вашей сети, а главная зона DNS-сервера хранит актуальные записи для всех узлов вашего домена.
DNS-сервер подчиненной зоны
Подчиненная зона — это копия основной зоны. DNS-сервер подчиненной зоны получает данные своей зоны с операциями передачи зоны от своего главного сервера. DNS-сервер подчиненной зоны авторитетно отвечает за зону, если у него есть действительные (не просроченные) данные зоны. Если ведомое устройство не может получить новую копию данных зоны, оно перестает отвечать за зону.
Переадресаторы — это DNS-серверы, на которые ваш DNS-сервер должен отправлять запросы, на которые он не может ответить. Чтобы включить разные источники конфигурации в одной конфигурации, используется netconfig (см. также man 8 netconfig ).
Запись NS сообщает серверам имен, какие машины отвечают за данную доменную зону.
Записи MX (обмена почтой) описывают компьютеры, с которыми необходимо связаться для пересылки почты через Интернет.
Запись SOA (Start of Authority) — это первая запись в файле зоны. Запись SOA используется при использовании DNS для синхронизации данных между несколькими компьютерами.
Чтобы установить DNS-сервер, запустите YaST и выберите Программное обеспечение › Управление программным обеспечением. Выберите View › Patterns и выберите DHCP and DNS Server. Подтвердите установку зависимых пакетов, чтобы завершить процесс установки.
В качестве альтернативы используйте следующую команду в командной строке:
Используйте DNS-модуль YaST для настройки DNS-сервера для локальной сети. При первом запуске модуля запускается мастер, предлагающий принять несколько решений по администрированию сервера. После завершения этой начальной настройки создается базовая конфигурация сервера. Используйте экспертный режим для решения более сложных задач настройки, таких как настройка списков контроля доступа, ведение журнала, ключи TSIG и другие параметры.
Мастер состоит из трех шагов или диалогов. В соответствующих местах диалогов вы можете войти в экспертный режим настройки.
При первом запуске модуля открывается диалоговое окно настроек сервера пересылки, показанное на Рисунке 32.1, «Установка DNS-сервера: настройки сервера пересылки». Политика разрешения локальных DNS позволяет установить следующие параметры:
Объединение серверов пересылки отключено
Объединение серверов пересылки включено
Пользовательская конфигурация — если выбрана Пользовательская конфигурация, можно указать пользовательскую политику; по умолчанию (с выбранным автоматическим слиянием) для пользовательской политики установлено значение auto , но здесь вы можете либо задать имена интерфейсов, либо выбрать одно из двух имен специальных политик STATIC и STATIC_FALLBACK .
В Local DNS Resolution Forwarder укажите, какую службу использовать: Использование системных серверов имен , Этот сервер имен (привязка) или Локальный сервер dnsmasq .
Дополнительную информацию обо всех этих настройках см. в man 8 netconfig .
Переадресаторы — это DNS-серверы, на которые ваш DNS-сервер отправляет запросы, на которые сам не может ответить. Введите их IP-адрес и нажмите Добавить .
Диалоговое окно «Зоны DNS» состоит из нескольких частей и отвечает за управление файлами зон, описанное в Разделе 32.6, «Файлы зон». Для новой зоны укажите имя для нее в Name . Чтобы добавить обратную зону, имя должно заканчиваться на .in-addr.arpa. Наконец, выберите тип (ведущий, подчиненный или прямой). См. Рисунок 32.2, «Установка DNS-сервера: Зоны DNS». Щелкните Изменить, чтобы настроить другие параметры существующей зоны. Чтобы удалить зону, нажмите Удалить .
В последнем диалоговом окне вы можете открыть порт DNS в брандмауэре, нажав «Открыть порт в брандмауэре» . Затем решите, запускать ли DNS-сервер при загрузке (On или Off). Вы также можете активировать поддержку LDAP. См. Рисунок 32.3, «Установка DNS-сервера: Мастер завершения».
После запуска модуля YaST открывает окно с несколькими параметрами конфигурации. Его выполнение приводит к настройке DNS-сервера с основными функциями:
В разделе «Запуск» укажите, следует ли запускать DNS-сервер при загрузке системы или вручную. Чтобы немедленно запустить DNS-сервер, щелкните Запустить DNS-сервер сейчас. Чтобы остановить DNS-сервер, щелкните Остановить DNS-сервер сейчас. Чтобы сохранить текущие настройки, выберите Сохранить настройки и перезагрузить DNS-сервер сейчас. Вы можете открыть порт DNS в брандмауэре с помощью команды «Открыть порт в брандмауэре» и изменить настройки брандмауэра в разделе «Сведения о брандмауэре» .
При выборе LDAP Support Active файлы зон управляются базой данных LDAP. Любые изменения данных зоны, записанные в базу данных LDAP, перехватываются DNS-сервером при его перезапуске или при появлении запроса на перезагрузку конфигурации.
Если ваш локальный DNS-сервер не может ответить на запрос, он пытается перенаправить запрос серверу пересылки , если он настроен таким образом. Этот сервер пересылки может быть добавлен вручную в список серверов пересылки. Если сервер пересылки не статичен, как в коммутируемом соединении, настройками занимается netconfig. Дополнительные сведения о netconfig см. в man 8 netconfig .
В этом разделе задайте основные параметры сервера. В меню «Параметры» выберите нужный элемент, затем укажите значение в соответствующем текстовом поле. Включите новую запись, выбрав Добавить .
Чтобы указать, что и как должен регистрировать DNS-сервер, выберите Ведение журнала . В разделе Тип журнала укажите, куда DNS-сервер должен записывать данные журнала. Используйте общесистемный журнал, выбрав «Системный журнал», или укажите другой файл, выбрав «Файл». В последнем случае дополнительно укажите имя, максимальный размер файла в мегабайтах и количество сохраняемых версий файла журнала.
Дополнительные параметры доступны в разделе «Дополнительное ведение журнала». Включение регистрации всех DNS-запросов приводит к тому, что каждый запрос регистрируется в журнале, и в этом случае файл журнала может стать очень большим. По этой причине не рекомендуется включать эту опцию только для целей отладки. Чтобы регистрировать трафик данных во время обновлений зоны между DHCP и DNS-сервером, включите Log Zone Updates. Чтобы регистрировать трафик данных во время передачи зоны от ведущего к ведомому, включите Log Zone Transfer. См. Рисунок 32.4, «DNS-сервер: ведение журнала».
Используйте это диалоговое окно для определения ACL (списков управления доступом) для применения ограничений доступа. Указав отдельное имя в поле Имя , укажите IP-адрес (с маской сети или без нее) в поле Значение следующим образом:
Синтаксис файла конфигурации требует, чтобы адрес заканчивался точкой с запятой и заключался в фигурные скобки.
Основной целью TSIG (подписей транзакций) является защита связи между серверами DHCP и DNS. Они описаны в Разделе 32.8, «Безопасные транзакции».
Чтобы сгенерировать ключ TSIG, введите отличительное имя в поле ID ключа и укажите файл, в котором должен храниться ключ ( Имя файла ). Подтвердите свой выбор с помощью Generate .
Чтобы использовать ранее созданный ключ, оставьте поле ID ключа пустым и выберите файл, в котором он хранится, в поле Имя файла . После этого подтвердите с помощью Добавить .
Чтобы добавить подчиненную зону, выберите DNS Zones , выберите тип зоны Slave , напишите имя новой зоны и нажмите Add .
В диалоговом окне редактора зон в разделе IP-адрес главного DNS-сервера укажите главный сервер, с которого подчиненный сервер должен получать свои данные. Чтобы ограничить доступ к серверу, выберите один из ACL из списка.
Чтобы изменить основную зону, выберите Зоны DNS , выберите основную зону из таблицы и нажмите Изменить . Диалоговое окно состоит из нескольких страниц: Basics (открывается первой), NS Records , MX Records , SOA и Records .
Основное диалоговое окно, показанное на Рисунке 32.5, «DNS-сервер: Редактор зон (основы)», позволяет определить параметры динамического DNS и параметры доступа для передачи зон клиентам и подчиненным серверам имен. Чтобы разрешить динамическое обновление зон, выберите Разрешить динамические обновления и соответствующий ключ TSIG. Ключ должен быть определен до начала действия обновления. Чтобы включить передачу зон, выберите соответствующие ACL. ACL должны быть уже определены.
В диалоговом окне «Основные» выберите, следует ли включить передачу зон. Используйте перечисленные ACL, чтобы определить, кто может загружать зоны.
Диалоговое окно NS Records позволяет определить альтернативные серверы имен для указанных зон. Убедитесь, что ваш собственный сервер имен включен в список. Чтобы добавить запись, введите ее имя в разделе «Сервер имен» для добавления, затем подтвердите, нажав «Добавить». См. Рисунок 32.6, «DNS-сервер: Редактор зоны (NS-записи)».
Чтобы добавить почтовый сервер для текущей зоны в существующий список, введите соответствующий адрес и значение приоритета. После этого подтвердите, выбрав Добавить . См. Рисунок 32.7, «DNS-сервер: Редактор зоны (записи MX)».
Это диалоговое окно управляет разрешением имен. В Record Key введите имя хоста, затем выберите его тип. Тип A представляет основную запись. Значение для этого должно быть IP-адресом (IPv4). Используйте AAAA для адресов IPv6. CNAME — это псевдоним. Используйте типы NS и MX для подробных или частичных записей, которые расширяют информацию, представленную на вкладках NS Records и MX Records. Эти три типа разрешаются в существующую запись A. PTR для обратных зон. Это противоположно записи A, например:
Запустите YaST › DNS-сервер › Зоны DNS.
Если вы не добавили главную зону переадресации, добавьте ее и отредактируйте.
На вкладке «Записи» заполните соответствующий ключ и значение записи, затем добавьте запись, нажав «Добавить», и подтвердите, нажав «ОК». Если YaST жалуется на несуществующую запись для сервера имен, добавьте ее на вкладке NS Records.
Вернувшись в окно "Зоны DNS", добавьте обратную основную зону.
Редактируйте зону реверса, и на вкладке «Записи» вы увидите тип записи PTR: реверсивный перевод. Добавьте соответствующий ключ записи и значение , затем нажмите «Добавить» и подтвердите, нажав «ОК».
При необходимости добавьте запись сервера имен.
Совет: редактирование обратной зоны
После добавления прямой зоны вернитесь в главное меню и выберите обратную зону для редактирования. Там на вкладке «Основные» установите флажок «Автоматически создавать записи из» и выберите свою зону переадресации. Таким образом, все изменения в прямой зоне автоматически обновляются в обратной зоне.
В системе SUSE® Linux Enterprise Server сервер имен BIND ( Berkeley Internet Name Domain ) поставляется предварительно настроенным, поэтому его можно без проблем запустить сразу после установки. Обычно, если у вас уже есть подключение к Интернету и вы ввели 127.0.0.1 в качестве адреса сервера имен для localhost в /var/run/netconfig/resolv.conf , у вас уже есть работающее разрешение имен без необходимости знать DNS провайдера. BIND выполняет разрешение имен через корневой сервер имен, что значительно медленнее. Обычно DNS провайдера следует вводить вместе с его IP-адресом в файле конфигурации /etc/named.conf под серверами пересылки, чтобы обеспечить эффективное и безопасное разрешение имен. Если это работает до сих пор, сервер имен работает как чистый сервер имен только для кэширования. Только когда вы настраиваете свои собственные зоны, он становится полноценным DNS.Найдите простой пример, задокументированный в /usr/share/doc/packages/bind/config .
Совет: автоматическая адаптация информации сервера имен
В зависимости от типа подключения к Интернету или сетевого подключения информация сервера имен может автоматически адаптироваться к текущим условиям. Для этого установите для переменной NETCONFIG_DNS_POLICY в файле /etc/sysconfig/network/config значение auto .
Однако не устанавливайте официальный домен, пока он не будет назначен вам ответственным учреждением. Даже если у вас есть собственный домен и им управляет провайдер, вам лучше его не использовать, потому что в противном случае BIND не будет пересылать запросы для этого домена. Например, веб-сервер провайдера будет недоступен для этого домена.
Чтобы запустить сервер имен, введите команду systemctl start с именем root . Проверьте с помощью systemctl status named, успешно ли запущен named (так называется процесс сервера имен). Немедленно протестируйте сервер имен в локальной системе с помощью программ host или dig, которые должны вернуть localhost в качестве сервера по умолчанию с адресом 127.0.0.1. Если это не так, возможно, файл /var/run/netconfig/resolv.conf содержит неправильную запись сервера имен или файл не существует. Для первого теста введите host 127.0.0.1, который всегда должен работать. Если вы получили сообщение об ошибке, используйте имя systemctl status, чтобы увидеть, действительно ли сервер работает. Если сервер имен не запускается или ведет себя непредвиденно, проверьте выходные данные journalctl -e .
Чтобы использовать сервер имен провайдера (или тот, который уже работает в вашей сети) в качестве сервера пересылки, введите соответствующий IP-адрес или адреса в разделе параметров в разделе серверы пересылки. Адреса, включенные в Пример 32.1, «Параметры пересылки в named.conf», являются только примерами. Настройте эти записи по своему усмотрению.
За записью options следуют записи для зоны, localhost и 0.0.127.in-addr.arpa. Запись подсказки типа в разделе « . ” всегда должен присутствовать. Соответствующие файлы не нуждаются в модификации и должны работать как есть. Также убедитесь, что каждая запись закрыта знаком «; ” и что фигурные скобки находятся в правильных местах. После изменения файла конфигурации /etc/named.conf или файлов зоны скажите BIND перечитать их с помощью systemctl reload named . Достигните того же, остановив и перезапустив сервер имен с помощью перезапуска systemctl named . Остановите сервер в любое время, введя systemctl stop с именем .
Все настройки самого сервера имен BIND хранятся в файле /etc/named.conf. Однако данные зоны для обработки доменов (состоящие из имен хостов, IP-адресов и т. д.) хранятся в отдельных файлах в каталоге /var/lib/named. Подробности этого описаны позже.
Указывает каталог, в котором BIND может найти файлы, содержащие данные зоны. Обычно это /var/lib/named .
Указывает серверы имен (в основном провайдера), на которые следует пересылать DNS-запросы, если они не могут быть разрешены напрямую. Замените IP-ADDRESS на IP-адрес, например 192.168.1.116 .
Вызывает переадресацию DNS-запросов до того, как будет предпринята попытка разрешить их через корневые серверы имен. Вместо forward first может быть записано forward only, чтобы все запросы пересылались и ни один из них не отправлялся на корневые серверы имен. Это имеет смысл для конфигураций брандмауэра.
Сообщает BIND, какие сетевые интерфейсы и порт принимать клиентские запросы. порт 53 не нужно указывать явно, так как 53 является портом по умолчанию. Введите 127.0.0.1, чтобы разрешить запросы от локального хоста. Если вы полностью опустите эту запись, по умолчанию будут использоваться все интерфейсы.
прослушивание v6, порт 53 ;
Сообщает BIND, на каком порту он должен прослушивать клиентские запросы IPv6. Единственная альтернатива any — none. Что касается IPv6, сервер принимает только адреса с подстановочными знаками.
адрес источника запроса * порт 53;
Эта запись необходима, если брандмауэр блокирует исходящие DNS-запросы. Это указывает BIND отправлять внешние запросы с порта 53, а не с любого из старших портов выше 1024.
адрес источника запроса v6 * порт 53;
Сообщает BIND, какой порт использовать для запросов IPv6.
Определяет сети, из которых клиенты могут отправлять DNS-запросы. Замените NET информацией об адресе, например 192.168.2.0/24 . /24 в конце — это сокращенное выражение для сетевой маски (в данном случае 255.255.255.0).
Определяет, какие хосты могут запрашивать передачу зоны. В примере такие запросы полностью отвергаются с помощью ! * . Без этой записи передачу зоны можно запрашивать откуда угодно без ограничений.
При отсутствии этой записи BIND генерирует несколько строк статистической информации в час в системном журнале. Установите значение 0, чтобы полностью скрыть эту статистику, или установите интервал в минутах.
Эта опция определяет, через какие промежутки времени BIND очищает кэш.Это запускает запись в системном журнале каждый раз, когда это происходит. Спецификация времени в минутах. Значение по умолчанию — 60 минут.
BIND регулярно ищет в сетевых интерфейсах новые или несуществующие интерфейсы. Если для этого значения установлено значение 0, это не делается, и BIND прослушивает только те интерфейсы, которые были обнаружены при запуске. В противном случае интервал может быть задан в минутах. Значение по умолчанию — шестьдесят минут.
no предотвращает информирование других DNS-серверов об изменениях в данных зоны или перезапуске DNS-сервера.
Список доступных параметров см. на странице руководства man 5 named.conf .
Что, как и где происходит ведение журнала, можно подробно настроить в BIND. Обычно настроек по умолчанию должно быть достаточно. Пример 32.3, «Запись для отключения ведения журнала», показывает простейшую форму такой записи и полностью подавляет любое ведение журнала.
Читайте также: