Whois: Практическое Руководство Пользователя

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

Его основная задача — помочь написать скрипты для получения whois-информации по IP-адресам и доменам.



Что такое кто?

Что такое whois и для чего он нужен, можно прочитать, например, здесь: http://en.wikipedia.org/wiki/Whois .

В двух словах whois (от английского whois — «кто есть») — это сетевой протокол, основанный на протоколе TCP. Его основная цель — получить в текстовом виде регистрационные данные о владельцах IP-адресов и доменных имен (в основном, их контактную информацию).

Запись домена обычно содержит имя и контактную информацию «регистранта» (владельца домена) и «регистратора» (организации, зарегистрировавшей домен), имена DNS-серверов, дату регистрации и срок действия.

дата.

Записи об IP-адресах сгруппированы по диапазонам (например, 8.8.8.0 — 8.8.8.255) и содержат данные об организации, которой делегирован этот диапазон.

Whois часто используется для проверки того, доступно ли доменное имя или оно уже зарегистрировано.

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

Стоит отметить, что вся контактная информация вводится при регистрации и со временем может устареть.

У каждого регистратора своя процедура их обновления, кроме того, сам процесс может занять некоторое время (хотя обычно это происходит в течение 24 часов).

Протокол подразумевает клиент-серверную архитектуру и используется для доступа к общедоступным серверам баз данных (обычно к самим регистраторам IP-адресов и доменных имен).

В некоторых случаях whois-сервер конкретного домена верхнего уровня содержит полную базу данных всех зарегистрированных доменов.

В других случаях такой whois-сервер содержит только самую основную информацию и относится к whois-серверам конкретных регистраторов.

Остальные подробности будут обсуждаться по ходу самой статьи.

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



Немного предыстории

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

Однако после миграции продукта на новую версию FreeBSD внезапно выяснилось, что jwhois перестал работать: для большинства доменов стала появляться абсолютно нелогичная ошибка «Невозможно подключиться к удаленному хосту».

Гугл не помог, и я уже был готов приступить к отладке кода на С, как вдруг выяснилось, что jwhois нам совершенно не подходит из-за своей лицензии (GPL v3).

В общем, возникла задача найти какое-то альтернативное решение.

К моему удивлению, разумных альтернатив не нашлось.

Большинство форумов рекомендуют использовать один и тот же файл jwhois. Несколько программ, конечно, нашлись (в том числе несколько библиотек на родном для нашего продукта языке Python), но большинство из них были отвергнуты буквально после первого же теста на домене в зоне «ua».

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

Единственная заслуживающая доверия на тот момент библиотека была написана на Ruby (что нас совершенно не устраивало) и имела устрашающий размер исходных кодов и различных конфигурационных файлов для каждого конкретного whois-сервера.

Еще существовала стандартная утилита Unix под названием «whois», но ее работа оставляла желать лучшего.

В общем, единственным вариантом было сесть, прочитать спецификации протокола и написать решение самому.

Результатом этого стал модуль на Python с 1000 строк кода, в процессе написания которого я последовательно наступал на все сопутствующие грабли, и, в конечном итоге, эта статья, в которой рассказывается обо всех этих «граблях» (да, если что , то код является собственностью).

Забегая вперед отмечу, что с высоты полученного опыта и jwhois, и Ruby Whois( http://www.ruby-whois.org ) теперь тоже выглядят «оставляющими желать лучшего».



в чем именно проблема?:

Вся работа Whois описана в RFC 3912 ( http://tools.ietf.org/html/rfc3912 ) и занимает 4 страницы.

В двух словах все сводится к следующему: открыть TCP-соединение по порту 43 с нужным whois-сервером, отправить запрос в определенном формате (который для конкретного whois-сервера может быть любым), завершить его "\r \n" и получаем результат, формат которого для конкретного whois-сервера тоже может быть любым.

Закрытие соединения сервером означает конец результата.

Все! Другими словами, каждый whois-сервер определяет формат связи по своему усмотрению.

Это не говоря о том, что совершенно не очевидно, где взять необходимый whois-сервер для конкретного домена или IP-адреса.

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

По сути, все сводилось к пережевыванию скудной информации из RFC и названий нескольких самых известных whois-серверов.

Хотя некоторую разрозненную информацию нам все же удалось найти.

В общем, мне пришлось посмотреть код Unix whois, а также jwhois и Ruby Whois — об их принципе работы пойдет речь дальше.



Unix-кто есть кто

Итак, как работает Whois в Unix?
  • Если мы ищем домен, мы определяем для него домен верхнего уровня (например, «ru») и отправляем запрос на whois-сервер типа ru.whois-servers.net. Если полученный результат содержит строку типа «Whois Server: », затем отправляем запрос также на этот новый сервер и объединяем результаты.

  • Если мы ищем IP-адрес, мы отправляем запрос на whois.arin.net (сервер whois, отвечающий за Северную Америку).

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

  • Для большинства whois-серверов запрос отправляется в формате " \r\n».

    Для двух whois-серверов (whois.denic.de и whois.dk-hostmaster.dk) запрос отправляется в своем специальном формате.

  • Пользователь имеет возможность указать whois-сервер для связи.

Примечание: дополнительный функционал, который меня не интересовал (не связанный с доменами и IP-адресами), здесь и далее опущен.

Как видите, все предельно просто.

И действительно, во многих случаях это работает. Для многих доменов .

whois-servers.net — это псевдоним реального whois-сервера (но для многих это не так, и запрос, естественно, не проходит).

Также whois.arin.net для многих IP-адресов, за которые сам не несет ответственности, тем не менее знает правильный региональный сервер и корректно отправляет на него (однако в некоторых случаях все равно не знает или отправляет на него в произвольном формате , не обязательно с упоминанием имени самого whois-сервера, на который опирается программа).

Большинство whois-серверов понимают формат " \r\n", но исключения ни в коем случае не ограничиваются двумя серверами.

И, конечно, ссылка на другой whois-сервер не обязательно будет строго в формате «Whois-сервер: ”.

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

Например:

  
  
  
  
  
  
  
  
  
   

$ whois google.com GOOGLE.COM.ZZZZZZZZZZZZZZZZZZZZZZZZZZZ.LOVE.AND.TOLERANCE.THE-WONDERBOLTS.COM GOOGLE.COM.ZZZZZZZZZZZZZZZZZZZZZZZZZZ.HAVENDATA.COM GOOGLE.COM.ZZZZZZZZZZZZZ.GET.ONE.MILLION.DOLLARS.AT.WWW.UNIMUNDI.COM GOOGLE.COM.ZZZZZ.GET.LAID.AT.WWW.SWINGINGCOMMUNITY.COM GOOGLE.COM.ZOMBIED.AND.HACKED.BY.WWW.WEB-HACK.COM .

GOOGLE.COM.AU GOOGLE.COM.AR GOOGLE.COM.ALL.THE.PEOPLE.WHO.SPAM.THE.WHOIS.ARE.SERIOUSLY.ANNOYING.SOMEPONY.COM GOOGLE.COM.AFRICANBATS.ORG GOOGLE.COM.9.THE-WONDERBOLTS.COM GOOGLE.COM.1.THE-WONDERBOLTS.COM GOOGLE.COM To single out one record, look it up with "xxx", where xxx is one of the of the records displayed above. If the records are the same, look them up with "=xxx" to receive a full display for each record.

Оказывается, whois-сервер знает о ряде доменов, похожих на «google.com», и не знает, какой из них выбрать.

Или другой пример:

$ whois 8.8.8.8 Level 3 Communications, Inc. LVLT-ORG-8-8 (NET-8-0-0-0-1) 8.0.0.0 - 8.255.255.255 Google Incorporated LVLT-GOOGL-1-8-8-8 (NET-8-8-8-0-1) 8.8.8.0 - 8.8.8.255

Как мы видим, IP-адрес сначала был делегирован одной организации в определенном диапазоне, а затем повторно делегирован другой организации в меньшем поддиапазоне.

И whois-сервер опять же не знает, какая информация нас интересует. Другими словами, программа опирается на самый общий принцип работы whois-протокола и абсолютно не готова ни к каким исключениям.

Для «обнаружения» доменных whois-серверов используется whois-servers.net, что на данный момент является не самым эффективным способом.



jwhois

Теперь давайте посмотрим, как работает самая популярная утилита whois. В отличие от Whois Unix, он не осуществляет никакого «обнаружения», а полностью полагается на конфигурационный файл длиной в километр (около тысячи строк!), в котором жестко запрограммированы whois-серверы для всех известных доменов верхнего уровня, для ряда конкретных домены второго уровня (которые имеют собственные whois-серверы) и даже для определенных диапазонов IP-адресов.

Стоит ли говорить, что в современном быстро меняющемся мире этот файл конфигурации будет требовать ежедневных обновлений и вряд ли когда-либо будет обновлен на 100%? В шапке файла есть ссылка на репозиторий, из которого можно скачать последнюю версию, и оказалось, что она датирована апрелем 2011 года! За это время появилось много новых whois-серверов, а некоторые старые уже не работают. Я уверен, что было делегировано целый ряд новых диапазонов IP, особенно для IPv6. Помимо собственно названий whois-серверов, файл в специальном формате описывает все известные исключения для форматов запросов, а также формат ссылок на другие whois-серверы (намного больше, чем в Unix whois).

Также была обнаружена еще одна интересная функция.

Для многих доменов верхнего уровня Whois-серверы фактически не существуют или доступ к ним ограничен, но информация Whois доступна через Интернет на их веб-сайте.

Итак, jwhois может отправить необходимый запрос с помощью GET или POST, получить результат, а затем извлечь необходимую информацию из HTML. Адреса страниц, имена параметров формы и формат результатов для каждого конкретного случая также жестко запрограммированы в файле конфигурации.

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

Возвращаясь к приведенным выше примерам, jwhois правильно возвращает результат для «google.com», но с «8.8.8.8» он не лучше, чем Unix whois. В общем, как оказалось, jwhois не такая уж хорошая программа, как мы думали.

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



Руби Whois

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

Их журнал изменений изобилует такими обновлениями, как «Обновить whois.nic.ms до нового формата ответа», «whois.coza.net.za стал whois.registry.net.za» или «Добавлено определение и анализатор .

AX».

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

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

Но делать это для whois-серверов, которые меняются почти каждый день, вероятно, не самая полезная задача.

Мне как-то очень жаль авторов проекта — поддерживать его явно непростая задача.

На тот момент у меня уже были имена нескольких «хитрых» whois-серверов (и понимание, откуда их можно получить) — никакой информации о них в конфигурации Ruby Whois не было.

У меня не было возможности (или особого желания) запускать Ruby Whois, поэтому я не знаю, справится ли он с «8.8.8.8» или нет.

пкто

Еще одна программа, которую мне порекомендовали в комментариях к статье.

Он написан на Perl и является оберткой для модуля Net::Whois::Raw. Оба можно скачать здесь: http://search.cpan.org/~despair/Net-Whois-Raw-2.43/ .

Последнее обновление датировано августом 2012 года.

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

Главный недостаток тот же: нельзя все жестко закодировать.

Многие whois-серверы не настроены; поэтому невозможно получить информацию о ряде доменов.

Ну и с «8.8.8.8» программа тоже не справилась.



Что дальше?

К этому времени у меня уже были некоторые представления о том, как должен работать «правильный» whois, и я приступил к разработке первоначальной версии.

Все дальнейшие «знания» были получены экспериментальным путем в результате множества различных whois-запросов и анализа их результатов.

К счастью, многое из этого можно автоматизировать.

Еще хотелось бы отметить сайт http://whois.domaintools.com — лучший веб-сервис whois, который я смог найти.

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

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

Работу с whois я бы свел к решению трех фундаментальных задач:

  1. Определение правильного whois-сервера;
  2. Отправка корректного запроса на сервер;
  3. Анализ полученного результата.

Итак, давайте начнем.



Как определить правильный whois-сервер для домена?

Сначала несколько замечаний.

Невозможно получить информацию Whois для всех доменов верхнего уровня.

Некоторые страны вообще не предоставляют whois-информацию для своих доменов (например, КНДР).

Кроме того, в некоторых странах Африки нет своих whois-серверов (возможно, у них просто нет денег или они съели всех программистов).

Для некоторых доменов верхнего уровня информацию whois можно получить только на сайте регистратора.

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

Однако я полностью отказался от идеи парсинга.

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

Кроме того, эта информация требует постоянного обновления, поскольку может меняться даже чаще, чем имена whois-серверов.

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

В большинстве случаев whois-форма представлена либо на главной странице, либо перейти на страницу с ней можно в один клик.

Это гораздо более надежный метод, чем полагаться на «скрапинг», который все равно не сможет справиться с капчей.

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

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

Итак, где я могу получить имя правильного whois-сервера? Получить его можно из нескольких источников: 1. Есть такой замечательный whois-сервер whois.iana.org, принадлежащий IANA ( http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority ).

Он содержит самую свежую информацию обо всех доменах верхнего уровня.

Например (далее все примеры с использованием Unix whois):

$ whois -h whois.iana.org ru domain: RU organisation: Coordination Center for TLD RU address: 8, Zoologicheskaya str. address: Moscow 123242 address: Russian Federation contact: administrative name: .

RU domain Administrative group organisation: Coordination Center for TLD RU address: 8, Zoologicheskaya str. address: Moscow 123242 address: Russian Federation phone: +7 499 254 88 94 fax-no: +7 499 254 89 63 e-mail: [email protected] contact: technical name: Technical Center of Internet organisation: Technical Center of Internet address: 8, Zoologicheskaya str. address: Moscow 123242 address: Russian Federation phone: +7 495 737 92 95 fax-no: +7 495 737 06 84 e-mail: [email protected] nserver: A.DNS.RIPN.NET 193.232.128.6 2001:678:17:0:193:232:128:6 nserver: B.DNS.RIPN.NET 194.85.252.62 2001:678:16:0:194:85:252:62 nserver: D.DNS.RIPN.NET 194.190.124.17 2001:678:18:0:194:190:124:17 nserver: E.DNS.RIPN.NET 193.232.142.17 2001:678:15:0:193:232:142:17 nserver: F.DNS.RIPN.NET 193.232.156.17 2001:678:14:0:193:232:156:17 ds-rdata: 14072 8 2 DFFBFE59FBBD3289D0C3819F05F94610A1E03B556D64540A2CC5F8C4158A00E7 whois: whois.tcinet.ru status: ACTIVE remarks: Registration information: <span>http</span>:// www.cctld.ru/en created: 1994-04-07 changed: 2012-12-21 source: IANA

Обратим внимание на следующие строки:

whois: whois.tcinet.ru remarks: Registration information: <span>http</span>:// www.cctld.ru/en

На самом деле это whois-сервер и сайт регистратора! Для большинства доменов верхнего уровня IANA возвращает полностью актуальное имя сервера whois. Я специально проверил изменения в Ruby Whois за последние несколько месяцев, и все они были взяты с whois.iana.org. В своем модуле я кеширую результат от IANA на 24 часа (на больший период времени особого смысла нет, и данные могут измениться).

Несмотря на все сказанное выше, для некоторых доменов верхнего уровня IANA почему-то не предоставляет информацию о whois-серверах.

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

2. Если присмотреться, то для многих доменов верхнего уровня имена их whois-серверов выглядят как whois.nic. (более распространенный) или whois. (менее употребителен).

Например:

  • whois.nic.fr
  • whois.nic.it
  • whois.biz
Более того, даже если IANA укажет какой-то другой whois-сервер (например, whois.registro.br), во многих случаях построенный по этой схеме псевдоним (в нашем примере whois.nic.br) все равно будет работать.

Таким образом, если IANA нам ничего не вернула, то для любого домена верхнего уровня мы легко можем получить имена двух потенциальных whois-серверов:

  • whois.nic.
  • кто.

Практика показала, что этот метод определяет валидные whois-серверы для десятка доменов верхнего уровня, информацию о которых IANA не возвращает. Довольно часто, если мы ищем домен третьего уровня (например, russia.edu.ru), то whois-сервер, отвечающий за домен верхнего уровня, не содержит необходимой информации.

Например:

$ whois -h whois.tcinet.ru russia.edu.ru No entries found for the selected source(s).

Last updated on 2013.01.04 01:41:36 MSK

Это связано с тем, что за многие домены второго уровня (в нашем примере edu.ru) отвечает совершенно другая организация, у которой есть свой whois-сервер.

В таких случаях jwhois и Ruby Whois тщательно кодируют имя сервера whois для каждого известного им домена второго уровня со своим собственным сервером.

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

Например:

  • whois.za.net
  • whois.eu.org
  • whois.nic.priv.at
Что делать с теми whois-серверами, которые называются по-другому? Например, в конфигурации Ruby Whois вы можете увидеть:
  • ".

    ae.org", "whois.centralnic.com"

  • «.

    edu.ru», «whois.informika.ru»

С самого начала я был морально готов к необходимости жестко закодировать в своем коде несколько whois-серверов, однако, перебрав абсолютно все такие серверы, упомянутые в конфигурациях jwhois и Ruby Whois, оказалось, что все они на самом деле тоже доступны.

за псевдонимами, такими как whois. или whois.nic. ! Для нашего примера:

  • whois.ae.org
  • whois.edu.ru
В конечном итоге мне вообще не пришлось жестко прописывать ни один whois-сервер (за исключением whois.iana.org, конечно).

3. Помимо описанного выше, имя whois-сервера может также выглядеть как whois. .

Например:

$ whois -h whois.iana.org br whois: whois.registro.br remarks: Registration information: <span>http</span>://registro.br/

В некоторых случаях, когда IANA возвращает только сайт регистратора без whois-сервера, имя, построенное по этой схеме, оказывается правильным.

4. Как уже говорилось, whois-servers.net содержит псевдонимы whois-серверов только для достаточно ограниченного числа доменов верхнего уровня, но в некоторых случаях, когда все вышеперечисленное не помогает, псевдоним вида .

whois-servers.net выглядит вполне работоспособным (например, для «ps»).

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

Например, для russia.edu.ru у нас будет:

  • whois.tcinet.ru (результат IANA для «ru»)
  • whois.edu.ru << the whois server we need
  • whois.nic.edu.ru
  • whois.nic.ru
  • whois.ru
  • whois.cctld.ru («фиктивный» сервер на основе адреса сайта регистратора)
  • ru.whois-servers.net (фактически рабочий псевдоним whois.tcinet.ru)
Какой из них выбрать? На самом деле выбирать ничего не нужно, поскольку можно легко опросить все найденные whois-серверы в порядке приоритета.

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

Кроме того, если какого-либо из этих whois-серверов на самом деле не существует (а среди «фиктивных» их будет, естественно, большинство), то эту информацию можно легко закешировать.

Отдельно хотелось бы поговорить о кэше.

Whois-сервер от IANA и whois-серверы, найденные по ссылкам (подробнее об этом ниже), по умолчанию считаются «активными».

Когда активный сервер не отвечает (то есть сервер недоступен в принципе, а не просто не нашел необходимой информации для конкретного домена и вернул ошибку), его статус меняется на «временно недоступен».

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

В этом случае статус сервера меняется на «неактивный» и он блокируется ровно на две недели.

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

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

Все «фиктивные» whois-серверы и серверы типа По умолчанию домен .

whois-servers.net считается неактивным.

То есть, если они не отвечают, их сразу блокируют на две недели.

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

Стоит отметить, что при следующем поиске домена в зоне edu.ru активными будут считаться сразу два whois-сервера:

  • whois.tcinet.ru
  • whois.edu.ru
Однако тот факт, что whois.edu.ru активен, говорит о том, что первый whois-сервер, скорее всего, не содержит нужной нам информации (иначе очередь не дошла бы до whois.edu.ru, и он бы не стал активным).

Поэтому было бы целесообразно поставить его на первое место и опрашивать whois-серверы в следующем порядке:

  • whois.edu.ru << the whois server we need
  • whois.tcinet.ru
  • whois.nic.edu.ru
  • whois.nic.ru
  • whois.ru
  • whois.cctld.ru
  • ru.whois-servers.net
Если мы, например, ищем daily.lviv.ua (тоже домен третьего уровня), то результат по нему, скорее всего, вернет самый первый whois-сервер, который нам вернула IANA (whois.ua).

Поэтому сервер whois.lviv.ua никогда не станет активным (возможно, он не существует — я не проверял), и в следующий раз домен в зоне lviv.ua будем искать снова на whois.ua. Другими словами, через некоторое время запросы к несуществующим или некорректным whois-серверам сократятся до минимума.



Ссылки на дополнительные whois-серверы

Часто результат, выдаваемый whois-сервером, неполный, но содержит ссылку на другой whois-сервер, содержащий более полную информацию.

Например:

$ whois -h whois.verisign-grs.com 'domain google.com' Domain Name: GOOGLE.COM Registrar: MARKMONITOR INC. Whois Server: whois.markmonitor.com Referral URL: <span>http</span>:// www.markmonitor.com Name Server: NS1.GOOGLE.COM Name Server: NS2.GOOGLE.COM Name Server: NS3.GOOGLE.COM Name Server: NS4.GOOGLE.COM Status: clientDeleteProhibited Status: clientTransferProhibited Status: clientUpdateProhibited Status: serverDeleteProhibited Status: serverTransferProhibited Status: serverUpdateProhibited Updated Date: 20-jul-2011 Creation Date: 15-sep-1997 Expiration Date: 14-sep-2020

Как видите, информации не так много, но есть ссылка на другой whois-сервер:

Whois Server: whois.markmonitor.com

Если теперь обратиться к этому, то получим:

$ whois -h whois.markmonitor.com google.com Registrant: Dns Admin Google Inc. Please contact [email protected] 1600 Amphitheatre Parkway Mountain View CA 94043 US [email protected] +1.6502530000 Fax: +1.6506188571 Domain Name: google.com Registrar Name: Markmonitor.com Registrar Whois: whois.markmonitor.com Registrar Homepage: <span>http</span>:// www.markmonitor.com Administrative Contact: DNS Admin Google Inc. 1600 Amphitheatre Parkway Mountain View CA 94043 US [email protected] +1.6506234000 Fax: +1.6506188571 Technical Contact, Zone Contact: DNS Admin Google Inc. 2400 E. Bayshore Pkwy Mountain View CA 94043 US [email protected] +1.6503300100 Fax: +1.6506181499 Created on.: 1997-09-15. Expires on.: 2020-09-13. Record last updated on.: 2012-01-29. Domain servers in listed order: ns2.google.com ns4.google.com ns3.google.com ns1.google.com

Таким образом, чтобы получить наиболее полную информацию, мы должны поискать в результатах ссылки на другие whois-серверы.

Чаще всего они выглядят так: «whois-сервер: », но зачастую ссылка находится в совершенно непредсказуемом месте (например, в середине текста).

Мой модуль ищет ссылки достаточно агрессивно, принимая за whois-сервер любую строку, похожую на имя хоста и содержащую слово «whois» (как мы уже выяснили, «лишние» whois-серверы — не проблема).

Если мы нашли ссылку в формате «whois-сервер: », то имя сервера не обязательно должно содержать слово «whois» (на практике это может быть даже не имя хоста, а просто IP-адрес).

Все найденные whois-серверы по умолчанию считаются активными.

Правда, здесь есть один подводный камень.

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

Например:

$ whois -h whois.jp newsmap.jp [ JPRS database provides information on network administration. Its use is ] [ restricted to network administration purposes. For further information, ] [ use 'whois -h whois.jprs.jp help'.

To suppress Japanese output, add'/e' ] [ at the end of command, e.g. 'whois -h whois.jprs.jp xxx/e'.

] .



Там упоминается whois.jprs.jp, который на самом деле является псевдонимом whois.jp. То есть, если мы сейчас отправим запрос на whois.jprs.jp, то получим тот же результат. Кроме того, некоторые whois-серверы могут работать как прокси и возвращать результаты от какого-то другого whois-сервера — естественно, упоминая в результате его имя.

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

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

Однако не все так просто.

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

Если первый whois-сервер работает как прокси, то он, как правило, будет содержать некоторый дополнительный текст. И самое интересное: некоторые whois-серверы умудряются от запроса к запросу возвращать данные в разном порядке! То есть результат запросов абсолютно одинаковый, но несколько строк поменяны местами.

Поэтому перед сравнением я заменяю все числовые последовательности на «X», удаляю все пустые строки и строки, начинающиеся с «#» или «%» (комментарии), и на всякий случай заменяю несколько пробелов одним и делаю «обрезку».

все линии.

После этого я сравниваю два набора строк (используя тип set в Python), и если второй является подмножеством первого, то он является дубликатом.

К счастью, с IDN-доменами (такими как «правительство.

рф») проблем не возникает. Переводим «правительство.

рф» в «xn--80aealotwbjpid2k.xn--p1ai» и ищем на whois.i Теги: #whois #rwhois #python #Домены #практические советы #Разработка сайтов #python

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.