Разное

Посмотреть записи домена – Проверка DNS-записей домена — утилита dig

17.04.2018

Обеспечение автоматизации проверки владения доменом на основе DNS-записей в протоколе ACME [перевод]

От переводчика: Это перевод статьи от EFF
A Technical Deep Dive: Securing the Automation of ACME DNS Challenge Validation.
Автор оригинальной статьи: Joona Hoikkala.
Дата оригинальной публикации: 23 февраля 2018

Ранее в этом месяце, Let’s Encrypt (бесплатный, автоматизированный, открытый центр сертификации, который EFF помог запустить два года назад) преодолел важный рубеж: выдачу более 50 миллионов активных сертификатов. И это число будет продолжать расти, потому что через несколько недель Let’s Encrypt также начнет выдавать wildcard-сертификаты, о которых просили многие системные администраторы.

Что такое wildcard-сертификат?


Чтобы проверить сертификат HTTPS, браузер пользователя проверяет, действительно ли доменное имя веб-сайта указано в сертификате. Например, сертификат от www.eff.org должен фактически включать в себя www.eff.org как действительный домен для этого сертификата. Сертификаты также могут содержать несколько доменов (например, www.eff.org, ssd.eff.org, sec.eff.org и т.д.), если владелец просто хочет использовать один сертификат для всех своих доменов.

Wildcard-сертификат — это сертификат, который гласит: «Я действителен для всех поддоменов в этом домене», а не явно перечисляя их все. (В сертификате это указывается с помощью символа подстановки, обозначенного звездочкой. Поэтому, если Вы сейчас проверите сертификат для eff.org, он скажет, что он действителен для *.eff.org.) Таким образом, системный администратор может получить сертификат для всего своего домена и использовать его в новых поддоменах, о которых он даже не думал, когда получал сертификат.

Для выдачи wildcard-сертификатов Let’s Encrypt будет требовать от пользователей подтверждения своего контроля над доменом, используя проверку(challenge) на основе DNS, системы доменных имен, которая переводит доменные имена, такие как www.eff.org, в IP-адреса, такие как 69.50.232.54. С точки зрения центра сертификации, такого как Let’s Encrypt, нет лучшего способа доказать, что Вы управляете доменом, чем путем изменения его записей DNS, поскольку управление доменом является одной из основ DNS.

Однако, одна из ключевых идей Let’s Encrypt заключается в том, что получение сертификата должно быть автоматическим процессом. Но, чтобы автоматизировать его, программное обеспечение, запрашивающее сертификат, также должно будет иметь возможность изменять записи DNS для этого домена. В целях реализации этой возможности программное обеспечение также должно иметь доступ к учетным данным для службы DNS (например, логин и пароль или криптографический токен), а эти учетные данные должны храниться там, где происходит автоматизированное получение сертификата.

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

Как работает проверка владения доменом?


На высоком уровне проверка владения доменом работает, как и все остальные автоматические проверки, которые являются частью протокола ACME, — протокола, который может использовать центр сертификации (CA), например Let’s Encrypt, и клиентское программное обеспечение, например Certbot, для обмена информацией о том, какой сертификат запрашивает сервер, и как сервер должен подтвердить право собственности на соответствующее доменное имя.

Во время проверки владения доменом пользователь запрашивает сертификат из CA с помощью клиентского программного обеспечения ACME, такого как Certbot, который поддерживает данный тип проверки. Когда клиент запрашивает сертификат, CA запрашивает у клиента подтверждение права собственности на домен, путем добавления конкретной TXT-записи в свою зону DNS. Более подробно: CA отправляет уникальный случайный токен ACME-клиенту, и тот, кто имеет контроль над доменом, должен поместить этот токен как TXT-запись в свою зону DNS, в предопределенный поддомен с именем «_acme-challenge» того домена, контроль над которым пытается доказать пользователь.

Например, если Вы пытаетесь проверить домен для *.eff.org, поддомен проверки будет «_acme-challenge.eff.org». Когда значение токена добавляется в зону DNS, клиент сообщает CA продолжить проверку владения, после чего CA будет выполнять DNS-запрос к авторитетным серверам для домена. Если авторитетные DNS-серверы ответят DNS-записью, содержащей правильный токен проверки владения, право собственности на домен будет доказано, и процесс выдачи сертификата может быть продолжен.

