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

Обновлено: 21.11.2024

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

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

Из-за критической роли, которую DNS играет в функционировании сетевых служб, важно, чтобы администраторы Linux могли быстро решать возникающие проблемы с DNS, чтобы свести к минимуму перебои в обслуживании. Ключом к точному и эффективному поиску и устранению неполадок DNS является возможность точно определить, какая из многочисленных точек во множестве скрытых взаимодействий клиент-сервер ответственна за наблюдаемое неожиданное поведение. Это требует использования надлежащих инструментов и четкого понимания диагностических данных, которые они предоставляют. Domain Internet Groper (dig) — хороший инструмент для исследования проблем с DNS благодаря подробным диагностическим выводам.

Методы разрешения имен

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

В системах Linux сначала выполняется попытка разрешения имен в файле хостов /etc/hosts по умолчанию в соответствии с порядком, указанным в /etc/nsswitch.conf. Поэтому, приступая к поиску и устранению неполадок с разрешением имен, не спешите полагать, что проблема связана с DNS. Прежде всего, начните с определения используемого механизма разрешения имен, а не просто начните с DNS. Команда getent из пакета glibc-common, а также команда gethostip из пакета syslinux могут использоваться для разрешения имен, отражая процесс, используемый большинством приложений, в соответствии с порядком разрешения имен хостов, как указано в /etc. /nsswitch.conf.

Если результат getent или gethostip отличается от результата, выдаваемого dig, то это явный признак того, что за непредвиденный результат разрешения имен виновато что-то помимо DNS. Обратитесь к /etc/nsswitch.conf, чтобы определить, какие другие механизмы разрешения имен используются перед DNS.

Сетевое подключение клиент-сервер

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

Если при использовании dig для устранения неполадок с DNS не получен ответ от DNS-сервера, это явный признак того, что причина кроется в сетевом подключении клиент-сервер к DNS-серверу.

Возможной причиной является невозможность доступа к DNS-серверу из-за неправильного IP-адреса (адресов) DNS-сервера в конфигурации DNS системы. Это может быть файл /etc/resolv.conf, если система действует как DNS-клиент, или пункт прямой зоны файла /etc/unbound/unbound.conf, если система настроена как несвязанный кэширующий сервер имен. /p>

Еще одна возможная причина – правила брандмауэра в клиентской или серверной системе, блокирующие трафик DNS через порт 53. Хотя DNS в основном использует протокол UDP, важно в случае DNS-серверов, поддерживающих механизм расширения для DNS (EDNS), преобразователи будут возвращаться к использованию TCP для повторной попытки запроса. Следовательно, правильная конфигурация DNS должна разрешать DNS-трафик через порт 53 как для UDP, так и для TCP. Разрешение трафика через порт 53 только для UDP приведет к ошибке усечения, когда распознаватель обнаружит ответ, превышающий то, что он может обработать по UDP.

Параметры tcp или vc в dig полезны для устранения неполадок, могут ли DNS-запросы быть успешными с TCP. Эти параметры заставляют dig использовать TCP, а не поведение по умолчанию, при котором сначала используется UDP, а затем возвращается к TCP только тогда, когда этого требует размер ответа.

При решении проблем с DNS на сетевом уровне dig предоставляет очень разреженные выходные данные, поэтому часто полезно также использовать анализатор сетевых пакетов, например tcpdump, чтобы определить, что происходит за кулисами на сетевом уровне.Используя tcpdump, администратор может определить информацию, которую нельзя получить с помощью одного только dig, например, IP-адрес получателя DNS-запроса, если пакеты запроса покидают клиент, если пакеты запроса достигают сервера, если пакеты ответа покидают сервер, если пакеты ответа связаться с клиентом и т. д.

Коды ответов DNS

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

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

Коды возврата DNS

КОД	ЗНАЧЕНИЕ
SERVFAIL	Сервер имен обнаружил проблему при обработке запроса.
NXDOMAIN	Запрашиваемое имя не существует в зоне.
ОТКАЗАНО	Сервер имен отклонил DNS-запрос клиента из-за ограничений политики.

ОШИБКА ОБСЛУЖИВАНИЯ

Частой причиной состояния SERVFAIL является сбой связи DNS-сервера с серверами имен, полномочными для запрашиваемого имени. Это может быть связано с тем, что авторитетные серверы имен недоступны. Это также может быть проблема на сетевом уровне, мешающая взаимодействию клиент-сервер между DNS-сервером и авторитетными серверами имен, например проблемы с сетевой маршрутизацией или правила брандмауэра на любом узле сетевого пути.

