Как сделать обратную зону dns

Обновлено: 04.07.2024

Например, у вас в сети могут быть зеркала ваших сайтов в apache, прокси сервер squid, музыкальный сервер mpd, получить доступ к ним можно используя ip адрес, либо записи в файле hosts. Но начинается рутина, когда в сети компьютеров больше чем два. Используя собственную dns зону на собственном dns сервере, можно задать например такие понятные и лаконичные имена:

mysql.ff - для указания amarokу где лежит его коллекция

mpd.ff - адрес mpd сервера

proxy.ff - адрес прокси сервера сети

К тому же можно избавить от суфикса .ff просто добавив в файл /etc/resolve.conf строчки

В общем потратьте пару минут сейчас и вы съкономите часы после

Созадём прямую зону, напримере bind в Ubuntu 8.04

В файл /etc/bind/named.conf.local добавить имя и файл новой зоны, в моём случае .xxx

Затем создаём файл зоны и добавляем туда вот это:

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

Обратная зона

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

В файл /etc/bind/named.conf.local добавить имя и файл нашей обратной зоны:

А в файл обратной зоны вот это:

Теперь проверим хозяйство:

nslookup eee.xxx

nslookup 192.168.80.75

nslookup proxy.xxx

nslookup 192.168.80.77

позже: о том как поднять собственный кеширующий dns сервер

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

Что такое обратная зона в DNS. Что такое PTR запись.

Что такое обратная зона в DNS. Что такое PTR запись.

Обратный запрос DNS — особая доменная зона, предназначенная для определения имени узла по его IPv4-адресу c помощью PTR-записи. Адрес узла AAA.BBB.CCC.DDD переводится в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP-адресов. Для этого в записях авторитетного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC.000/24) отвечает отдельный сервер.


in-addr.arpa — специальная доменная зона, предназначенная для определения имени хоста по его IPv4-адресу, используя PTR-запись. Адрес хоста AAA.BBB.CCC.DDD транслируется в обратной нотации и превращается в DDD.CCC.BBB.AAA.in-addr.arpa. Благодаря иерархической модели управления именами появляется возможность делегировать управление зоной владельцу диапазона IP адресов. Для этого в записях авторитативного DNS-сервера указывают, что за зону CCC.BBB.AAA.in-addr.arpa (то есть за сеть AAA.BBB.CCC/24) отвечает отдельный сервер.

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

В целях уменьшения объёма нежелательной почтовой корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.

В данном материале мы рассмотрим конфигурацию программы named при организации сервера домена, чьи хосты распределены по двум физическим IP-сетям класса C (в нотации CIDR x.x.x.x/24). Основное внимание будет уделено "обратным" зонам, т.к. "прямая" зона в этом случае не имеет существенных отличий от зоны, рассмотренной при описании небольшого корпоративного домена.

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

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

192.168.0.0/24 и 192.168.10.0/24

С точки зрения описания соответствия между доменным именем и IP-адресом в "прямой" зоне здесь проблем нет:

Из примера видно, что адресные записи могут прекрасно "перемешиваться" в описании зоны. Таким образом, прямую зону можно определить на любом множестве наборов адресов, которые могут быть, как угодно разбросаны по адресному пространству.

Конечно, есть адреса, которые нельзя мешать. Например, нельзя мешать маршрутизируемые и немаршрутизируемые адреса. Собственно, в примере мы используем именно последние (подробнее о немаршрутизируемых адресах см. RFC 1918).

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

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

И так, в "прямой" зоне мы можем "мешать" адреса, но вот как поддерживать обратные соответствия? Ведь в случае "обратных" зон мы имеем дело тоже с доменными именами, хотя они и образованы инверсией IP-адресов. Разделителем в иерархии именования доменов является символ ".", следовательно, границы байтов в адресе будут соответствовать границам вложенности доменов.

Выход простой – создать две обратных зоны 0.168.192.in-addr.arpa и 10.168.192.in-addr.arpa. Выглядеть это будет примерно так:

И для 0.168.192.in-addr.arpa. соответственно:

На master сервере должно быть объявлено две "обратных" зоны. В BIND 4.x в файле named.boot это будет выглядеть примерно так:

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

Здесь стоит только пояснить, что в данном случае адрес 192.168.20.1 – это адрес slave сервера, которому разрешено копировать зону. Назначение остальных директив управления подробно рассмотрено в "Небольшой корпоративный домен в домене ru. Описание "прямых" зон. Описание "обратных" зон. Настройки BIND.".