DNS служба контролирует цифровую идентичность


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

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

Отдельные и ограниченные привилегии


Строго говоря, для того, чтобы ACME-клиент делал обновления в автоматическом режиме, этот клиент должен иметь доступ только к учетным данным, которые могут обновлять TXT-записи для поддоменов «_acme-challenge». К сожалению, большинство программных продуктов DNS и поставщиков услуг DNS не предлагают подробные средства контроля доступа, которые позволяют ограничить эти привилегии, или просто не предоставляют API для автоматизации этого за пределами основных обновлений или транзакций DNS-зоны. Это оставляет возможные методы автоматизации непригодными или небезопасными.

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

Способы смягчения проблемы


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

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

Разрешить обновления только для TXT-записей


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

В случае компрометации этот метод ограничивает последствия для злоумышленника способностью выдавать сертификаты для всех доменов в зоне DNS (поскольку они могут использовать учетные данные DNS для получения собственных сертификатов), а также прерывание доставки почты. Воздействие на доставку почты происходит из TXT-записей, специфичных для почты, а именно SPF, DKIM и его расширения ADSP и DMARC. Их компрометация также облегчит доставку фишинговых писем, выдающих себя за отправителя из скомпрометированного домена.

Использовать «throwaway» домен подтверждения


Второй способ — вручную создать CNAME-записи для поддомена «_acme-challenge» и указать ими на домен проверки, который будет находиться в зоне, контролируемой другим набором учетных данных.

Например, если Вы хотите получить сертификат для покрытия «yourdomain.tld» и «www.yourdomain.tld», вам придется создать две CNAME-записи — «_ acme-challenge.yourdomain.tld» и «_acme-challenge.www.yourdomain.tld» — а также указать ими на внешний домен для проверки. Домен, используемый для проверки владения, должен быть во внешней зоне DNS или в поддиапазонной зоне DNS, которая имеет свой собственный набор учетных данных для управления. (DNS-зона субделегата определяется с помощью NS-записей и фактически делегирует полный контроль над частью зоны внешнему источнику.)

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

Ограниченный доступ к зоне DNS


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

К сожалению, на момент публикации был найден единственный поставщик, который дает данные привилегии — это Microsoft Azure DNS. У Dyn предположительно также есть гранулированные привилегии, но мы не смогли найти более низкий уровень привилегий в их сервисе помимо «Обновление записей», которые все еще оставляют зону полностью уязвимой.

Route53 и, возможно, другие позволяют своим пользователям создавать зону субделегата, новые учетные данные пользователя, указывать NS-записи в новую зону и указывать поддомены проверки _acme-challenge для них с использованием CNAME-записей. Нужно много работы для того, чтобы корректно сделать распределение привелегий, используя этот метод, так как нужно пройти все эти шаги для каждого домена, для которого необходимо использовать проверку владения.

Использовать ACME-DNS


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

Последний метод — это часть программного обеспечения под названием ACME-DNS, написанная для борьбы именно с обсуждаемой проблемой, и она может полностью устранить её. Единственный недостаток заключается в том, что этот метод добавляет еще один компонент в вашу инфраструктуру, который надо поддерживать, а также требует открыть DNS-порт (53) для общего доступа в интернет.

ACME-DNS действует как простой DNS-сервер с ограниченным HTTP API. Сам API позволяет только обновлять TXT-записи автоматически генерируемых случайных поддоменов. В нём нет методов для запроса утерянных учетных данных, обновления или добавления других записей. Он предоставляет две конечные точки:

  • /register — эта конечная точка создает новый поддомен для использования, сопровождаемый именем пользователя и паролем. В качестве необязательного параметра конечная точка регистра принимает список диапазонов CIDR для «белых» обновлений.
  • /update — эта конечная точка используется для обновления текущего токена проверки владения доменом на сервере.

Чтобы использовать ACME-DNS, вам сначала нужно создать для него A/AAAA-записи, а затем указать к нему NS-записи для создания узла делегирования. После этого Вы просто создаете новый набор учетных данных через конечную точку /register и указываете CNAME-запись из поддомена подтверждения проверки «_acme-challenge» в исходной зоне к вновь созданному поддомену.