Чтобы определить, почему сервер имен генерирует статус SERVFAIL при выполнении рекурсии от имени запроса клиента, администратору сервера имен необходимо определить, связь с каким сервером имен вызывает сбой. Параметр dig + trace полезен в этом сценарии, чтобы увидеть результаты повторяющихся запросов сервера имен, начиная с корневых серверов имен

NXДОМЕН

Состояние NXDOMAIN указывает на то, что записи, связанные с запрошенным именем, не найдены. Если это не ожидаемый результат и запрос направлен на сервер, который не является авторитетным для имени, то кеш сервера может содержать отрицательный кеш для имени. Пользователь может либо дождаться истечения срока действия отрицательного кеша этого имени на сервере, либо отправить запрос администратору сервера на удаление этого имени из кеша сервера. Как только имя будет удалено из кеша, сервер отправит запрос полномочному серверу имен, чтобы получить текущие записи ресурсов для имени.

Еще одна ситуация, когда статус NXDOMAIN может быть неожиданно обнаружен, — это запрос записи CNAME, содержащей потерянный CNAME. В записи CNAME имя в правой части записи, каноническое имя, должно указывать на имя, которое содержит записи A или AAAA. Если эти связанные записи A или AAAA не существуют или позже удалены, то каноническое имя в записи CNAME потеряно. Когда это произойдет, запросы имени владельца в записи CNAME больше не будут разрешаться и приведут к коду возврата NXDOMAIN.

ОТКАЗАНО

Статус REFUSED указывает на то, что DNS-сервер имеет ограничение политики, которое не позволяет ему выполнить запрос клиента. Ограничения политик часто реализуются на DNS-серверах, чтобы ограничить, какие клиенты могут делать рекурсивные запросы и запросы на передачу зоны. Некоторыми распространенными причинами неожиданного кода возврата REFUSED являются клиенты, настроенные на запросы к неправильным DNS-серверам, или неправильная конфигурация DNS-сервера, приводящая к отклонению действительных клиентских запросов.

ДРУГИЕ РАСПРОСТРАНЕННЫЕ ПРОБЛЕМЫ DNS

Устаревшие кэшированные данные

Код возврата DNS NOERROR означает, что при разрешении запроса не было обнаружено ошибок. Однако это не гарантирует отсутствие проблем с DNS. Бывают ситуации, когда записи DNS в ответе DNS могут не соответствовать ожидаемому результату. Наиболее распространенной причиной неправильного ответа является то, что ответ получен из кэшированных данных, которые больше не являются актуальными.

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

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

Ответы на несуществующие записи

Если запись была удалена из зоны, а при запросе записи по-прежнему поступает ответ, сначала убедитесь, что ответы на запросы не получены из кэшированных данных. Если ответ достоверный, что подтверждается наличием флага aa в выходных данных команды dig, возможной причиной является наличие записи с подстановочным знаком (*) в зоне.

Ошибки имени, отличного от FQDN

Зацикливание записей CNAME

Хотя это технически возможно, следует избегать записей CNAME, указывающих на записи CNAME, чтобы снизить эффективность поиска в DNS. Другая причина, по которой это нежелательно, — возможность создания неразрешимых циклов CNAME, таких как:

Хотя запись CNAME с потерянным CNAME приведет к статусу NXDOMAIN, зацикленные записи CNAME вернутся как NOERROR.

Отсутствуют записи PTR

Многие сетевые службы используют DNS для обратного просмотра входящих подключений от клиентов. Отсутствие записей PTR в DNS может привести к проблемам, характер которых зависит от службы. SSHD по умолчанию будет выполнять обратный поиск IP-адресов подключающихся клиентов. Отсутствие записей PTR приведет к задержкам в установлении этих соединений.

Многие агенты передачи сообщений используют обратный поиск в DNS для подключения IP-адресов клиентов в качестве защиты от вредоносных почтовых клиентов. На самом деле, многие MTA настроены на отклонение клиентских подключений для IP-адресов, которые не могут быть разрешены с помощью запроса PTR в DNS. Таким образом, администраторы, поддерживающие сетевые службы, должны убедиться, что они понимают требования, предъявляемые этими службами не только к прямому, но и к обратному поиску DNS.