Что же касается файла named.conf версий BIND 8.х и 9.х, то его содержание будет выглядеть примерно так:

options ;
//Root server hints
zone "." ;
// Forward Loopback
zone "localhost" ;
// Reverse Loopback
zone "0.0.127.in-addr.arpa" ;
// Corporative domain
zone "test.ru" ;
>;
// Reverse corporative domain
zone "0.168.192.in-addr.arpa" ;
>;
// Reverse corporative domain
zone "10.168.192.in-addr.arpa" ;
>;

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

Здесь следует отметить, что несколько обратных зон появляются, например, и для сетей типа x.x.x.x/23. Вся штука в том, что, адресный пул, например, 192.168.0.0.23, объединяет два смежных блока 192.168.0.0/24 и 192.168.1.0/24. Соответствующих обратных зон, следовательно, будет две: 0.168.192.in-addr.arpa и 1.168.192.in-addr.arpa. Объединить их стандартным образом можно только на уровне 168.192.in-addr.arpa, но никак не ниже.

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

Аналогичные замечания справедливы и для адресных пулов x.x.x.x/16 и для адресных пулов x.x.x.x.8, т.е. сетей классов B и A соответственно. Пространство доменных имен "обратных" зон построено с учетом старой классификации адресов, в то время, когда нотация CIDR широко еще не использовалась.

В документе RFC 1519 подробно разбирается отображение адресного пространства CIDR на "суперсети" сетей класса C, т.е. пулов адресов, которые составлены из подсетей сетей класса B и A. Провайдер в этом случае должен делегировать соответствующие обратные зоны клиентам, а те обеспечить их поддержку способом, похожим на случай 192.168.0.0/23, рассмотренный выше.

Зоной (zone) в DNS называется часть пространства имен DNS, за управление которой от­вечает определенный сервер или группа серверов DNS. Она является в DNS основным ме­ханизмом для делегирования полномочий и применяется для установки границ, в пределах которых определенному серверу разрешено выполнять запросы. Любой сервер, который обслуживает какую-то определенную зону, считается полномочным или ответственным за эту зону; исключением являются разве что зоны-заглушки.

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

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

Зоны прямого просмотра

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

Зоны обратного просмотра

Зоны обратного просмотра (reverse lookup zone) выполняют прямо противоположную операцию той, что выполняют зоны прямого просмотра. Они предусматривают сопостав­ление IP-адресов с обычным именем. Эта похоже на поиск телефонного номера, когда сам номер известен, а имя того, кому он принадлежит, нет. Зоны обратного просмотра обычно создаются вручную и вовсе необязательно присутствуют в каждой реализации. За счет при­менения мастера настройки сервера DNS (Configure a DNS Server), как описывалось ранее в главе, процесс создания такой зоны может быть автоматизирован. Как правило, зоны обратного просмотра заполняются записями PTR, которые служат для указания запросу обратного просмотра на соответствующее имя.

  • Вторичные зоны DNS для особого преобразования именВ некоторых ситуациях в Active Directory.

">Вторичные зоны в среде AD DS – 25/01/2013 04:36
Встроенные в каталог зоны DNSНаиболее важным изменением в реализации DNS в Windows 2000 Server.

">Зоны интегрированные в Active Directory – 24/01/2013 04:18
Первичные зоны В традиционной DNS (не интегрированной в Active Directory) какой-то один сервер.

  • Копирование базы данных DNSКопирование базы данных DNS с одного сервера на другой производится с.

">Выполнение переносов зон DNS – 22/01/2013 04:31
Концепция зон-заглушекКонцепция зон-заглушек является уникальной и встречается только в DNS.

">Создание зоны заглушки DNS – 22/01/2013 04:29
Первичные зоны В традиционной DNS (не интегрированной в Active Directory) какой-то один сервер.

  • Ключевые записи ресурсовВ иерархии DNS объекты идентифицируются за счет применения так называемых.

">Записи ресурсов DNS – 22/01/2013 04:16
Конфигурирование DNS-сервера для указания на самого себя Одной из дополнительных задач, которая.

">Дополнительное конфигурирование DNS – 21/01/2013 05:53
Установка DNS с помощью мастера добавления ролейХотя существует несколько различных способов для.





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