Единственные учетные данные, сохраненные локально, будут для ACME-DNS, и они хороши только для обновления точных TXT-записей для поддоменов проверки для доменов в поле. Это эффективно ограничивает влияние возможной компрометации для злоумышленника до способности выдавать сертификаты для этих доменов.

Дополнительные сведения об ACME-DNS см. на странице:
github.com/joohoi/acme-dns

Вывод


Чтобы устранить проблемы с проверкой владения доменом через ACME DNS, обсуждались такие предложения, как assisted-DNS в рабочей группе ACME IETF, но в настоящее время эти проблемы все еще остаются без разрешения. Поскольку единственный способ ограничить воздействие компрометации — это ограничить права доступа учетных записей DNS-зоны до изменения определенных TXT-записей, текущие возможности для надежной реализации автоматизации проверки владения доменом незначетельны.

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

habr.com

Что такое MX-запись домена, как ее проверить и узнать

Тематический трафик – альтернативный подход в продвижении бизнеса

Мы выпустили новую книгу «Контент-маркетинг в социальных сетях: Как засесть в голову подписчиков и влюбить их в свой бренд».

Подпишись на рассылку и получи книгу в подарок!

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

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

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

Что такое MX-запись домена

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

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

Настройка MX-записи домена

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

В случае, если у человека есть агент пересылки сообщений и ему нужно сделать так, чтобы прием сообщений осуществлялся именно им, следует выполнить определенные действия для применения настроек. В частности, необходимо, во-первых, открыть панель управления виртуальным хостингом, после чего перейти в раздел «Управление»; во-вторых, для каждого имени следует обозначить домен третьего и более уровня. Делается это довольно легко. К примеру, если имя @example.com, то после добавления имени, которое является частью более высокого уровня, получиться @mx.example.com.

После этого следует подтвердить свои действия, нажав на кнопку «Добавить», чтобы результат сохранился.

Следующий шаг – ввод уникального сетевого узла, построенного на основе стека протоколов TCP/IP, для @mx.example.com. Для этого нужно войти в раздел настроек и указать публичный адрес почтового сервера в свободном поле.

Важно перейти в раздел «Настройки» @example.com и отметить галочкой, что для этого домена не проставлены MX-записи. В процессе может возникнуть проблема, свидетельствующая, что почтовые ящики, применяющие уже готовые записи, существуют и готовы к использованию.

Решается этот вопрос довольно легко: достаточно зайти в раздел настроек «Управление почтой» и отвязать абсолютно каждую привязанную к нему учетку.

Как проверить MX-запись домена

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

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

Провести самостоятельную проверку очень просто. Для этих целей существует огромное количество различных установочных программ на персональные компьютеры, а также онлайн-сервисы. Наиболее популярными вариантами являются утилита Nslookup, которая дает возможность задавать различные типы запросов и опрашивать случайно подобранные сервера, а также веб-сервис Dig. Они встроены в операционные системы и предоставляются пользователю вместе с ПК.

Зачем смотреть MX-запись домена

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

На ПК с операционной системой Windows, MacOS и Linux есть встроенная утилита – Nslookup. Чтобы открыть ее, следует выбрать комбинацию клавиш Windows+R и в появившееся окно вписать команду «cmd». После этого будет открыта командная строка, где пользователь сможет подробно изучить текущий статус.

Создание MX-записи

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

Процесс создания должен проистекать в панели управления веб-хостингом ISPmanager во вкладке «Управление записями. Для этого следует нажать на кнопку «Создать».

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

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

  1. Название, которое может содержать в себе любое слово, включая поддомен.
  2. Точное время, когда информация обновляется.
  3. Здесь необходимо указать тип записи. При этом, для разных целей применяются индивидуальные параметры, а от ее типа зависит и назначение.
  4. Далее указывается непосредственно домен, а после него – приоритет.

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

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

semantica.in

10 примеров использования команды dig для просмотра параметров DNS (DNS Lookup) в Linux

Итак, что такое dig?

dig (англ. слово «копать», а формально — сокращение от «domain information groper») — утилита (DNS-клиент), предоставляющая пользователю интерфейс командной строки для обращения к системе DNS. Позволяет задавать различные типы запросов и запрашивать произвольно указываемые сервера. Является аналогом утилиты nslookup.

Утилита dig входит в стандартный комплект DNS сервера BIND.

Начнем,

1. Простой вывод команды dig (для понимания вывода, без доп.параметров )