Циклический DNS

Имя может иметь несколько записей A или AAAA в DNS. Это известно как DNS с циклическим перебором и часто используется как простой, недорогой механизм балансировки нагрузки для распределения нагрузки сетевых ресурсов между несколькими хостами. Когда DNS-клиент запрашивает имя, содержащее несколько записей A или AAAA, все записи возвращаются в виде набора. Однако порядок, в котором записи возвращаются в наборе, изменяется для каждого запроса. Поскольку клиенты обычно используют первый адрес в наборе, изменение порядка записей в каждом ответе фактически приводит к распределению запросов сетевых служб по нескольким IP-адресам в этих циклических записях DNS.

Хотя DNS с циклическим перебором является допустимой технической конфигурацией, бывают случаи, когда эта конфигурация создается непреднамеренно. Когда запрос на изменение IP-адреса записи A ошибочно реализуется как добавление записи ресурса, а не модификация записи ресурса, создается DNS с циклическим перебором. Если сетевые ресурсы на старом IP-адресе выведены из эксплуатации, эффект распределения нагрузки циклического DNS приведет к сбоям в обслуживании примерно для половины клиентов

В этой первой части двухчастного введения в поиск и устранение неполадок 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. ]

Руководства, учебные пособия, обзоры и новости для системных администраторов.

Как устранить проблемы с DNS-клиентом в Linux

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

Существует несколько потенциальных точек отказа в процессе поиска DNS, например, в системе, выполняющей поиск, в кэше DNS или на внешнем DNS-сервере. Здесь мы расскажем, как их проверить и выполнить различные тесты, чтобы определить, в чем именно заключается проблема.

Подготовка к сертификации RHCE? Посмотрите наш видеокурс RHCE на сайте Udemy со скидкой 20 % при использовании кода ROOTUSER.

Конфигурация локального сервера

Во-первых, важно понять раздел hosts в файле /etc/nsswitch.conf. Конфигурация хостов по умолчанию показана ниже.

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

Поскольку файлы являются первыми, они будут проверяться в первую очередь, это ссылается на локальный файл /etc/hosts, который содержит статическое имя хоста и сопоставление IP-адресов. Этот файл имеет приоритет над любым разрешением DNS, любые изменения в файле будут помещены прямо в кеш DNS этого локального сервера. Ниже приведен пример строки конфигурации из /etc/hosts

Если в файле hosts нет записи, DNS будет использоваться следующим образом в соответствии с /etc/nsswitch.conf. Серверы, используемые для разрешения DNS, будут указаны в файле /etc/resolv.conf, ниже приведен пример конфигурации этого файла.

В этом случае все DNS-запросы нашей системы будут направляться на DNS-сервер по адресу 192.168.0.1. Другие вторичные и третичные DNS-серверы также могут быть указаны здесь как резервные.

Тестирование DNS

Для успешного разрешения DNS на 192.168.0.1 DNS-сервер с адресом 192.168.0.1 должен будет принимать TCP- и UDP-трафик через порт 53 от нашего сервера. Сканер портов, такой как инструмент nmap, можно использовать для проверки доступности DNS-сервера на порту 53, как показано ниже.

Примечание. Чтобы установить nmap, запустите команду yum install nmap -y.

Стоит отметить, что сканирование UDP с помощью nmap ненадежно из-за природы UDP, поэтому состояние указано как открытое или отфильтрованное. Мы можем ясно видеть, что TCP 53 определенно открыт и отвечает, что является хорошим признаком, если состояние было сообщено как отфильтрованное, следующее, что нужно исследовать, это подключение к DNS-серверу, в частности, любой брандмауэр, работающий на DNS-сервере, потребуется настроить так, чтобы разрешить входящий трафик портов TCP и UDP 53.

Примечание. Dig входит в состав пакета bind-utils, который можно установить с помощью команды «yum install bind-utils».

Статус запроса на раскопки правильно возвратил IP-адрес с нашего локального DNS-сервера 192.168.0.1, а статус был NOERROR, который возвращается, когда запрос успешно разрешен. Коды ответов могут помочь вам в процессе устранения неполадок, полный их список см. в RFC 5395.

Проверка авторитетного DNS-сервера

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

Чтобы получить серверы имен домена, мы можем использовать команду whois, как показано ниже. Это часть пакета whois, и его можно установить с помощью команды «yum install whois -y», если она еще не установлена.