Мы собираемся поговорить о том, как прямой просмотр системы доменных имен (DNS) может помочь вашей бизнес-для-бизнеса (B2B) компании извлечь выгоду на обратном просмотре DNS (rDNS).

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

Честно говоря, это очень важная информация, — просто не нагружайте голову другими темами, пока мы не закончим.

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

При прямом просмотре DNS, DNS запрашивается для получения IP-адреса определенного имени хоста.

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

В принципе, обратный просмотр DNS возвращает имя хоста IP-адреса.

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

Знание того, кто интересуется в том, что вы можете предложить, — это та информация, за которую Tinder требует платную подписку.


Какую функцию выполняет инструмент обратного просмотра DNS?

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

Он позволяет выполнять обратный просмотр DNS.

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

Не верите? Попробуйте сами.

Вы можете использовать приведенную выше форму для обратного просмотра DNS. Введите IP-адрес (например, 8.8.8.8), нажмите клавишу enter и инструмент выполнит обратный просмотр DNS и покажет параметры имени для этого IP-адреса.


Что такое обратный просмотр DNS простыми словами

Вы можете использовать приведенную выше форму для обратного просмотра DNS.

Введите IP-адрес (например, 8.8.8.8) и нажмите клавишу enter. Инструмент выполнит обратный просмотр DNS и предоставит параметры имени для этого IP-адреса.

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

Согласно отчету CSO Insights за 2018 год, более 70 процентов B2B покупателей точно знают, что им нужно, прежде чем обратиться к торговому представителю.

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

Когда вы определяете B2B покупателя на ранней стадии процесса, у вас есть шанс ворваться с решением (вашим решением). Даже если это не тот продукт, за которым пришёл покупатель (пока что не тот).

Итак, вы хотите видеть такие данные для всех посетителей вашего сайта? Конечно же хотите. Вы не против того, чтобы зарабатывать деньги — в конце концов, это Америка (или страна, в которой вы находитесь).
Разбивка понятия обратного DNS, чтобы ваша команда продаж его поняла

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

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

DNS расшифровывается как Система Доменных Имен. Это список адресов компьютеров, подключенных к интернету.

Если вы зайдете в Google, вы спросите DNS, где находится эта компания в онлайн.

Точно так же, как вы использовали бы картотеку, чтобы найти адрес в реальной жизни. Шутка, никто не использует картотеки в реальной жизни.

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

Однако благодаря цифровой революции, обратный просмотр DNS (rDNS) позволяет найти чье-то имя исходя из его (интернет) адреса.

Поиск rDNS — это процесс поиска интернет-хостов по их IP-адресу.

Отсюда и "обратное" различие в названии.

Помимо поиска IP-адреса Google, вы также можете определить, какая компания работает с IP-адреса 8.8.8.8.

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

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

Каждое устройство, подключенное к интернету, имеет свой IP-адрес.

Да. Это означает, что ваш телефон, робот-пылесос, Amazon Echo и — самое главное в мире B2B — рабочие компьютеры имеют свой собственный IP-адрес.

Хотя не у каждого IP-адрес есть обратный отчет DNS, у большинства из них все же есть.

Например, когда вы открыли этот пост в блоге, ваше устройство предоставило ваш IP-адрес нашему серверу, а ваш браузер получил наш IP-адрес. Все благодаря DNS!

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

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

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

Запустив обратный DNS, Leadfeeder отслеживает IP-адрес тех, кто посещает ваш сайт, вплоть до их компании.

Это не ракетостроение, но он делает свою работу.

Что такое "ptr-запись" и "in-addr.arpa"?

Извините, но мы еще не закончили с техническим жаргоном понимания обратного просмотра DNS.

DNS определяется зонами. Зона — это отдельная часть пространства доменных имен. Традиционно, DNS управлялся как однофайловая зона.

Чаще всего доменом является одна зона.

Владелец зоны сопоставляет разные адреса с разными доменными именами в своей зоне.

Например, он сопоставляет IP-адрес 23.25.62.12 с именем хоста "www" в зоне "example.com". Это делается с помощью записей DNS.

Но что насчет обратного DNS?

PTR-запись — это запись для обратного DNS.

Итак, владелец зоны просто добавляет какой-либо IP-адрес в свою зону, и все готово? Нет, обратный DNS работает наоборот.

PTR-запись хранится в специальной зоне под названием .in-addr.arpa.