Когда вы задаете имя домена в команде dig по-умолчанию вы получаете A-запись домена (ip-адрес сайта (домена) который мы запрашивали) как показано на листинге ниже

$dig ya.ru

; <<>> DiG 9.7.3 <<>> ya.ru
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31244
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ya.ru.                         IN      A

;; ANSWER SECTION:
ya.ru.                  2187    IN      A       87.250.251.3
ya.ru.                  2187    IN      A       77.88.21.3
ya.ru.                  2187    IN      A       213.180.204.3
ya.ru.                  2187    IN      A       93.158.134.3
ya.ru.                  2187    IN      A       213.180.193.3
ya.ru.                  2187    IN      A       87.250.250.203
ya.ru.                  2187    IN      A       93.158.134.203
ya.ru.                  2187    IN      A       87.250.250.3

;; Query time: 2 msec
;; SERVER: 10.218.138.252#53(10.218.138.252)
;; WHEN: Fri Mar 23 15:21:18 2012
;; MSG SIZE  rcvd: 151


В примере можно увидеть A-записи домена ya.ru в разделе ANSWER SECTION

Давайте рассмотрим разделы данного вывода подробней:
— HEADER (заголовок): показывает версию dig, глобальные опции используемые с командой и другую дополнительную информацию
— QUESTION SECTION (секция запроса): Показывает наш запрос, то бишь мы запросили показать A-запись (команда dig без параметров) для домена ya.ru
— ANSWER SECTION (секция ответа): Показывает ответ полученный от DNS, в нашем случае показывает A-запись для ya.ru
Последняя секция это статистика по запросу (служебная информация) — время выполнения запроса, имя DNS-сервера который запрашивался, когда был создан запрос и размер сообщения

Так же можно выполнить опрос конкретного DNS-сервера:

 

$dig @ns1.yandex.ru ya.ru

; <<>> DiG 9.7.3 <<>> @ns1.yandex.ru ya.ru
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56730
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ya.ru.                         IN      A

;; ANSWER SECTION:
ya.ru.                  7200    IN      A       77.88.21.3
ya.ru.                  7200    IN      A       87.250.250.3
ya.ru.                  7200    IN      A       87.250.250.203
ya.ru.                  7200    IN      A       87.250.251.3
ya.ru.                  7200    IN      A       93.158.134.3
ya.ru.                  7200    IN      A       93.158.134.203
ya.ru.                  7200    IN      A       213.180.193.3
ya.ru.                  7200    IN      A       213.180.204.3

;; AUTHORITY SECTION:
ya.ru.                  7200    IN      NS      ns1.yandex.ru.
ya.ru.                  7200    IN      NS      ns5.yandex.ru.

;; ADDITIONAL SECTION:
ns1.yandex.ru.          345600  IN      A       213.180.193.1
ns1.yandex.ru.          3600    IN      AAAA    2a02:6b8::1
ns5.yandex.ru.          345600  IN      A       213.180.204.1

;; Query time: 13 msec
;; SERVER: 213.180.193.1#53(213.180.193.1)
;; WHEN: Fri Mar 23 14:41:37 2012
;; MSG SIZE  rcvd: 254


Результат вывода дополняется еще двумя секциями:
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)

Пример:

$ dig ya.ru +nocomments +noquestion +noauthority +noadditional +nostats

; <<>> DiG 9.7.3 <<>> ya.ru +nocomments +noquestion +noauthority +noadditional +nostats
;; global options: +cmd
ya.ru.                  114     IN      A       77.88.21.3
ya.ru.                  114     IN      A       213.180.204.3
ya.ru.                  114     IN      A       93.158.134.3
ya.ru.                  114     IN      A       213.180.193.3
ya.ru.                  114     IN      A       87.250.250.203
ya.ru.                  114     IN      A       93.158.134.203
ya.ru.                  114     IN      A       87.250.250.3
ya.ru.                  114     IN      A       87.250.251.3


Можно сделать проще, существует ключ +noall, который выключает все секции. Таким образом мы используем ключ +noall и добавляем ключ +answer, уменьшая длину команды

 

$ dig ya.ru +noall +answer