Хотя возвращаемая запись A в этом случае одинакова, обратите внимание, что в этом ответе dig у нас теперь есть флаг «aa» в заголовке, который означает, что это авторитетный ответ, а не кешированный ответ. Если мы снова запустим ту же команду dig, значение срока жизни 300 секунд, которое было возвращено в разделе ответа, будет постоянно указывать, что время жизни составляет 300 секунд, поскольку ответ является авторитетным.

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

Обзор

Поскольку DNS является важной службой, возможность устранения неполадок является полезным навыком. По умолчанию Linux сначала проверяет свой локальный файл хоста /etc/hosts, прежде чем запрашивать DNS-серверы, определенные в /etc/resolv.conf. Важно убедиться, что в этом файле указаны правильные DNS-серверы и что вы можете подключиться к ним через TCP/UDP-порт 53. DNS-запросы можно проверить с помощью команды dig либо на локальном DNS-сервере, либо на авторитетном сервер имен для домена, который предоставит актуальный результат без кэширования.

Этот пост является частью нашей серии руководств по подготовке к экзамену Red Hat Certified Engineer (RHCE). Для получения дополнительных сообщений и информации, связанных с RHCE, ознакомьтесь с нашим полным учебным пособием по RHCE.

Устранение неполадок с DNS

DNS (система доменных имен) хранит информацию, связанную с доменными именами, в виде распределенной базы данных. Служба клиент-сервер преобразует доменные имена в IP-адреса и наоборот.

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

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

Стабильное подключение к Интернету.
Доступ к командной строке/терминалу.
Учетная запись пользователя с правами администратора/sudo.

Примечание. Следуйте нашему руководству, чтобы настроить DNS-сервер имен в Ubuntu.

Устранение неполадок DNS

Устранение неполадок DNS следует логическим шагам, начиная с простого устранения неполадок сети и заканчивая более глубоким анализом. Сетевые службы часто сообщают о проблемах с DNS по причинам, не требующим подробного устранения неполадок DNS.

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

При использовании проводного подключения убедитесь, что все подключено правильно. В беспроводных сетях проверьте, включен ли Wi-Fi и подключен ли он. Проверьте маршрутизатор, все ли кабели исправны. Попробуйте переключить порты для кабелей Ethernet и проверить подключение.

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

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

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

Вывод команды помогает определить причину проблемы с подключением:

<р>1. Если ping не дает ответа, проблема, скорее всего, на стороне сервера.

<р>2. Частой причиной ошибки в ответе является плохо настроенный DNS-сервер или ограничения брандмауэра. Узнайте, как устранить ошибку "Временный сбой при разрешении имен".

<р>3. Если на выходе отображается ответ, проблема, скорее всего, связана с DNS.

Приведенный ниже исчерпывающий список содержит ценные советы по устранению неполадок с DNS.

Проверьте настройки TCP/IP

Распространенной проблемой являются неправильно настроенные адреса DNS-серверов. Сбросьте настройки и проверьте, вернулась ли связь в нормальное состояние. Шаги различаются в зависимости от используемой ОС.

Для Windows:

<р>1. Найдите Статус сети в меню "Пуск" и откройте инструмент.

<р>2. Выберите «Свойства» в разделе сведений о сетевом подключении.

<р>3. Нажмите кнопку «Изменить», чтобы изменить настройки IP.

<р>4. Если назначение IP-адреса установлено вручную, дважды проверьте IP-адрес, предпочтительный и альтернативный DNS-адреса.Измените назначение IP-адреса, выбрав Автоматически (DHCP) в раскрывающемся меню, чтобы вернуться к нормальному состоянию.

<р>5. По завершении сохраните настройки.

Для Linux:

<р>1. Нажмите на значок подключения в правом верхнем углу.

<р>2. Откройте меню и выберите Настройки проводной сети.

<р>3. Щелкните значок шестеренки на панели подключения, чтобы открыть настройки.

<р>4. Перейдите на вкладку IPv4 в меню настроек.

<р>5. Если он назначен вручную, дважды проверьте список Адрес и IP-адрес DNS. Выберите параметр «Автоматически (DHCP)» и измените переключатель DNS на «Автоматически», чтобы восстановить нормальное состояние.

По завершении примените настройки и закройте окно. Наконец, проверьте соединение, чтобы убедиться, что все работает правильно.

Очистить кеш DNS

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