Эта зона управляется тем, кто владеет блоком IP-адресов. В приведенном примере зоной для записи PTR будет являться 12.62.25.23.in-addr.arpa. Владельцем IP-адреса обычно является интернет-провайдер (ISP), и если вы хотите добавить PTR-запись к своему IP-адресу, вам необходимо связаться с вашим провайдером.

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

Почему кого-то должно волновать, как сделать обратный просмотр DNS?

Ну, честно говоря, большинству людей все равно.

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

Давайте все же разберемся с этой темой:

У вас есть веб-сайт. Это очевидно, потому что вы управляете бизнесом в 21 веке.

Этот веб-сайт постоянно собирает IP-адреса с устройств, которые его посещают.

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

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

Однако, поскольку бизнес можно идентифицировать с помощью обратного DNS просмотра, Leadfeeder может собирать данные о компании из LinkedIn.

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

Дело в том, что большинство обычных людей не владеют своим IP-адресом.

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

Согласно исследованию Deloitte, проведенному в 2019 году, в среднестатистическом американском доме есть 11 подключённых к интернету устройств.

Таким образом, большинство людей в основном арендуют IP-адрес у своего провайдера. Обычно это относится к мобильным телефонам и домашним широкополосным соединениям. Ваше имя хоста будет выглядеть примерно так — 62.78.145.65.bb.dnainternet.fi.

Удивительно, но в этом IP-адресе все еще скрыто много информации. Вы можете узнать детали об этом с помощью WHOIS.

Например, этот адрес говорит вам, что пользователь из Хельсинки, Финляндия, а его интернет-провайдер — DNA.

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

Это здорово, но вы все еще не сможете идентифицировать точного человека с этой информацией.

BIND – наиболее распространенное open-source приложение, в котором реализованы протоколы DNS, предоставляющие возможность преобразования доменных имен в IP-адреса и наоборот.

Данная статья представляет собой руководство по быстрой настройке DNS-сервера в Linux при помощи BIND. Мы не будем подробно разбирать, что такое система DNS и как она работает, а сосредоточимся на примере настройки своей зоны и файла конфигурации для домена/узла с поддержкой сервисов www и электронной почты.

Установка сервера bind

Установка bind очень проста – нужно воспользоваться менеджером пакетов. В Debian и Ubuntu выполните следующую команду:

В CentOS или Fedora:

Пакет dnsutils необязателен для запуска сервера bind, но для тестирования конфигурации мы будем пользоваться командой dig из этого пакета.

Создание файла зоны DNS

Рассмотрим ключевые строки этого файла:

Настройка обратной зоны

Запись PTR: DNS-запись, используемая для определения соответствия IP-адреса имени узла.

Настройка файла конфигурации bind

На данный момент у нас должно быть два файла:

Теперь требуется вставить имена обоих файлов зоны в файл конфигурации bind /etc/bind/named.conf.local . Для этого добавьте в файл следующие строки:

Последний момент перед проверкой конфигурации – внести в файл named.conf.options IP-адрес стабильного DNS-сервера. Он будет использоваться, если локальный DNS-сервер не будет знать ответ на запрос разрешения имени. Часто этот адрес предоставляется интернет-провайдером, но если вы поклонник Google, можно указать адрес 8.8.8.8 или 8.8.4.4.

Замените следующий блок текста в файле named.conf.options:

на блок текста с адресом стабильного DNS-сервера

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

А лучше, для безопасности вместо any пропишите ваши сети с которых разрешено подключение

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

Проверка файлов зоны и конфигурации

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

Для проверки файлов конфигурации выполните следующую команду:

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

Для проверки файлов зоны DNS можно воспользоваться командой named-checkzone:

Проверка обратной зоны

Запуск и перезапуск сервера bind

Теперь мы можем запускать сервер bind:

Если сервер уже был запущен, его можно перезапустить командой restart:

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

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

Для тестирования новой конфигурации сервера имен bind нам пригодится команда dig из пакета dnsutils. Эту команду можно запустить на любом компьютере с сетевым доступом к вашему DNS-серверу, но лучше всего начать тестирование с локального узла. В рассматриваемом нами примере IP-адрес сервера имен 172.31.0.122. Сначала проверим прямое разрешение имени (получение IP-адреса по доменному имени):


Теперь проверим обратную зону:

dig @172.31.0.122 -x 172.31.1.10


Если вы получили аналогичные результаты, то зона DNS настроена правильно. Вместо команды dig для тестирования можно также использовать команду nslookup.


nslookup 172.31.1.10 172.31.0.122


Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

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