; <<>> DiG 9.7.3 <<>> ya.ru +noall +answer
;; global options: +cmd
ya.ru.                  7152    IN      A       213.180.193.3
ya.ru.                  7152    IN      A       87.250.250.203
ya.ru.                  7152    IN      A       93.158.134.3
ya.ru.                  7152    IN      A       87.250.250.3
ya.ru.                  7152    IN      A       77.88.21.3
ya.ru.                  7152    IN      A       213.180.204.3
ya.ru.                  7152    IN      A       87.250.251.3
ya.ru.                  7152    IN      A       93.158.134.203


3. Запрос MX-записи

Для запроса MX-записи домена мы используем одноименный аргумент командной строки (MX)
 

$ dig ya.ru  MX +noall +answer

; <<>> DiG 9.7.3 <<>> ya.ru MX +noall +answer
;; global options: +cmd
ya.ru.                  1979    IN      MX      10 mx.yandex.ru.


Этот же запрос можно выполнить с ключом -t (тип)

$ dig -t MX ya.ru +noall +answer

; <<>> DiG 9.7.3 <<>> -t MX ya.ru +noall +answer
;; global options: +cmd
ya.ru.                  1903    IN      MX      10 mx.yandex.ru.


4. Запрос NS-записи

По аналогии с предыдущим пунктом, используем аргумент NS
 

$ dig ya.ru NS +noall +answer

; <<>> DiG 9.7.3 <<>> ya.ru NS +noall +answer
;; global options: +cmd
ya.ru.                  7170    IN      NS      ns5.yandex.ru.
ya.ru.                  7170    IN      NS      ns1.yandex.ru.


Вы также можете использовать ключ -t для указания типа запроса

$ dig -t NS ya.ru +noall +answer

; <<>> DiG 9.7.3 <<>> -t NS ya.ru +noall +answer
;; global options: +cmd
ya.ru.                  7088    IN      NS      ns5.yandex.ru.
ya.ru.                  7088    IN      NS      ns1.yandex.ru.

5. Просмотр всех типов DNS-записей

Для этого используется ключ ANY

$ dig ya.ru ANY +noall +answer

; <<>> DiG 9.7.3 <<>> ya.ru ANY +noall +answer
;; global options: +cmd
ya.ru.                  4931    IN      TXT     "v=spf1 redirect=_spf.yandex.ru"
ya.ru.                  6963    IN      NS      ns1.yandex.ru.
ya.ru.                  6963    IN      NS      ns5.yandex.ru.
ya.ru.                  1533    IN      MX      10 mx.yandex.ru.
ya.ru.                  6494    IN      A       93.158.134.203
ya.ru.                  6494    IN      A       213.180.193.3
ya.ru.                  6494    IN      A       87.250.250.203
ya.ru.                  6494    IN      A       93.158.134.3
ya.ru.                  6494    IN      A       87.250.250.3
ya.ru.                  6494    IN      A       77.88.21.3
ya.ru.                  6494    IN      A       213.180.204.3
ya.ru.                  6494    IN      A       87.250.251.3


Также допустим ключ -t

$ dig -t ANY ya.ru  +noall +answer

; <<>> DiG 9.7.3 <<>> -t ANY ya.ru +noall +answer
;; global options: +cmd
ya.ru.                  4857    IN      TXT     "v=spf1 redirect=_spf.yandex.ru"
ya.ru.                  6889    IN      NS      ns5.yandex.ru.
ya.ru.                  6889    IN      NS      ns1.yandex.ru.
ya.ru.                  1459    IN      MX      10 mx.yandex.ru.
ya.ru.                  6420    IN      A       213.180.204.3
ya.ru.                  6420    IN      A       87.250.251.3
ya.ru.                  6420    IN      A       93.158.134.203
ya.ru.                  6420    IN      A       213.180.193.3
ya.ru.                  6420    IN      A       87.250.250.203
ya.ru.                  6420    IN      A       93.158.134.3
ya.ru.                  6420    IN      A       87.250.250.3
ya.ru.                  6420    IN      A       77.88.21.3


6. Краткий вывод команды dig

Допустим чтобы просмотреть только ip-адрес, без лишней информации, используем опцию +short

$ dig ya.ru +short
213.180.193.3
93.158.134.203
87.250.250.203
77.88.21.3
213.180.204.3
87.250.250.3
93.158.134.3
87.250.251.3

Также интересно:


Вы также можете вывести информацию по любому виду информации с ключем +short
Пример:

$ dig ya.ru ns +short
ns5.yandex.ru.
ns1.yandex.ru.