Очистка кеша DNS — это хорошая мера безопасности. Следуйте нашему руководству для получения подробных инструкций для конкретных ОС: Как сбросить кэш DNS в macOS, Windows и Linux.

Освобождение и обновление IP-адреса DHCP-сервера

Освобождение и обновление IP-адреса помогает разрешить конфликт IP и старую информацию DNS путем обновления кэшированной информации. Самый простой способ выполнить выпуск и обновление — через командную строку/терминал.

Внимание! При сбросе IP-адреса компьютер отключается от Интернета.

Чтобы обновить IP-адрес в Windows с помощью командной строки:

<р>1. Выполните следующие команды, чтобы освободить текущий IP-адрес и обновить информацию:

<р>2. Проверьте новую информацию с помощью:

Чтобы принудительно обновить IP в Linux через терминал:

<р>1. Откройте терминал и освободите текущий IP-адрес с помощью следующей команды:

Терминал выводит подтверждающее сообщение, и соединение закрывается.

<р>2. Запустите dhclient без каких-либо параметров для обновления IP:

Перейти на общедоступные DNS-серверы

Адрес Google 8.8.8.8 в качестве основного и 8.8.4.4 в качестве дополнительного.
Адрес Cloudflare 1.1.1.1 в качестве основного и 1.0.0.1 в качестве дополнительного.

Адреса общедоступных доменов, как правило, надежны и доступны бесплатно. Однако используйте это только как временное решение.

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

Использовать копание

Команда dig (информация о домене) предоставляет информацию о DNS и помогает в диагностике проблем. Необработанные выходные данные утилиты делают ее предпочтительным методом устранения проблем с DNS.

По умолчанию эта программа доступна для macOS и Linux, а в Windows ее можно установить бесплатно.

Чтобы получить информацию о копании для домена, выполните в терминале следующую команду:

Примечание. При использовании IP-адреса выполняется обратный поиск DNS.

По умолчанию dig ищет запись A для домена и показывает, на какой IP-адрес указывает домен при разрешении имени.

Инструмент раскопок предлагает множество дополнительных параметров для комплексного поиска. Например, добавьте тег +trace, чтобы увидеть полный путь к месту назначения:

Параметр +trace помогает точно определять пропуски трафика на пути к месту назначения.

Чтобы проверить делегированные серверы имен, используйте параметр ns:

Используйте параметр ns для выявления и устранения проблем с делегированием.

Использовать nslookup

Команда nslookup предоставляет функции для проверки различных записей DNS и серверов. Этот инструмент по умолчанию доступен в операционных системах macOS, Linux и Windows, и это был первый инструмент для запросов к DNS.

Чтобы получить информацию nslookup для домена, используйте следующую команду в командной строке/терминале:

В результате выводится адрес DNS-сервера и ответ A-записи. Команда nslookup предпочтительнее для Windows из-за ее доступности.

Использовать хост

Утилита host – это простая программа для поиска в DNS. Команда доступна для систем macOS и Linux.

Основной синтаксис для хоста:

Команда host отлично подходит для быстрой проверки существования доменного имени и его разрешения в адрес. Типичный пример использования хоста — скрипты bash.

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

Вывод показывает дополнительную информацию в разделе ответов, такую как NS, SOA, MX и другие доступные записи.

Использовать traceroute или tracert

Инструменты traceroute и tracert помогают отслеживать маршрут от источника к месту назначения. При устранении неполадок DNS команды помогают определить, где в сети остановились пакеты. Команда traceroute доступна в macOS и Linux, а ее эквивалент в Windows — tracert .

Примечание. Установите инструмент traceroute с помощью диспетчера пакетов apt:

В качестве легкодоступной и более простой альтернативы используйте tracepath.

Чтобы сопоставить сеть, выполните в терминале следующую команду:

Если вы используете компьютер с Windows, запустите:

Для получения дополнительной информации о команде traceroute / tracert и о том, как читать выходные данные, ознакомьтесь с нашим подробным руководством по запуску Traceroute в Linux, Windows и macOS.

Свяжитесь со своим интернет-провайдером

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

В конце этого руководства у вас должно быть несколько инструментов и приемов, которые помогут вам решить проблемы с DNS. Если вы хотите настроить свой DNS-сервер дома, чтобы ускорить подключение, попробуйте следовать нашему руководству по Raspberry Pi «Как настроить Raspberry Pi в качестве DNS-сервера».

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