10 примеров использования команды dig для просмотра параметров DNS (DNS Lookup) в Linux
Итак, что такое dig?
dig (англ. слово «копать», а формально — сокращение от «domain information groper») — утилита (DNS-клиент), предоставляющая пользователю интерфейс командной строки для обращения к системе DNS. Позволяет задавать различные типы запросов и запрашивать произвольно указываемые сервера. Является аналогом утилиты nslookup.
Утилита dig входит в стандартный комплект DNS сервера BIND.
1. Простой вывод команды dig (для понимания вывода, без доп.параметров )
Когда вы задаете имя домена в команде dig по-умолчанию вы получаете A-запись домена (ip-адрес сайта (домена) который мы запрашивали) как показано на листинге ниже
В примере можно увидеть A-записи домена ya.ru в разделе ANSWER SECTION
Давайте рассмотрим разделы данного вывода подробней:
— HEADER (заголовок): показывает версию dig, глобальные опции используемые с командой и другую дополнительную информацию
— QUESTION SECTION (секция запроса): Показывает наш запрос, то бишь мы запросили показать A-запись (команда dig без параметров) для домена ya.ru
— ANSWER SECTION (секция ответа): Показывает ответ полученный от DNS, в нашем случае показывает A-запись для ya.ru
Последняя секция это статистика по запросу (служебная информация) — время выполнения запроса, имя DNS-сервера который запрашивался, когда был создан запрос и размер сообщения
Так же можно выполнить опрос конкретного DNS-сервера:
Результат вывода дополняется еще двумя секциями:
AUTHORITY SECTION: Показывает имена DNS-серверов обработавших наш запрос
ADDITIONAL SECTION: Показывает ip-адреса этих DNS-серверов (из секции AUTHORITY SECTION)
2. Вывод только секции ANSWER SECTION
В большинстве случаев требуется только ip адрес домена, то бишь вывод секции «ANSWER SECTION»
Для этого существуют следующие ключи:
-+nocomments — отключает линию комментариев
-+noauthority — отключает секцию «AUTHORITY SECTION»
-+noadditional – отключает секцию «ADDITIONAL SECTION»
-+nostats – отключает секцию статистики
-+noanswer – выключает секцию ответа (ANSWER SECTION)
Можно сделать проще, существует ключ +noall, который выключает все секции. Таким образом мы используем ключ +noall и добавляем ключ +answer, уменьшая длину команды
3. Запрос MX-записи
Для запроса MX-записи домена мы используем одноименный аргумент командной строки (MX)
Этот же запрос можно выполнить с ключом -t (тип)
4. Запрос NS-записи
По аналогии с предыдущим пунктом, используем аргумент NS
Вы также можете использовать ключ -t для указания типа запроса
5. Просмотр всех типов DNS-записей
Для этого используется ключ ANY
Также допустим ключ -t
6. Краткий вывод команды dig
Допустим чтобы просмотреть только ip-адрес, без лишней информации, используем опцию +short
Вы также можете вывести информацию по любому виду информации с ключем +short
Пример:
7. Просмотр информации об обратной зоне домена (PTR)
Для просмотра обратной зоны необходимо использовать ключ -х
Для примера, мы хотим узнать имя домена по айпи-адресу 77.88.21.3
Для вывода полной информации убираем ключ +short
8. Использование конкретного DNS-сервера для выполнения запроса
Для использования конкретного DNS-сервераиспользуется запись вида — @dnsserver, где dnsserver это или имя или ip-адрес DNS-сервера
Данный пример мы рассмотрели в п.1
9. Объемный запрос (запрос информации сразу о нескольких доменах)
Для запроса информации о нескольких доменах возможно использование текстовых файлов с перечислением доменов.
Создадим файл names.txt с именами доменов:
Далее используем ключ -f для чтения из файла:
Также можно комбинировать тип DNS записи c опцией -f:
Также возможно перечисление доменов непосредственно в командной строке. Для примера узнаем MX-запись для домена ya.ru и NS-запись для домена google.ru:
10. Изменение параметров по умолчанию для команды dig
Например вы хотите, чтобы утилита dig по умолчанию выводила только секцию ответа (ANSWER SECTION).
Для этого необходимо внести в файл .digrc необходимые ключи, в нашем случае +noall +answer:
Таким образом мы рассмотрели мизерную часть этой замечательной утилиты, для тех, кто хочет большего, добро пожаловать в man dig 😉
Источник
Диагностика сетевого подключения (ping, arp, traceroute, dig, nslookup)
Одна из важнейших подсистем, отвечающая за связь любого сервера с внешним миром — сетевая. Через сетевые интерфейсы поступают запросы от удаленных систем и через эти же интерфейсы направляются ответы, что позволяет налаживать коммуникацию и предоставлять/получать сервисы. В связи с этим особенно важно уметь производить диагностику и мониторинг сети хотя бы на базовом уровне, чтобы выявлять проблемы и вносить корректировки в конфигурацию в случае необходимости.
Для операционных систем семейства Linux написано множество утилит, помогающих в диагностике и мониторинге. Познакомимся с наиболее часто используемыми из них.
Диагностика сетевой связности (ping, arp, traceroute)
В данной статье мы будем опираться на использование протокола IP версии 4. Согласно стандартам, определяющим работу этого протокола, каждое устройство, подключенное к сети, должно иметь как минимум IP-адрес и маску подсети — параметры, которые позволяют уникально идентифицировать устройство в пределах определенной сети. В такой конфигурации устройство может обмениваться сетевыми пакетами с другими устройствами в пределах той же самой логической сети. Если к этому набору параметров добавить адрес шлюза по умолчанию — наш сервер сможет связываться с хостами, находящимися за пределами локального адресного пространства.
В случае каких-либо сетевых проблем в первую очередь проверяем, не сбились ли настройки сетевого интерфейса. Например, команды ip addr или ifconfig выведут IP-адрес и маску сети:
В выводе команды виден перечень сетевых интерфейсов, распознанных операционной системой. Интерфейс lo — это псевдоинтерфейс (loopback). Он не используется в реальных взаимодействиях с удаленными хостами, а вот интерфейс с именем ens192 — то, что нам нужно (именование сетевых интерфейсов различается в разных ветках и версиях ОС Linux). IP-адрес и маска сети, назначенные этому интерфейсу, указаны в поле inet — /24 после адреса обозначают 24-битную маску 255.255.255.0.
Теперь проверим, указан ли шлюз по умолчанию. Команды ip route или route покажут имеющиеся маршруты:
В таблице маршрутизации мы видим, что имеется маршрут по умолчанию (обозначается либо ключевым словом default, либо адресом 0.0.0.0). Все пакеты, предназначенные для внешних сетей, должны направляться на указанный в маршруте адрес через обозначенный сетевой интерфейс.
Если в настройках интерфейса есть ошибки, их необходимо исправить — помогут в этом другие статьи, для ОС Ubuntu 18.04 или CentOS. Если же все верно — приступаем к диагностике с помощью утилиты ping. Данная команда отправляет специальные сетевые пакеты на удаленный IP-адрес (ICMP Request) и ожидает ответные пакеты (ICMP Reply). Таким образом можно проверить сетевую связность — маршрутизируются ли сетевые пакеты между IP-адресами отправителя и получателя.
Синтаксис команды ping IP/имя опции:
Скриншот №3. Синтаксис команды
В данном случае видим, что на оба сетевых пакета, отправленных на адрес нашего шлюза по умолчанию, получены ответы, потерь нет. Это значит, что на уровне локальной сети со связностью все в порядке. Помимо количества полученных/потерянных сетевых пакетов мы можем увидеть время, которое было затрачено на прохождение запроса и ответа – параметр RTT (Round Trip Time). Этот параметр может быть очень важен при диагностике проблем, связанных с нестабильностью связи и скоростью соединения.
Часто используемые параметры:
- ping –c количество — указать количество пакетов, которое будет отправлено адресату (по умолчанию пакеты отправляются до тех пор, пока пользователь не прервет выполнение команды. Этот режим можно использовать, чтобы проверить стабильность сетевого соединения. Если параметр RTT будет сильно изменяться в ходе проверки, значит где-то на протяжении маршрута есть проблема);
- ping –s количество — указать размер пакета в байтах. По умолчанию проверка производится малыми пакетами. Чтобы проверить работу сетевых устройств с пакетами большего размера, можно использовать этот параметр;
- ping –I интерфейс — указать сетевой интерфейс, с которого будет отправлен запрос (актуально при наличии нескольких сетевых интерфейсов и необходимости проверить прохождение пакетов по конкретному сетевому маршруту).
В случае, если при использовании команды ping пакеты от шлюза (или другого хоста, находящегося в одной локальной сети с сервером-отправителем) в ответ не приходят, стоит проверить сетевую связность на уровне Ethernet. Здесь для коммуникации между устройствами используются так называемые MAC-адреса сетевых интерфейсов. За разрешение Ethernet-адресов отвечает протокол ARP (Address Resolution Protocol) и с помощью одноименной утилиты мы можем проверить корректность работы на этом уровне. Запустим команду arp –n и проверим результат:
Команда выведет список IP-адресов (так как был использован аргумент –n), и соответствующие им MAC-адреса хостов, находящиеся в одной сети с нашим сервером. Если в этом списке есть IP, который мы пытаемся пинговать, и соответствующий ему MAC, значит сеть работает и, возможно, ICMP-пакеты, которые использует команда ping, просто блокируются файрволом (либо со стороны отправителя, либо со стороны получателя). Подробнее об управлении правилами файрвола рассказано здесь и здесь.
Часто используемые параметры:
- arp –n — вывод содержимого локального arp-кэша в числовом формате. Без этой опции будет предпринята попытка определить символические имена хостов;
- arp –d адрес — удаление указанного адреса из кэша. Это может быть полезно для проверки корректности разрешения адреса. Чтобы убедиться, что в настоящий момент времени адрес разрешается корректно, можно удалить его из кэша и снова запустить ping. Если все работает правильно, адрес снова появится в кэше.
Если все предыдущие шаги завершены корректно, проверяем работу маршрутизатора — запускаем ping до сервера за пределами нашей сети, например, 8.8.8.8 (DNS-сервис от Google). Если все работает корректно, получаем результат:
В случае проблем на этом шаге, нам может помочь утилита traceroute, которая используя ту же логику запросов и ответов помогает увидеть маршрут, по которому движутся сетевые пакеты. Запускаем traceroute 8.8.8.8 –n и изучаем вывод программы:
Первым маршрутизатором на пути пакета должен быть наш локальный шлюз по умолчанию. Если дальше него пакет не уходит, возможно проблема в конфигурации маршрутизатора и нужно разбираться с ним. Если пакеты теряются на дальнейших шагах, возможно, есть проблема в промежуточной сети. А, возможно, промежуточные маршрутизаторы не отсылают ответные пакеты. В этом случае можно переключиться на использование другого протокола в traceroute.
Часто используемые опции:
- traceroute –n — вывод результата в числовом формате вместо символических имен промежуточных узлов;
- traceroute –I — использование ICMP-протокола при отслеживании маршрута. По умолчанию используются UDP-датаграммы;
- traceroute –s адрес— указать адрес источника для исходящего сетевого пакета;
- traceroute –i интерфейс— указать сетевой интерфейс, с которого будут отправляться пакеты.
Диагностика разрешения имен (nslookup, dig)
Разобравшись с сетевой связностью и маршрутизацией приходим к следующему этапу — разрешение доменных имен. В большинстве случаев в работе с удаленными сервисами мы не используем IP-адреса, а указываем доменные имена удаленных ресурсов. За перевод символических имен в IP-адреса отвечает служба DNS — это сеть серверов, которые содержат актуальную информацию о соответствии имен и IP в пределах доверенных им доменных зон.
Самый простой способ проверить работает ли разрешение имен — запустить утилиту ping с указанием доменного имени вместо IP-адреса (например, ping ya.ru). Если ответные пакеты от удаленного сервера приходят, значит все работает как надо. В противном случае нужно проверить прописан ли DNS-сервер в сетевых настройках и удается ли получить от него ответ.
Способы выяснения какой DNS-сервер использует наш сервер различаются в зависимости от используемой версии и дистрибутива ОС Linux. Например, если ОС используется Network Manager для управления сетевыми интерфейсами (CentOS, RedHat и др.), может помочь вывод команды nmcli:
В настройках сетевого интерфейса, в разделе DNS configuration, мы увидим IP-адрес сервера. В Ubuntu 18.04 и выше, использующих Netplan, используем команду systemd-resolve —status:
Используемый сервер также будет указан в настройках интерфейса, в разделе DNS Servers. В более старых версиях Ubuntu потребуется проверить содержимое файлов /etc/resolve.conf и /etc/network/interfaces. Если сервер не указан, воспользуйтесь статьей для ОС Ubuntu 18.04 или CentOS, чтобы скорректировать настройки.
Проверить работу сервиса разрешения имен нам помогут утилиты nslookup или dig. Функционально они почти идентичны: G-вывод утилиты dig содержит больше диагностической информации и гибко регулируется, но это далеко не всегда нужно. Поэтому используйте ту утилиту, которая удобна в конкретной ситуации. Если эти команды недоступны, потребуется доставить пакеты на CentOS/RedHat:
yum install bind-utils
sudo apt install dnsutils
После успешной установки сделаем тестовые запросы:
В разделе Answer Section видим ответ от DNS сервера — IP-адрес для A-записи с доменным именем ya.ru. Разрешение имени работает корректно:
Аналогичный запрос утилитой nslookup выдает более компактный вывод, но вся нужная сейчас информация в нем присутствует.
Что же делать, если в ответе отсутствует IP-адрес? Возможно, DNS-сервер недоступен. Для проверки можно отправить тестовый запрос на другой DNS-сервер. Обе утилиты позволяют эти сделать. Направим тестовый запрос на DNS-сервер Google:
Скриншот №11. Отправка тестового запроса 1
nslookup ya.ru 8.8.8.8
Скриншот №12. Отправка тестового запроса 2
Если имена разрешаются публичным DNS-сервером корректно, а установленным по умолчанию в ОС нет, вероятно, есть проблема в работе этого DNS-сервера. Временным решением данной проблемы может быть использование публичного DNS-сервера в качестве сервера для разрешения имен в операционной системе. В том случае, если разрешение имен не работает ни через локальный, ни через публичный DNS сервер — стоит проверить не блокируют ли правила файрвола отправку на удаленный порт 53 TCP/UDP пакетов (именно на этом порту DNS-серверы принимают запросы).
Часто используемые параметры:
- nslookup имя сервер — разрешить доменное имя, используя альтернативый сервер;
- nslookup –type=тип имя — получить запись указанного типа для доменного имени (например, nslookup -type=mx ya.ru – получить MX-записи для домена ya.ru);
- dig @сервер имя — разрешить доменное имя, используя альтернативый сервер;
- dig имя тип — получить запись указанного типа для доменного имени (например, dig ya.ru mx — получить MX-записи для домена ya.ru).
Как обычно, полный набор опций и параметров для указанных утилит можно найти во встроенной справке операционной системы, используя команду man.
Источник