7. Просмотр информации об обратной зоне домена (PTR)

Для просмотра обратной зоны необходимо использовать ключ -х
Для примера, мы хотим узнать имя домена по айпи-адресу 77.88.21.3
 

$ dig -x 77.88.21.3 +short
www.yandex.ru.

Для вывода полной информации убираем ключ +short
 

$dig -x 77.88.21.3

; <<>> DiG 9.7.3 <<>> -x 77.88.21.3
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 885
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;3.21.88.77.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
3.21.88.77.in-addr.arpa. 11007  IN      PTR     www.yandex.ru.

;; Query time: 2 msec
;; SERVER: 10.218.138.252#53(10.218.138.252)
;; WHEN: Fri Mar 23 16:21:23 2012
;; MSG SIZE  rcvd: 68

8. Использование конкретного DNS-сервера для выполнения запроса

Для использования конкретного DNS-сервераиспользуется запись вида — @dnsserver, где dnsserver это или имя или ip-адрес DNS-сервера
Данный пример мы рассмотрели в п.1

9. Объемный запрос (запрос информации сразу о нескольких доменах)

Для запроса информации о нескольких доменах возможно использование текстовых файлов с перечислением доменов.
Создадим файл names.txt с именами доменов:
 

$nano names.txt
ya.ru
google.ru


Далее используем ключ -f для чтения из файла:

$ dig -f names.txt +noall +answer
ya.ru.                  5241    IN      A       87.250.251.3
ya.ru.                  5241    IN      A       93.158.134.203
ya.ru.                  5241    IN      A       213.180.193.3
ya.ru.                  5241    IN      A       87.250.250.203
ya.ru.                  5241    IN      A       93.158.134.3
ya.ru.                  5241    IN      A       87.250.250.3
ya.ru.                  5241    IN      A       77.88.21.3
ya.ru.                  5241    IN      A       213.180.204.3
google.ru.              231     IN      A       74.125.232.55
google.ru.              231     IN      A       74.125.232.56
google.ru.              231     IN      A       74.125.232.63


Также можно комбинировать тип DNS записи c опцией -f:
 

$dig -f names.txt MX +noall +answer
ya.ru.                  184     IN      MX      10 mx.yandex.ru.
google.ru.              10800   IN      MX      10 google.com.s9b1.psmtp.com.
google.ru.              10800   IN      MX      10 google.com.s9a2.psmtp.com.
google.ru.              10800   IN      MX      10 google.com.s9b2.psmtp.com.
google.ru.              10800   IN      MX      10 google.com.s9a1.psmtp.com.

 
Также возможно перечисление доменов непосредственно в командной строке. Для примера узнаем MX-запись для домена ya.ru и NS-запись для домена google.ru:
 

dig ya.ru mx +noall +answer google.ru ns +noall +answer

; <<>> DiG 9.7.3 <<>> ya.ru mx +noall +answer google.ru ns +noall +answer
;; global options: +cmd
ya.ru.                  7143    IN      MX      10 mx.yandex.ru.
google.ru.              66518   IN      NS      ns4.google.com.
google.ru.              66518   IN      NS      ns3.google.com.
google.ru.              66518   IN      NS      ns1.google.com.
google.ru.              66518   IN      NS      ns2.google.com.

10. Изменение параметров по умолчанию для команды dig

Например вы хотите, чтобы утилита dig по умолчанию выводила только секцию ответа (ANSWER SECTION).
Для этого необходимо внести в файл .digrc необходимые ключи, в нашем случае +noall +answer:
 

$nano $HOME/.digrc
+noall +answer

Вывод будет:

$ dig ya.ru
ya.ru.                  4162    IN      A       93.158.134.203
ya.ru.                  4162    IN      A       213.180.193.3
ya.ru.                  4162    IN      A       87.250.250.203
ya.ru.                  4162    IN      A       93.158.134.3
ya.ru.                  4162    IN      A       87.250.250.3
ya.ru.                  4162    IN      A       77.88.21.3
ya.ru.                  4162    IN      A       213.180.204.3
ya.ru.                  4162    IN      A       87.250.251.3


Таким образом мы рассмотрели мизерную часть этой замечательной утилиты, для тех, кто хочет большего, добро пожаловать в man dig 😉

greendail.ru

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *